# Where an on-chain number comes from before you see it

Four stages sit between a block and a dashboard — a node, an indexer, an attribution layer and a metric definition. Each one is a decision you cannot see.

*https://cryptomarkets.tools/guides/where-an-onchain-number-comes-from · background to On-chain Analytics Platforms*

**Answer:** Four stages sit between a block and the number on a dashboard. A node or RPC provider serves the raw data, an indexer decodes and stores it, an attribution layer decides which addresses belong to whom, and a metric definition decides what counts. Every stage is a vendor decision. Two platforms disagree about active addresses because they disagree three stages down, and only the last stage is usually published.

You open two dashboards, ask both for active addresses on the same chain for the same day, and
get two numbers. Neither is broken. They disagree because four separate things had to happen
between the block and the chart, each of them a decision somebody made, and only the last of the
four is normally written down anywhere you can read it.

This page is the pipeline, in the order the data moves through it. It is worth knowing before you
buy anything in this category, because which stage you can live with somebody else owning is the
actual purchase decision — and because a number quoted with confidence in a report is a number
that inherited all four.

## How it works

### Stage one — somebody has to be holding the history

Chain data is public. Holding all of it is not free, and the split is a documented property of
the node software rather than a vendor's choice. A full node, says
[ethereum.org's nodes and clients page](https://ethereum.org/en/developers/docs/nodes-and-clients/),
"only keep a local copy of relatively recent data (typically the most recent 128 blocks)". An
archive node "stores everything kept in the full node and builds an archive of historical
states", and is what you need "if you want to query something like an account balance at block
#4,000,000". The page puts the storage at "units of terabytes".

That is the whole economic basis of this category. Everything else on this page is built on
somebody having paid for that, and most of the products here are reselling it in one form or
another. [Token Terminal](https://cryptomarkets.tools/tools/token-terminal) runs its own nodes and describes over a petabyte
processed daily, loading raw and transforming afterwards specifically so a methodology change can
be replayed over history rather than requiring a re-ingest. [Dune](https://cryptomarkets.tools/tools/dune) puts its own
catalogue at 100+ chains and 3+ petabytes. [growthepie](https://cryptomarkets.tools/tools/growthepie) says it indexes most of
its own data via RPCs.

The archive is also where the cheap plans stop. On [Bitquery](https://cryptomarkets.tools/tools/bitquery)'s self-service
plans, raw on-chain data keeps four hours on EVM chains and Tron and eight on Solana; complete
history is a per-chain add-on rather than part of any published plan. A rolling window and an
archive are different products sold from the same page.

**One case where the raw data genuinely goes away.** Layer twos post their data to Ethereum in
blobs, and [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), read on 21 September 2026,
specifies both halves of what that means — blob contents are "a large amount of data that cannot
be accessed by EVM execution, but whose commitment can be accessed", and the retention parameter
`MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS` is 4096 epochs, which the EIP itself glosses as "around
18 days". So an L2 metric computed from blob data is computed from something the network is not
specified to keep, by whoever archived it in time. When [L2BEAT](https://cryptomarkets.tools/tools/l2beat) and growthepie
agree on an L2's costs, that agreement rests on two parties having independently held the same
disappearing input.

### Stage two — the indexer decides when a block is true

An indexer does two jobs, and both are judgement calls dressed as plumbing.

The first is deciding what counts as settled. Ethereum's
[proof-of-stake documentation](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/)
divides time into "slots (12 seconds) and epochs (32 slots)", makes "the first block in each
epoch" a checkpoint, and finalises a checkpoint only once a supermajority link exists between two
of them. The latest block is therefore not the same kind of fact as a block from an hour ago, and
every platform here picks a different point on that curve and mostly does not tell you which.

The ones that do tell you are worth naming, because the numbers are not close to each other.
[Glassnode](https://cryptomarkets.tools/tools/glassnode) waits one block confirmation on Bitcoin and twelve on Ethereum,
publishes a deliberately incomplete last bar, and recommends waiting roughly two hours after first
release on Bitcoin and ten minutes on Ethereum before treating a value as final.
[CryptoQuant](https://cryptomarkets.tools/tools/cryptoquant) avoids the newest block outright to survive reorganisations and
publishes the resulting lag as data — append `/latency` to any v1 endpoint and it returns the
blockchain's own delay and the platform's processing delay as two separate ISO-8601 durations,
with a worked example in its documentation of roughly 14 minutes of block delay and 26 of
processing at day resolution. [Allium](https://cryptomarkets.tools/tools/allium) puts its SQL product about an hour behind
the chain and its warehouse shares one to three hours. [Nansen](https://cryptomarkets.tools/tools/nansen) describes seconds
to a couple of minutes, with some current-day responses served from a cache of up to five minutes.

Dune publishes no freshness figure anywhere in its documentation, and neither does
[Footprint Analytics](https://cryptomarkets.tools/tools/footprint-analytics). That is not a small gap: on a warehouse with no
stated lag, the difference between a chart that is wrong and a chart that is late is something you
have to measure yourself.

The second job is decoding, and depth is not uniform even within one product. Dune carries a full
decoded stack on EVM chains — raw transactions, logs and traces, then `logs_decoded` and
`traces_decoded`, then curated cross-protocol tables — while its Bitcoin coverage is blocks,
inputs, outputs and transactions with no decoded layer at all, because there is nothing to decode.
Footprint's coverage table lists 31 chains of which **only six carry traces**. A metric that needs
internal calls exists on a fraction of the chains a coverage count implies.

### Stage three — attribution, which is judgement all the way down

This is the stage with no measurement in it anywhere.

The chain records that address A sent to address B. It records nothing about who A is. Turning
one into the other is done with clustering heuristics plus a small hand-verified seed, and the
method has been in the public literature since 2013, when Meiklejohn and colleagues published
[A Fistful of Bitcoins](https://discovery.ucl.ac.uk/1490261/1/Meiklejohn%20et%20al%20A%20fistful%20of%20bitcoins.pdf)
at the ACM Internet Measurement Conference. Read it for the shape of the problem rather than for
its figures, because nothing about the shape has changed.

Their first heuristic is the safe one and it is a property of the protocol — "if two (or more)
addresses are used as inputs to the same transaction, then they are controlled by the same user".
Applied to the chain as it then was, it produced 5.5 million clusters, and the paper's own upper
bound on distinct users was 6,595,564. Their second heuristic, which links a transaction's inputs
to its one-time change address, is the one every product here depends on and the paper calls it
"more challenging and significantly less safe than Heuristic 1". The first attempt identified over
four million change addresses and, when checked against later behaviour, 555,348 false positives
— "13% of all labeled change addresses". Refinements drove that to 1%, then to 0.28% by waiting a
day before labelling an address and 0.17% by waiting a week.

And it still failed in the way that matters. Even after all of it, the authors report, they "still
ended up with a giant super-cluster containing the addresses of Mt. Gox, Instawallet, BitPay, and
Silk Road, among others", of 1.6 million addresses. That is the characteristic failure of
attribution: not a wrong name on one address, but four unrelated entities merged into one because
a handful of links were wrong. The paper says so in advance — falsely linking even a small number
of change addresses "might collapse the entire graph into large 'super-clusters' that are not
actually controlled by a single user".

The seed is the other half, and the leverage in it is startling. Ground truth came from
transacting with services and watching which addresses they used — accounts with 18 real-time
exchanges, 10 wallet services, 8 fixed-rate exchanges and a list of vendors. From 344 transactions
they hand-tagged 1,070 addresses, and the refined heuristic turned those into names on over 1.8
million addresses, which the paper puts at "1,600 times more addresses than our own manual
observation provided".

Every commercial label set in this catalogue is that arrangement with a bigger seed and better
engineering. What differs between them is how much of it they will tell you:

- **Glassnode** names its three label sources in a transparency notice on its exchange metrics —
  addresses the exchanges themselves disclose, public tags that pass QA, and ML clustering — says
  it tunes against false positives so reported exchange balances understate the truth, and states
  that balances are revised retrospectively when an address is added to a cluster. Exchange
  balances are Bitcoin and Ethereum only.
- **[Arkham](https://cryptomarkets.tools/tools/arkham)** publishes a confidence grade rather than evidence — verified labels
  at a stated threshold of 98% or better, entity predictions at 80% or better, distinguished in
  the interface by a badge. A badge does not survive a screenshot.
- **Bitquery** sells labels as a separate add-on and is unusually specific about where they come
  from — 169M labelled addresses across 45 label types and 12 chains, each carrying a `RecordedAt`
  timestamp, with per-user deposit addresses inferred from sweep behaviour into verified hot
  wallets and issuer-freeze labels read from Tether's and Circle's own blacklist events.
- **Nansen** puts its count at 500 million labelled addresses, and its documentation states that
  the labels endpoint returns the current set with no date range and no historical look-back. The
  label object carries a name, a category and a kind, so nothing in a response says when a label
  was applied or last checked. "Former Smart Trader" is a published label, which tells you labels
  are withdrawn; no review cadence is published anywhere.
- **Allium** publishes column-level definitions for its wallet classification and covers 400M+
  curated addresses, with no revision date for the label set. Its geographic attribution tables
  ship with a documented measurability tiering, which is more than most label sets admit to.
- **[Santiment](https://cryptomarkets.tools/tools/santiment)** has entity labels for Ethereum only, undated.
- **[Bubblemaps](https://cryptomarkets.tools/tools/bubblemaps)** does not attribute at all — it draws the transfer graph and
  leaves the interpretation to you — and its wallet labels are crowdsourced, reviewed and paid for
  by the submitter.
- **Dune, L2BEAT, growthepie, [DefiLlama](https://cryptomarkets.tools/tools/defillama), Token Terminal** and
  **[Artemis](https://cryptomarkets.tools/tools/artemis)** have no first-party address-to-entity layer at all. On Dune the
  community tables exist and are other users' work rather than a maintained product with a
  revision date.

There is one public attempt at doing this stage in the open, and it is worth knowing about as a
standard even though it labels contracts rather than exchange wallets. The
[Open Labels Initiative](https://github.com/openlabelsinitiative/OLI) defines a label as a
`tag_id` and a `value` attached to an `address` and a `chain_id`, and submits it as an attestation
that is "public, timestamped and signed by an EOA, ensuring transparency and traceability of the
contribution's source". Quality is then handled by a trust table the *consumer* supplies — a list
of attester addresses with a confidence from 0 to 1, optionally scoped per tag and per chain —
rather than by one vendor's badge. growthepie's paid Advanced tier buys contract labelling through
exactly this, which is the one place in this catalogue where you can read who made a claim.

### Stage four — the metric is a definition, not a measurement

By the time a number reaches a chart, somebody has decided what counts. That decision is usually
the largest single source of disagreement between two platforms, and it is the one stage where
several vendors do publish their working.

Start with what the chain actually emits. Under
[EIP-20](https://eips.ethereum.org/EIPS/eip-20), a token balance is contract state read through
`balanceOf`, and a transfer is an event the contract fires. The standard requires that the
`Transfer` event "MUST trigger when tokens are transferred, including zero value transfers", and
that a contract creating new tokens "SHOULD trigger a Transfer event with the `_from` address set
to `0x0`". So a naive count of token transfers counts mints, and counts zero-value spam sent to
addresses that never asked for it. Somebody has to decide to exclude those, and that somebody is
your vendor.

Active addresses is the standing example. Artemis splits it into two named metrics rather than
shipping one ambiguous one — `CHAIN_DAU` counts addresses that send a transaction on the chain,
`DAU` counts addresses using a protocol's products — and its documentation shows the pair agreeing
exactly on Ethereum, Tron and Solana for 1 August 2026. Santiment defines the same phrase the
widest way available, as the distinct addresses that participated in a transfer in the window,
senders and receivers both, which its own card notes roughly doubles a sender-only figure.
Neither is wrong. They are two metrics with one name.

Three more definitional traps the cards record:

**A dimensional split does not add up.** Artemis documents that splitting Ethereum's `DAU` by
category produced twenty categories summing to 605,380 against an undifferentiated total of
439,738 for the same day, because an address active in two categories is counted in both. Its own
instruction is to read the split as directional rather than additive, and it says plainly never to
sum open interest.

**The same word measures different objects.** L2BEAT reports value secured as a sum of canonically
bridged, externally bridged and natively minted assets, and explains at length why that is not a
TVL figure from elsewhere; it also measures activity in user operations per second rather than
transactions, on the grounds that an L2 transaction can bundle many user actions and counting them
equally flatters whoever batches hardest. DefiLlama's TVL publishes its exclusions — borrowed
coins, the protocol's own token, non-circulating and vesting tokens, native chain staking, bridge
TVL attributed to no chain — with the test written down as whether the money would truly be lost
if the protocol were hacked.

**A definition can move while the field name stays.** In July 2026 Artemis moved stablecoin
transfer volume from an adjusted figure, deduplicated with intra-exchange transfers and MEV
removed, to gross transfers minus mints and burns. Volume reads higher as a result and the API
field names are unchanged, so a chart crossing that date is two measurements. Glassnode's
changelog carries the same class of event — spot volume for BTC and ETH changing on a named day
after a methodology change, circulating supply recomputed, a holder metric redefined to drop dust
balances.

## Why nothing you pulled last quarter reproduces

The four stages are not only a source of disagreement between vendors. They are a source of
disagreement between a vendor and its own past self, because a correction at any stage rewrites
the output of every stage below it.

Nansen states that past windows may be revised for late-arriving data, data-quality corrections,
historical-price fixes, token metadata changes, sector reclassification, blacklist updates and
attribution and label-history updates — so re-running the same query over the same past week can
return different numbers because the labels moved underneath it. CryptoQuant's `/latency` response
carries a `mutable` flag that is `true` for the metrics its documentation demonstrates, which is
an unusually honest way of saying that a value you have already been served can change. Glassnode
is explicit that published series mutate as entity clustering improves and off-chain data arrives
late, and sells the fix — Point-in-Time metrics that freeze each datapoint as it was known, with a
`computed_at` field tracked since 2024.

An on-chain time series is therefore not a record of what happened. It is the current best
estimate of what happened, restated whenever any of the four stages improves.

## Nobody's pipeline is entirely their own

One more thing to trace before citing a figure — a platform's own stages may be somebody else's.

growthepie's metadata file names its upstream sources outright: L2BEAT, DefiLlama, CoinGecko and
Dune alongside its own indexing. Its maturity framework is defined with readable thresholds — a
billion dollars secured, Stage 2 and no outstanding risks for "Robust"; $150 million, Stage 1 and
180 days of age for "Maturing" — and the Stage input is L2BEAT's hand-written assessment. A
chain's maturity badge on one site is therefore partly another organisation's judgement, wired in
explicitly rather than absorbed silently, which is the honest version of a dependency and still a
dependency. growthepie's own data terms make you responsible for the upstream provider's licence
as well as its own wherever a chart names one.

DefiLlama's TVL has a price feed inside it. Its methodology states that deposits are valued almost
entirely through [CoinGecko](https://cryptomarkets.tools/tools/coingecko-api)'s API, with on-chain pool-weight pricing as a
fallback. An on-chain number that moves when a third party's price coverage moves is a reasonable
design and a thing to know before you attribute a change to the chain.

## What it costs

**The archive is the floor.** Units of terabytes, per ethereum.org, before anybody has decoded
anything. That cost is most of what an indexed-data subscription is really selling, and it is why
the cheap plans sell a rolling window instead. Bitquery's complete-history add-ons are priced per
chain — 100 to 150 USD a month for trading data and 150 for transfers, balances and holders on
the main EVM chains, 300 and 500 respectively for Solana, and 250 a month for each of six UTXO
chains — on top of a plan that starts at 49.

**Attribution is priced as its own product, everywhere.** Bitquery's entity labels are a 99 USD a
month add-on. On Nansen the API is metered in credits and a common-labels lookup costs 100 of
them against a premium lookup's 500, which means the free plan's 100 opening credits buy exactly
one; the labels endpoints are also the ones excluded from Nansen's pay-per-call rail, so the thing
the product is known for cannot be bought by the call. Arkham's Intel API starts at 100 USD a month
in credits, or 0.20 USD per credit on its per-request rail, where a single address lookup is one
credit and a batch endpoint is 250 to 1,000. Bubblemaps charges the other direction — 299 USD for
up to three community labels plus 89 for each additional one, paid by whoever wants the address
named.

**Reproducibility is an upsell.** Glassnode's Point-in-Time set requires the Professional plan at
the Full access level — the on-chain data package is 9,000 USD a year, Full adds 3,000, one seat
is included and each additional seat is 2,500 — and downgrades are not possible after the first
year. Below that, a backtest you ran last quarter will not reproduce.

**The aggregates most people came for sit above the entry plan.** CryptoQuant's on-chain data —
exchange flows, miner flows, entity flows, MVRV, SOPR — is Professional and above at 109 USD a
month, with market data on every plan; block resolution and the full history are 799 a month with
no month-to-month option. Glassnode's 99 USD a month Advanced plan is a viewing plan whose Light
API serves 14 days of history at 50 calls a day.

**Definitions, by contrast, are mostly free.** L2BEAT is free in full with no account, growthepie
is free to read and query with no key under a CC BY licence, and DefiLlama's methodology is public
on a product whose basic API needs no key. The stage that causes most of the disagreement is the
stage nobody charges for.

## What you can do about it

**Ask for the freshness figure as a number with a unit, and prefer the vendor that serves it.**
CryptoQuant's `/latency` on any v1 endpoint returns the chain delay and the processing delay
separately, plus the `mutable` flag. Glassnode publishes a confirmation policy and a recommended
wait. Dune and Footprint publish nothing, so on those two measure the lag yourself against a block
explorer on the chain you care about, before you chart anything time-sensitive — and write the
measurement down, because nothing will tell you when it changes.

**Get both definitions before you treat a gap as an error.** If two platforms differ on active
addresses, ask each one whether it counts senders, receivers or either, and at what grain. A
factor of roughly two between a senders-only count and a senders-and-receivers count is a
definition, not a bug, and both vendors are behaving correctly.

**Never sum a dimensional split unless the vendor says you may.** Twenty categories summing to
605,380 against a stated total of 439,738 is not a rounding problem; it is the same address
counted in two categories. Read a split as direction.

**Treat a label as a claim with an author and a date, and ask for both.** The good answer is a
timestamp on the label itself, as Bitquery ships, or a confidence grade, as Arkham does, or a
named provenance for each label type. The common answer is a name with neither. Where your use has
a consequence attached to naming somebody, remember what the method's own founding paper reports
about itself — a refined, carefully tuned change-address heuristic still merged Mt. Gox,
Instawallet, BitPay and Silk Road into one cluster of 1.6 million addresses.

**Ask when the label set was last revised, and treat unlabelled as unlabelled.** An address
labelled as an exchange wallet two years ago is still labelled that way after the exchange stopped
using it, and an exchange-balance series that its own vendor describes as a lower bound is a lower
bound in your chart too.

**If the answer has to reproduce, buy immutability explicitly or build it.** Point-in-Time is a
line item, not a default. The free version of it is writing every response you rely on to your own
store with the date you fetched it, which turns a vendor's restatement from an invisible change
into a diff you can see.

**Pin the definition by watching the changelog, and diff when the changelog is thin.** A field
whose name survives a definition change will not tell you it moved. Re-pull one fixed historical
window on a schedule and compare it to your stored copy; where a vendor's public changelog records
nothing for ten months, as Artemis's does between 30 July 2025 and 27 May 2026, that diff is the
changelog.

**Own the stage you cannot accept somebody else owning, and only that one.** If attribution is the
risk, buy rows and label them yourself — Dune, Bitquery and Allium sell indexed chain data with no
opinion attached, and the trade is a query you have to write and maintain. If the definition is
the risk, buy a platform that publishes one — L2BEAT, DefiLlama, growthepie, Artemis and Token
Terminal all do, and three of them at no charge. If freshness is the risk, the node is the stage,
and that is terabytes.

**Trace whose numbers you are actually citing.** Before a figure goes into a report, check whether
the platform computed it or consumed it. A chain's maturity badge may carry another organisation's
Stage judgement; a TVL figure may carry a third party's price coverage. Both are legitimate and
both should be named in your footnote rather than theirs.

**Know the threshold below which none of this applies.** One chain, a published definition, a
daily bar, and a question about direction rather than level — that case is covered by the free
tier of half this category, and none of the four stages will hurt you. The stages start to matter
when the number is going in front of somebody else, when it has to be the same number next
quarter, or when it names a person.

The [on-chain analytics category page](https://cryptomarkets.tools/categories/onchain-analytics) sorts the seventeen products
here into the three shapes they come in — a SQL surface over an index, a labelled dashboard, and a
curated metric set — which maps onto which of these four stages you are buying and which you are
keeping.

## Tools this bears on

- [Dune](https://cryptomarkets.tools/tools/dune.md) — SQL over 100+ indexed chains, with the API on every plan including the free one.
- [Glassnode](https://cryptomarkets.tools/tools/glassnode.md) — A curated metric set in a charting studio, with the API on a separate annual plan.
- [Nansen](https://cryptomarkets.tools/tools/nansen.md) — A labelled view of the chain — who is buying, not just which address.
- [Artemis](https://cryptomarkets.tools/tools/artemis.md) — Chain and protocol fundamentals — fees, revenue, users — one definition everywhere.
- [CryptoQuant](https://cryptomarkets.tools/tools/cryptoquant.md) — Exchange reserves, miner flows and MVRV for four chains, as charts, alerts and an API.
- [L2BEAT](https://cryptomarkets.tools/tools/l2beat.md) — Ethereum L2 metrics with the risk assessment behind them, MIT-licensed and free.

## FAQ

### Why do two on-chain dashboards show different numbers for the same metric?

Because they disagree somewhere upstream of the chart. Four stages sit between a block and a headline figure — which node served the history, how the indexer decoded and finalised it, which addresses an attribution layer assigned to which entity, and what the metric's definition counts. Only the last of the four is usually published, so a difference that looks like an error is normally a definition or a label set.

### What is entity attribution and can I check it?

It is the step that turns a hex address into "Binance hot wallet" or "a fund". It runs on clustering heuristics plus a hand-verified seed set, and no platform in this catalogue publishes the evidence behind an individual label. Arkham grades its labels by confidence, Bitquery timestamps each one, and most of the rest ship a name with neither a date nor a provenance note.

### Do I need an archive node to run on-chain analytics myself?

For anything historical, yes or its equivalent. A full Ethereum node prunes old state and keeps roughly the most recent 128 blocks, so a balance at an old block needs an archive node, and ethereum.org puts that at units of terabytes. That cost is most of what an indexed-data subscription is actually buying.

### Can I reproduce an on-chain number I pulled last quarter?

Usually not, unless you paid for that or stored it yourself. Published series are revised — for late data, corrected prices, and changed entity labels — and CryptoQuant marks affected metrics with a mutable flag. Glassnode sells the frozen version as Point-in-Time, on its Professional plan at the Full access level.

### Is a free on-chain dataset worse than a paid one?

Not on definitions, which is the stage that causes most of the disagreement. L2BEAT, growthepie and DefiLlama publish their methodology in full and charge nothing for the data. What free almost never includes is entity labels, and what it rarely includes is a stated freshness figure.

## Sources

1. [Nodes and clients — full, archive and light nodes](https://ethereum.org/en/developers/docs/nodes-and-clients/) — ethereum.org, 2026-07-13
2. [Proof-of-stake — slots, epochs, checkpoints and finality](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/) — ethereum.org, 2026-08-31
3. [EIP-4844 — Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) — Ethereum Improvement Proposals, 2022-02-25. Status Final, which freezes the text — this page cites what the specification says, not any client's current retention setting.
4. [EIP-20 — Token Standard](https://eips.ethereum.org/EIPS/eip-20) — Ethereum Improvement Proposals, 2015-11-19. Status Final, which freezes the text — an ERC-20-compliant token emits the Transfer event exactly as specified here.
5. [A Fistful of Bitcoins — Characterizing Payments Among Men with No Names, ACM IMC 2013, sections 3 and 4](https://discovery.ucl.ac.uk/1490261/1/Meiklejohn%20et%20al%20A%20fistful%20of%20bitcoins.pdf) — Association for Computing Machinery, 2013-10-23. Cited for the method it defines rather than its 2013 figures — a measurement of a past state of a chain does not date the way a fee table does.
6. [Open Labels Initiative — label schema, label pool and label trust](https://github.com/openlabelsinitiative/OLI) — Open Labels Initiative, read 2026-09-21

*Last updated 2026-09-21. A reference page, corrected in place — not a dated post.*