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.

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, "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 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 puts its own catalogue at 100+ chains and 3+ petabytes. growthepie says it indexes most of its own data via RPCs.

The archive is also where the cheap plans stop. On 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, 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 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 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 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 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 puts its SQL product about an hour behind the chain and its warehouse shares one to three hours. 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. 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 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 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 has entity labels for Ethereum only, undated.
  • 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, Token Terminal and 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 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, 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'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 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

Cards in the catalogue where what is above changes the decision.

  • Dune

    SQL over 100+ indexed chains, with the API on every plan including the free one.

    $75/moFree tier

  • Glassnode

    A curated metric set in a charting studio, with the API on a separate annual plan.

    $99/moFree tier

  • Nansen

    A labelled view of the chain — who is buying, not just which address.

    $0.01/moFree tier

  • Artemis

    Chain and protocol fundamentals — fees, revenue, users — one definition everywhere.

    $100/moFree tier

  • CryptoQuant

    Exchange reserves, miner flows and MVRV for four chains, as charts, alerts and an API.

    $39/moFree tier

  • L2BEAT

    Ethereum L2 metrics with the risk assessment behind them, MIT-licensed and free.

    FreeFree tierOpen source

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 ethereum.org,
  2. Proof-of-stake — slots, epochs, checkpoints and finality ethereum.org,
  3. EIP-4844 — Shard Blob Transactions Ethereum Improvement Proposals, . 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 Ethereum Improvement Proposals, . 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 Association for Computing Machinery, . 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 Open Labels Initiative, read

The catalogue next door

This page is background, not a listing. The products it bears on are in On-chain Analytics Platforms, each filled in against the same schema, with the fields to narrow it yourself.

Last updated . Corrected in place: this is a reference page, not a dated post.