Active Solana addresses are not the same as active users

Decide what makes an address active

A dataset might count transaction signers, fee payers, referenced account keys, changed accounts or participants in decoded application events. Those rules produce different populations.

A signer approves a message under transaction rules. A fee payer funds its fee. A referenced program or token account can appear without being a separate human participant.

Choose a metric such as distinct fee-payer addresses in successful transactions over one UTC day. That is a reproducible definition if the source and format coverage are known. Calling it daily users would make a stronger unsupported claim.

Keep the counted role, execution filter, cluster, period and source alongside the result.

One person can control several addresses

Choose a teaching population: Alice uses addresses A1 and A2. Bob uses B1. A single automated service uses ten addresses C1 through C10.

A distinct-address count sees 13 under a rule which includes all of them. The underlying actors in this chosen model are two people and one service, not 13 people.

A wallet can also control several token holding accounts or application positions. Counting every touched account as another user can multiply one action's apparent audience.

Address clustering can estimate relationships, but it introduces assumptions and possible errors. Keep inferred entities separate from directly observed addresses.

One address can serve many people

A custodial exchange can maintain an internal customer ledger while using pooled onchain accounts. Many customers can buy, sell or transfer internally without each action appearing as a unique customer address onchain.

A payment service can sponsor fees for users, making one fee payer represent activity from several customers. An application can also process batches.

The reverse mapping therefore fails too: one active address does not imply one active person. A public chain does not expose every service's private customer ledger.

For a product's actual user metric, combine authorized product analytics with a clearly defined account or customer model. Do not claim a network-wide human census from addresses alone.

Distinct addresses and address-days differ

Deduplicate within the intended time window

Choose day one with active set A,B,C and day two with B,C,D. Each day has three addresses. The distinct two-day population is four: A,B,C,D.

Adding daily counts gives six address-days, not six distinct addresses. Both quantities can be useful, but they have different units.

The same issue applies to weekly and monthly metrics. Compute the union over the intended period rather than summing already deduplicated daily counts.

Retention or return-rate analysis also needs an explicit cohort and matching rule. Reappearing addresses remain an address-level observation, not proof that the same individual returned.

Separate activity classification from intent

Bots can make useful market operations or unwanted activity. A high transaction count alone does not determine which. Classification needs program behaviour, patterns and a documented method.

Sponsored accounts, temporary accounts and account-creation campaigns can change address counts. Identify structural changes before interpreting a jump as user growth.

Filtering bots can also remove legitimate automated services or misclassify humans. Publish the criteria and coverage rather than claiming a perfect human-only dataset.

Keep failed transactions and successful application events distinct if your audience question depends on actual completed use.

Present the count with its supported conclusion

A defensible label might read distinct successful-transaction fee payers, daily UTC, with source, update time and exclusions. That tells readers what was observed.

For cross-chain or cross-provider comparisons, align account-role definitions and indexing coverage. Different execution and custody models can make superficially similar labels incompatible.

Use address activity alongside other evidence, such as decoded service events or application-specific records. State the narrower conclusion each supports.

The network metrics guide provides a general definition and coverage record for those comparisons.

Common questions