How we measure chain throughput

Every transactions-per-second figure on RampAtlas is counted from recent blocks on a chain's own public node, not taken from its marketing.

That distinction is the reason Chains exists. Throughput is crypto's most quoted number and its least comparable, because most published figures are ceilings rather than readings.

Measured, not maximum

A theoretical maximum is what a design permits under controlled conditions with a cooperative workload. It is a useful engineering number, a poor comparison, and what a project prints on its own site. No chain on our leaderboard ranks on a claim it made about itself.

What we publish instead is realized throughput: the transactions a network confirmed inside a window we sampled, divided by that window's length. The window is printed next to the number, so the figure reads as a rate over a stated period rather than as a property of the chain.

The arithmetic is conservative in one place. The window runs from the oldest block in the sample to the newest, and that oldest block's own transactions are not counted, because they confirmed at the start of the window rather than during it. Average block time is the mean gap between consecutive blocks in the same sample.

How one measurement is taken

A daily run walks back from the chain tip through recent blocks on the chain's own free public endpoint. Everything happens server side and no endpoint we read requires an API key. The walk stops when the sample covers the target window or hits the block ceiling, whichever comes first, and is abandoned if the node has not answered inside the timeout.

There is one adapter per chain family, because a full node on Solana, an XRP Ledger server and a Cosmos validator do not answer in the same shapes. A chain that produces blocks on several parallel shards at once, as TON's basechain does under load, is handled as one sequence per shard.

A chain with a second public endpoint of the same family gets one retry there, and only when the first produced no number at all. The spare is never read to replace a figure we already have, so a run cannot quietly keep whichever node reported the more flattering rate. Which endpoint answered, and why the first did not, both end up in the note on the chain's page.

What the count includes, and what it leaves out

Chains do not define a transaction identically, and normalizing the differences away would hide them. Each measurement carries a note saying what the counter counted.

Solana is the clearest case. Solana's transaction count includes vote transactions, which are consensus messages between validators rather than user activity, and they dominate the total, so the Solana page also gives the rate excluding votes. Aptos commits a block-metadata and a state-checkpoint transaction with every block, and its note gives the rate with those two removed. Stellar counts successful transactions rather than the larger operation count Horizon also reports. On TON the masterchain is excluded, because it carries consensus traffic rather than user transactions.

None of it is corrected silently: the adjustment or the caveat is stated beside the figure.

Why a chain can be unmeasured

Three things produce a chain with no reading. There may be no adapter for its family yet, there may be no public endpoint recorded for it, or the node simply did not answer: a timeout inside the budget, an error, or a response shape we do not recognize.

Failure is soft. The adapter returns empty fields plus a note explaining why, the run writes the snapshot anyway, and the chain appears on the leaderboard as unmeasured rather than vanishing from it. Measured chains rank by throughput, unmeasured chains sort after them alphabetically, and the hub lists each by name with the reason the run recorded. A dash on its own reads as a zero, and naming the endpoint that refused is what keeps the ranking honest about what is missing from it.

A chain page whose newest sample has passed 120 days stops being indexed too, under the same freshness rule as the rest of the site.

Where value locked and fees come from

Two columns on the leaderboard are not ours to measure. Total value locked and 24-hour network fees come from DefiLlama, and every page printing them says so.

Value locked is a direct lookup, matched per chain by display name. Fees are harder: the free endpoint publishes no per-chain total, only per-protocol 24-hour breakdowns keyed by DefiLlama's internal chain slug, which is not the display name and has no published mapping. We derive that pairing from the same response rather than guessing, and a chain no protocol reports fees for is recorded as having no figure rather than zero fees. Ethereum and Cardano both carry these two columns beside the throughput reading, each dated to the run that produced it.

Frequently asked questions