BTC$81,066-0.10% ETH$2,363-0.79% USDT$0.9992+0.01% BNB$710.71-0.41% XRP$1.27-1.44% USDC$0.9998+0.00% SOL$101.70-0.50% TRX$0.3323-0.32% FIGR_HELOC$1.07+4.39% ZEC$1,074-4.49% HYPE$77.07-1.65% DOGE$0.0772-1.55% XMR$583.92+4.14% USDS$1.0000+0.01% WBT$79.08-0.28% LINK$11.70-1.50% LEO$9.04-0.05% ADA$0.2146-1.20% RAIN$0.009085+3.83% NEAR$4.71-3.06% XLM$0.1732-1.79% BCH$267.09-2.25% USDE$0.9995+0.01% DAI$1.00+0.01% LTC$57.56-0.98% UNI$6.92-2.81% AVAX$9.43-2.37% USD1$0.9993+0.00% SUI$0.9528-1.46% CC$0.0970-5.82% GRAM$1.33-1.33% BTW$2.47-2.87%
Menu
Home
Assets
Coverage
All assetsEvery research file, largest firstSectorsWhat each category holds and weighsRankingsFourteen leaderboards and what they missHeat mapThe market sized by value, shaded by changeGlobal marketTotal capitalization, dominance and volume
Tools
ScreenerFilter by fundamentals, supply and riskCompare assetsResearch files side by sideSavedThe assets you have starred
Fundamentals
Economics
Fees & revenueWhat users pay, and who keeps itValue lockedCapital deposited in each networkExchange volumeTrading on decentralized exchanges
Networks
Network activityAddresses, transactions and throughputStablecoinsDollar tokens, where they live and what backs themStaking & yieldWhat securing a network pays, after issuance
Valuation
Standardized measures
Valuation ratiosPrice against fees and revenue, limits statedSupply & issuanceCirculating, maximum and the dilution aheadMetric definitionsEvery figure: definition, period, limitation
Institutional
Regulated access
Exchange-traded productsEvery US-listed fund, with a page eachCorporate treasuriesListed companies holding digital assets
Research
Analysis
Research notesShort notes written from stored figuresEvents calendarUpgrades, halvings and policy dates
Risk
Risk frameworkFifty factors in seven familiesSecurity incidentsExploits and failures, with the losses
Learn
Education
Learn libraryEleven tracks, from first principlesGlossaryEvery term in plain EnglishCalculatorsFee drag, dilution and conversion
How this site works
MethodologyHow every figure is measuredData sourcesWho publishes what we showData freshnessWhen each feed last ranAI agentsPrompts that keep an assistant on our dataPublic APIThe same figures, as JSON
News Ask the data About us
Reading options
Guided view

New to markets — prices, yields, market cap? We explain every term as you browse, in plain English. Same data, with the help built in.

Expert view

You already know the market. Just the data — clean, fast and compact, with no extra explanations. This is the default view.

View
Light or dark
Language
Photography PhotographyStill lifeCryptoStudio
Public API

Every figure on this site is available as JSON, with its period and source attached.

Read the API docs
Valuation Working knowledge 6 min

Market cap per active address, and why an address is not a person

Dividing market cap by active addresses gives a value-per-user figure whose denominator counts neither values nor users reliably.

Market cap per active address divides a network's market capitalization by the number of addresses that transacted over a period. It is the closest available analogue to a value-per-user measure, and the analogy holds only if addresses correspond to users, which they do not. One person can control thousands of addresses, and one address can serve millions of people.

The metric is published as market cap per active address, built from market cap and 24-hour active addresses. Both inputs are well defined; the interpretation placed on their quotient is where the difficulty lies.

What an address is

An address is a destination derived from a public key, or in some designs from a contract. Creating one costs nothing and requires no permission and no identity. A single wallet application routinely generates a fresh address for each receipt, which is standard practice on ledgers that track unspent outputs and is done for privacy rather than for accounting. Nothing in the protocol records that those addresses belong to one person.

The reverse case is equally common. A centralized exchange may serve a very large user base from a small number of on-chain addresses, settling most transfers internally and touching the public ledger only at the edges. Those users are entirely invisible to an address count, and the exchange itself appears as a handful of extremely active addresses.

What inflates and what deflates the count

EffectCauseDirection
Fresh address per transactionWallet privacy defaultsInflates
Airdrop farmingOne operator running many addresses to qualify for a distributionInflates
Bots and arbitrageAutomated strategies transacting continuouslyInflates
DustingUnsolicited tiny sends to many addressesInflates
Exchange internal settlementUsers trading without touching the chainDeflates
Layer 2 migrationActivity moving to a network that settles in batchesDeflates the base layer
Batched payoutsMany payments compressed into one transactionDeflates

Several of these operate at once and in opposite directions, which is why an address count is unreliable as a level and more informative as a change. Address clustering attempts to group addresses under a common controller using spending heuristics and known labels. Those heuristics are probabilistic, proprietary where they are any good, and subject to revision as new patterns are identified, so a clustered count is an estimate with an unpublished error bar rather than a census.

The layer 2 discontinuity

The most consequential distortion is structural. When users move to a layer 2 network, their activity no longer appears in the base layer's address count, even though the base layer still provides settlement and still earns fees from the rollup posting its data. A base-layer address count falling while total usage rises is the expected outcome of a working scaling design, not a decline in adoption.

This makes the ratio non-comparable across time for any network that has undergone such a shift, and non-comparable across networks with different architectures. A chain that executes everything on its base layer will always show more base-layer addresses than a modular one serving the same population. The network activity pages present address counts per layer so the transfer is visible rather than read as a decline.

What it is still good for

Two uses survive the caveats. The first is direction over time within one network with a stable architecture, where the 30-day change in active addresses read against daily transactions can show whether growth is coming from more participants or from the same participants transacting more often. Those two patterns have different implications for fee stability and neither is visible from the headline count.

The second is as a divergence check. If market cap moves substantially while address counts, transaction counts and fees do not, that divergence is a fact worth recording. It carries no direction and no conclusion. Networks have gone through long periods in which usage and valuation moved apart, in both directions, and those episodes resolved in ways that no reading of the ratio would have anticipated in advance.

Three counts that are often confused

Active addresses and new addresses answer different questions, and addresses with a balance answers a third. Active counts participation within a window. New counts first appearances, which is inflated by exactly the behaviors listed in the table above and is the easiest of the three to manufacture. Addresses with a balance counts holding rather than transacting, and is inflated by dust and by the fact that abandoned addresses never disappear from a ledger that only appends.

None of the three is a user count, and treating any of them as one produces a per-user figure with no defensible unit. Stated precisely, market cap per active address is dollars of market capitalization per transacting address per day. That is a real quantity with a narrow meaning, and the narrow meaning is the whole of what it supports.

The count is also asymmetric in how it can be manipulated. Raising an address count is nearly free, since the only cost is the transaction fee on a low-fee network, and incentive programs have repeatedly produced large increases that reversed as soon as the program ended. Lowering one requires a change in behavior or architecture. A rising count therefore carries less information than a falling one, which is the opposite of how such series are usually read.

A final point about scale. Because the denominator is a count rather than a value, the metric is extremely sensitive to network size and says nothing about how much value each of those addresses moved. Two networks with identical counts can differ enormously in the size of the transfers behind them, which is a question for the settled-value measures in the next article.

The network activity pages carry the address and transaction series with their layer attribution, and the methodology pages state which deduplication is applied to each.

01

What to take away

Addresses are free to create and carry no identity, so a count of them is not a count of people.
Wallet defaults, bots, airdrop farming and dusting inflate counts while exchanges, batching and layer 2 migration deflate them.
A base-layer address count falling as activity moves to a rollup is the expected result of scaling, not a decline in use.
The metric is most defensible as a change over time within one network and as a divergence check against fees and transactions.
Active addresses, new addresses and addresses with a balance measure three different things and are not interchangeable.
Digital Asset DatabaseDigital asset research & education

Assets

All assetsSectorsRankingsHeat mapScreenerCompareSaved

Fundamentals

Fees & revenueValue lockedExchange volumeNetwork activityStablecoinsStaking & yield

Valuation & risk

Valuation ratiosSupply & issuanceMetric definitionsRisk frameworkSecurity incidents

Institutional

Exchange-traded productsCorporate treasuriesEventsResearch notesNews

Learn

Learn libraryGlossaryCalculatorsAsk the dataAI agentsPublic API

About

About usContactMethodologyData sourcesEditorial policyData freshness

Legal

DisclaimersTerms of usePrivacy policy