An analyst sees active addresses double and must decide whether a lending protocol gained borrowers or a bot farm rotated wallets. The chain exposes signatures, calls, transfers, and state changes, not ready-made users, payments, or motives. One entity may control many addresses while a custodian aggregates millions of customers, so credible onchain analysis requires a defined economic unit, reproducible transformations, documented labels, sensitivity tests, and explicit uncertainty.
A strong workflow begins with a falsifiable question, reconstructs data from primary chain records, and builds an audit trail from raw events to the final metric. It pairs activity counts with value, fees, retention, counterparties, and application context. Most importantly, it separates observable facts from estimated entity relationships and inferred intent. Transparency of transactions improves verification, but it does not remove ambiguity about ownership, offchain agreements, or economic purpose.
What you will learn
- Design reproducible onchain metrics from transactions, traces, and events
- Separate addresses, entities, users, and economic actions
- Use cohorts, flow reconciliation, and sensitivity tests to challenge conclusions
Start with a question and a measurement contract
Replace broad questions such as whether adoption is growing with a measurement contract. Specify the chain, contracts, event types, time boundary, finality rule, units, exclusions, and entity definition. State what observation would support or contradict the hypothesis. A query measuring repeat borrowers needs a different universe from one measuring bridge settlement, and neither should silently become a claim about unique human users.
Preserve data lineage. Record node or indexer sources, block ranges, query version, decoded application interfaces, price methodology, label snapshot, and known chain reorganizations or migrations. Use integer token amounts and contract decimals before translating values. Reconcile totals against contract state, protocol reports, or an independent provider where possible. Reproducibility means another analyst can explain a difference instead of merely receiving the same dashboard screenshot.
Move carefully from addresses to entities
Address-level facts are usually the safest starting point: this address signed a transaction, received a transfer, or called a contract. Entity clustering adds estimates based on deposit patterns, common control, wallet disclosures, transaction timing, or known service infrastructure. Labels can be wrong, stale, or overly broad. Keep the original address data, assign label provenance and confidence, and allow results to be recalculated without uncertain clusters.
User counts require even more restraint. A custodial address can represent many beneficial users that are invisible onchain, while one automated agent can create many wallets. Sybil resistance, identity attestations, and account-abstraction structures change the mapping but do not solve it universally. Report active addresses or estimated entities using the correct term, and use ranges when clustering uncertainty could change the conclusion materially.
Distinguish economic activity from mechanical flow
Token transfer volume can double count the same economic value across a router, bridge, vault, and destination. Contract internals may move collateral without a new user decision. Exchanges sweep deposits among hot and cold wallets, protocols rebalance treasury assets, and flash loans create large intrablock flows that are repaid. Build flow rules around the economic event, then reconcile inputs and outputs so plumbing does not masquerade as final demand.
Pair quantity with quality indicators. For applications, examine repeat cohorts, fees paid net of incentives, transaction size distribution, contract diversity, time between actions, counterparties, and behavior during normal and stressed periods. For assets, separate minting, burning, bridging, exchange deposits, collateral locking, and simple transfers. No universal composite score removes judgment; the objective is to make each transformation visible and challengeable.
Use cohorts, comparisons, and falsification
Cohorts reveal whether activity persists. Group estimated entities by first qualifying action, then measure return at fixed intervals and distinguish survival from transaction intensity. Compare incentive and non-incentive periods, new and mature contracts, or similar applications using aligned definitions. Correct for partial periods and migrations. A rising average can coexist with weakening cohorts if a few large entities dominate, so inspect distributions rather than only totals.
Try to disprove the preferred interpretation. Remove known bots, alter clustering thresholds, exclude bridge loops, cap whale influence, change price sources, and shift the observation window. Search for alternative explanations such as an airdrop campaign, contract upgrade, exchange wallet migration, or fee change. If the conclusion disappears under a reasonable specification, confidence should fall. Sensitivity is a result to report, not an inconvenience to hide.
Common misconceptions
“Every active blockchain address represents one active user.”
One entity can control many addresses, custodians can aggregate many users, and automated systems can create activity without a separate human decision for each wallet.
“Public onchain data reveals the economic intent behind every transaction.”
The ledger records authorized state changes. Ownership, purpose, offchain hedges, internal bookkeeping, and beneficial users often require estimates or remain unknown.
Risks and limitations
- Incomplete or incorrect entity labels can materially change user, flow, and concentration conclusions.
- Bridge routes, routers, internal transfers, and flash loans can cause the same economic value to be counted repeatedly.
- Contract upgrades, event changes, decimal errors, and chain reorganizations can break historical query consistency.
- Analysts can select windows and filters after seeing results, creating confirmation bias and false statistical confidence.
Key takeaways
- Define chain, contracts, events, units, exclusions, and finality before running a metric.
- Preserve address-level facts separately from labels, entity estimates, and user inferences.
- Reconcile economic actions across routers, bridges, vaults, and internal protocol movements.
- Use cohorts and distributions to evaluate retention instead of relying on cumulative counts.
- Publish sensitivity tests and alternative explanations alongside the preferred interpretation.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.