Understanding On-Chain Analytics Metrics

Research question and scope

This article defines four commonly used on-chain metrics, grounds the active-addresses definition in a major analytics provider's own published documentation, and compares what each metric actually measures against its most common interpretive distortion. It is a methodology overview, not a live reading of any specific network's current metric values.

Key findings

• Public blockchains' openly recorded transaction data is what makes on-chain analysis possible at all, independent of any single company's self-reported figures.
• Glassnode's own documentation defines "active addresses" narrowly — unique senders or receivers in successful transactions only — and states no exclusion for exchange-internal or automated addresses, meaning the burden of filtering non-representative activity falls on the analyst, not the metric's own definition.
• Every commonly used on-chain metric has at least one well-documented way it can be distorted by non-representative activity (automation, exchange-internal transfers, or concentrated actors).
• No single on-chain metric reliably tells the full story alone — they are most informative considered together, in context.

Why on-chain data is analyzable at all

Public blockchains record transaction and account data openly, which lets analysts study real network activity directly from the chain itself, rather than relying solely on self-reported figures from any single company or platform.

Methodology: how one major provider actually defines "active addresses"

Rather than relying on a general description of "active addresses," this section reads Glassnode's own API documentation directly. Glassnode's published definition of its active_count endpoint states, verbatim, that the metric is "the number of unique addresses active in the network as a sender or receiver," and specifies that "only addresses active in successful transactions are counted." A separate variant, active_count_with_contracts, additionally counts an address as active if it calls a smart contract. Notably, Glassnode's documentation for this specific metric states no exclusion for exchange-internal addresses, automated/bot addresses, or any minimum transaction size — meaning that, by the provider's own stated definition, the metric does not inherently filter out the kinds of non-representative activity analysts commonly worry about. That filtering, where it happens, is a judgment the analyst applies on top of the raw metric, not something built into the metric's own definition.

Common metrics and what they generally indicate

• Active addresses: the number of distinct addresses that transacted over a given period, often used as a rough proxy for network usage.
• Transaction count and volume: how many transactions occurred, and their total value, over a given period.
• Network fees paid: total fees paid by users over a period, sometimes used as a proxy for demand for block space.
• Exchange inflows/outflows: the net movement of an asset onto or off of centralized exchange addresses, sometimes referenced as a general sentiment indicator.

Real limitations to keep in mind

On-chain metrics can be influenced by non-representative activity, such as automated transactions, exchange-internal address reshuffling, or a small number of actors generating a large volume of activity — meaning raw metrics don't always reflect genuine, organic usage in a straightforward way.

Comparing the four common metrics

Independent critical analysis

A common assumption in casual on-chain commentary is that a rising active-addresses count straightforwardly means a growing number of genuine users. Reading Glassnode's own definition directly undercuts this more specifically than the general "one person can control many addresses" caveat usually conveys: the documented definition counts any successful sender or receiver, with no stated minimum value, no stated exclusion for contract-internal calls in the base metric, and no stated exclusion for addresses that are known exchange hot wallets or automated market-making bots. This means the metric's documented construction, not just a hypothetical edge case, permits a single automated process cycling funds through many addresses to register as many distinct "active addresses" within one window. The practical implication is that active-addresses growth driven by a new automation pattern (for example, an airdrop farming campaign or a bot-driven arbitrage strategy) is not a departure from how the metric is supposed to work — it is squarely within its documented definition, which is a meaningfully different claim than saying the metric is merely "a rough proxy with some noise."

Limitations of this comparison

• This describes each metric's general definition and known distortion risk, not current values for any specific network.
• The active-addresses definition above is Glassnode's own, read directly from its documentation; other providers (Nansen, CryptoQuant, and others) may define or filter the same-named metric differently, and this article does not claim their definitions are identical.
• A metric's actual reliability varies by network, since address/wallet conventions and exchange practices differ.
• Combining metrics reduces but does not eliminate interpretive risk — context about the specific network still matters.

Implications and research conclusion

On-chain analytics offers genuinely useful, directly verifiable data about network activity, but common metrics like active addresses and transaction volume each have real, documented interpretive limitations. Reading a major provider's own definition directly, rather than relying on a general description, shows that at least one of these limitations (automated or exchange-driven address inflation) is not an incidental edge case but a direct consequence of how the metric is actually defined — reinforcing that these metrics are most useful analyzed together, in context, rather than read as a standalone proxy for "real users."

References

Primary source (read directly for this article): Glassnode, API documentation for the Addresses endpoints, including active_count and active_count_with_contracts (docs.glassnode.com/basic-api/endpoints/addresses) — Glassnode's own stated metric definitions, read verbatim rather than from a secondary summary.

Secondary sources (background only): general educational commentary on on-chain metric conventions and known interpretive distortions, surfaced via search synthesis and used only for the non-Glassnode-specific metric descriptions above (transaction count/volume, network fees paid, exchange inflows/outflows), which were not verified against a single named provider's documentation in this pass.