Crypto active addresses vs users: what the count means

Crypto active addresses count distinct addresses that meet a provider's activity rule during a defined period. They do not count unique human users: one person can control several addresses, a shared address can serve many people, and software or contracts can generate activity. Read the definition, separate initiators from recipients, and treat entity-adjusted counts as estimates of common control rather than a census.

A chart labeled “users” may contain an address metric underneath. Before interpreting its growth, identify what actually qualifies for the count. The difference can change the number substantially without changing a single transaction in the source ledger.

Define what active includes

There is no useful interpretation of “active” without a rule and a window. Coin Metrics defines its active-address series using distinct originators and recipients of qualifying ledger changes. An address counts once within the relevant interval, however many times it participates. Its documentation also explains that eligible actions depend on the protocol.

By comparison, growthepie's methodology counts distinct transaction from addresses and excludes to addresses. That addresses a different question: which addresses initiated activity? It does not establish that each initiator was a separate person. Two charts using these definitions can disagree while accurately applying their respective rules.

Specify the network, asset scope, qualifying action and observation window before comparing providers. A native-asset transfer series, token-transfer series and application-interaction series need not describe the same set of addresses. A chain-level count also cannot automatically become an application's audience count.

Account type matters too. Ethereum's account documentation distinguishes externally owned accounts, which can initiate transactions, from contract accounts controlled by code. It also distinguishes a wallet, the interface used to interact with an account, from the account itself. Counting a contract address does not count a person who clicked a button. Conversely, excluding contract addresses does not solve the problem of one participant controlling several externally owned accounts.

Recount a small transaction network

This example is hypothetical. It uses seven completed asset-transfer records inside one UTC day on a fictional network. Each row qualifies under our declared sender-or-recipient rule. Fees, rewards, additional contract calls and other transfers are outside this small fixture; it is not a complete Ethereum trace or a reproduction of either provider's metric.

The ownership information is stipulated for teaching. Operator Alpha controls A1, A2 and A3; Beta controls B1 and B2; an exchange controls X; an application has contract address P; automation operator Gamma controls C1, C2 and C3. “Operator” can mean a person or an organization. These labels are not discoverable with certainty merely by reading the transfer arrows.

The distinct senders are A1, A2, A3, X, B1, C1 and C2: seven. The distinct recipients are A2, P, X, B1, B2, C2 and C3: also seven. Four addresses appear in both sets: A2, X, B1 and C2.

The combined active-address count is therefore 7 + 7 − 4 = 10. Adding sender and recipient counts without subtracting their overlap would incorrectly report fourteen. Repeated activity by A2 or C2 does not create additional distinct addresses.

Under the stipulated control mapping, those ten addresses belong to five groups: Alpha, Beta, the exchange, the application and Gamma. That is a description of five operator groups, not five humans. The application is software; an exchange can serve customers whose individual actions and identities are absent from this ledger. The a16z crypto user-estimation methodology discusses both directions of the ambiguity: multiple addresses per person and multiple people behind a shared address.

The three answers are thus ten participating addresses, seven initiating addresses and five stipulated operator groups. A human-user count remains unknown. Because the mapping can run in either direction, address counts are neither a guaranteed upper nor lower bound on humans. Reducing ten to five does not reveal a census.

Understand a jump with no new initiators

Extend the same hypothetical day with forty more transfer records: C1 sends a nominal amount to each of R1 through R40. All forty recipient addresses are distinct from the original ten. None initiates a transfer in the observed window, and the fixture provides no information about their owners or intentions.

The total record count becomes forty-seven. The sender-or-recipient address count rises from ten to fifty, an increase of (50 / 10 − 1) × 100 = 400%. The distinct sender count stays at seven because C1 was already a sender. Forty additional addresses participated as recipients; forty additional people did not necessarily choose to use the network.

That distinction is particularly useful when interpreting distributions and unsolicited transfers. A recipient's inclusion can be correct under the metric definition even when describing it as an engaged user would be unsupported. The right response is to inspect the activity, rather than remove inconvenient records simply because they weaken an adoption narrative.

A sender-only rule would avoid counting these forty passive recipients. It would still count multiple initiating addresses controlled by one operator if that operator chose to use them. No single address filter supplies a universal conversion from on-chain activity to humans.

Aggregate time windows with sets

Return to the original seven-record fixture, without the forty-recipient extension. Suppose the following day contains only A1 sending to P and X sending to B1. That day's four active addresses all appeared on the first day.

Adding daily counts gives 10 + 4 = 14 address-days. The distinct two-day address count is ten, because the union contains no new address. An average of seven daily active addresses answers another question again. Neither fourteen nor seven is the distinct two-day address count.

For a weekly or monthly measure, deduplicate over the entire stated window. If all you have is a table of daily counts, the overlap needed to recover the period's unique-address count is missing. Do not invent it by assuming that every day contains new addresses.

Use the same care across chains. Decide whether the unit is an address on a particular network, a deduplicated identifier across a specified set of networks, or an estimated operator. A sum of chain totals can describe chain-address observations. It cannot establish unique people without additional identity evidence and a disclosed method.

Treat entity adjustment as a model

Entity-based data can help answer common-control questions. Glassnode's active-entities documentation describes clusters estimated to share control using heuristics and proprietary clustering methods. It also warns that recent entity-based observations can revise as clustering improves. This is a documented provider implementation, not a universal way to identify users across every chain.

Ask what evidence supports a cluster and what remains uncertain. An incorrect merge can combine separate operators; a missed relationship can leave one operator split across several clusters. A correctly identified custodian can still represent many customers. A “filtered” or “entity-adjusted” label therefore requires a definition alongside the value.

In the example, five groups are known only because the scenario supplies ownership. A production researcher would need supporting evidence for each proposed relationship. Funding several addresses from one source can justify investigation, but it does not by itself prove they all belong to one person.

Save the metric identifier, extraction date and methodology version where available. The data-provenance guide explains how to connect a derived claim to the input actually used. For historical research, the event, publication and ingestion-time guide helps distinguish what was known then from what a later download says. A revised cluster should not silently become earlier knowledge.

Audit one chart before using its headline

Use this worksheet on a single observation and its comparison period. Request the missing definition before expanding the conclusion.

For a surprising increase, inspect the records contributing new addresses. Separate receiving-only addresses from initiators under an explicitly declared rule. Check whether activity concentrates around one distributor or application. Such concentration is a lead for further review; it is not proof that recipients are bots or that an application has no human demand.

Keep a version without the exploratory filter and one with it, together with the removed count and reason. If an adoption claim depends on labeling every low-frequency address fake, the conclusion depends on that assumption. A legitimate occasional participant can otherwise disappear from the analysis.

Choose other metrics according to the question. If a distribution raises a supply question, examine token unlocks and dilution; recipient counts do not measure the change in circulating supply. For stablecoins, supply versus liquidity separates the quantity issued from trading conditions. Address activity alone answers neither question and provides no promised trading outcome.

For the next activity chart you use, write one defensible sentence: “This source counted these distinct addresses, under this rule, over this complete window.” Add an estimated-user claim only when you can also explain its identity evidence, assumptions and remaining uncertainty.