Methodology
How Blocktivity measures blockchain activity — transaction definitions, data statuses, formulas, and the staleness state machine.
What is this / how to read it
Blocktivity is a public scoreboard that ranks blockchains by on-chain transaction activity — the number of transactions recorded on each chain per day. The goal is simple: show which blockchains people actually use, in real time, with honest data.
The leaderboard shows every tracked chain ranked by their 7-day average daily transaction count. Each row displays:
- 24h Tx — the total number of transactions recorded in the last 24 hours
- 7d avg Tx — the sorting metric: the mean of the last 7 daily transaction counts
- 30d sparkline — a 30-day trend of daily transaction counts
- Status badge — how much confidence we have in the number (see Data statuses)
Expanding a row reveals secondary metrics (X'tivity, Potential), market data, and a full trust block with the data source, transaction definition, and last-update time.
Why Tx is the headline
The previous version of Blocktivity ranked by Operations — a broader count that includes internal protocol actions, system events, and anything the chain itself decides to call an "operation." Operations vary wildly in definition across chains, making cross-chain comparison misleading.
Transactions are the cleaner signal. Every chain has a concept of a user-submitted transaction — the thing a user signs and broadcasts. It's the most universal definition of "activity" and the most comparable across chains. Operations are no longer collected or displayed anywhere on the site: ranking on one metric and showing another invited exactly the cross-chain comparison we just called misleading.
Different chains still count transactions differently. That's why every chain on Blocktivity discloses its exact transaction definition — see the section below.
Transaction definition
Blocktivity does not force chains into a single transaction definition — different chains count differently and that is acceptable. What Blocktivity does require is disclosure. Every listed chain must declare exactly how it counts, using these 7 fields:
| Field | Options | Description |
|---|---|---|
| successful | included / excluded | Are successful transactions counted? |
| failed | included / excluded | Are failed transactions counted? |
| system | included / excluded | Are system/protocol-internal transactions counted? |
| internal | included / excluded / n-a | Are internal (sub-call) transactions counted? Use n-a if not applicable. |
| batched | as-batch / individually | Batched transactions: counted once or per inner transaction? |
| rollup | l2-user-tx / l1-settlement / both / n-a | For rollup chains: which layer is counted? |
| window | utc-day / rolling-24h | UTC calendar day or rolling 24-hour window? |
Blocktivity's preferred definition
Successful user-submitted transactions over the last 24 hours, excluding failed and system transactions where possible. This is what we recommend — but not what we mandate. Disclosure is what matters.
Data statuses
Every chain on Blocktivity carries a data-status badge. It tells you how the number was obtained and how much confidence you can place in it. Colour is paired with a text label — colour is never the only signal.
Foundation / official explorer / ecosystem team provides it
Provider exposes block/range endpoints enabling automated checks
Daily numbers given, limited auditability
Blocktivity temporarily uses a public explorer/third-party
Added by Blocktivity to bootstrap; not yet claimed
Source failed / not updated recently
Challenged or inconsistent
Source broken/invalid/abusive — out of main ranking, coin page remains
30d+ dead — historical page only
History coverage
A data status says who the number comes from; coverage says how far back we have it. The two are separate axes, tracked independently.
Activity recorded back to the chain’s genesis, from the same source that reports it live
Activity recorded well before this chain was listed, but not back to genesis
Activity recorded from the day Blocktivity listed this chain
Backfilled history comes from the same endpoint that reports a chain's activity live, so the older numbers use that chain's own definition of a transaction. We do not splice a second provider's series onto ours.
Coverage never affects rank or the credibility gate.
X'tivity & Potential
These are two secondary metrics derived from the primary Tx data, both computed from Transactions. Bitcoin (BTC) is the reference chain: it sits at 1 on both scales.
X'tivity
Transaction activity relative to Bitcoin. Formula:
xtivity = chain_tx_7d_avg / btc_tx_7d_avg
A chain with X'tivity 12 is doing 12× more 7-day-average transactions than Bitcoin. Display format: <0.1 → 2 decimal places; <1 → 1 decimal place; else integer.
Potential
Transaction volume per unit of market capitalisation, measured against Bitcoin and then placed on a 1–99 scale. First the raw ratio:
ratio = (chain_tx_7d_avg / chain_mc) / (btc_tx_7d_avg / btc_mc)
That ratio is unbounded — it can reach the millions — so it is compressed onto a bounded score. The curve is asymptotic: 100 is unreachable, and each further point costs progressively more activity per unit of market cap. A ratio of 1,000 scores 50; 10,000 scores 76; 1,000,000 scores 97.
A high Potential means a chain is doing a lot of transactions relative to its market cap compared to Bitcoin. Bitcoin itself scores 1, and any chain with more market cap per transaction than Bitcoin also scores 1 — it is the floor of the scale. Null when market cap is zero or unavailable.
These metrics are computed from 7-day average Tx so single-day spikes (which may be anomalous) don't distort them. Potential is a display metric only. It has no bearing on rank and no bearing on the credibility gate: a chain is never held out of the main table for being cheap to transact on.
Staleness state machine
When a chain's data source stops responding, Blocktivity automatically transitions it through a staleness state machine. States are evaluated daily.
| Time since failure | State | What happens |
|---|---|---|
| 0 – 24 h | warning | Auto-retry on next collector run; data still shown as-is. |
| 24 – 72 h | Stale | Marked stale on the site; provider notified (Phase 3). |
| 3 – 7 d | Hidden | Removed from the main ranking; coin page still accessible. |
| 7 – 30 d | delisted | Out of all active leaderboards; restorable by fixing the source. |
| 30 d + | Archived | Historical coin page only; no longer in any active ranking. |
A chain can recover from any state by fixing its source endpoint. It re-enters the collector cycle on the next run and transitions back toward active status.
FAQ
Why is my chain not listed?
We list chains that provide a stable, machine-readable daily transaction count via an API endpoint. If your chain is not listed, you can submit it via Add Your Chain. Newly submitted chains typically appear within a few business days.
Why is a chain's data marked "Stale"?
Stale means Blocktivity's automated collector could not fetch a fresh transaction count from that chain's endpoint within the expected window. The last known value is still shown, but the staleness badge tells you it may be outdated.
Why do some chains appear in an "Emerging & Unverified" section instead of the main table?
Chains in that section have not yet cleared the credibility gate (minimum market cap, 24-hour volume, and anomaly checks). They are listed with full transparency but the gate prevents chains with fabricated or unverifiable activity from dominating the main ranking.
Does a higher X'tivity or Potential score mean a chain is "better"?
Not necessarily. X'tivity measures transaction activity relative to Bitcoin (BTC = 1). Potential measures transaction volume relative to market cap, normalised to BTC = 1. Both are secondary lenses — the primary metric is raw Tx. A high Potential simply means the chain is doing a lot of transactions relative to its market cap.
The number shown for a chain looks wrong — too low or too high. What now?
Check the transaction definition first: chains count different things, and most disagreements are a definition mismatch rather than an error. We publish, per chain, whether failed, system and internal transactions are included, whether batched transactions count once or per inner transaction, which layer is counted for rollups, and whether the window is a UTC day or a rolling 24 hours. If it still looks wrong, the fastest fix is free — the foundation, official explorer or core team can claim (or re-claim) the chain and supply their own endpoint and definition, which also upgrades the chain to the Official API status label.
What stops a chain from spamming transactions to climb the ranking?
We count transactions and do not judge whether one was "economically meaningful" — that would be our opinion dressed up as data. Instead, several mechanisms make an inflated number hard to cash in: ranking uses the 7-day average rather than a single day; a chain whose 24h count jumps past 10× its own 7-day median is flagged as an anomaly and pushed out of the main ranking until the level persists; and the credibility gate requires a market-cap floor, a 24-hour volume floor and a plausible transactions-per-market-cap ratio — enormous claimed activity next to almost no market value is the classic fake-chain tell. Chains that fail are shown openly in Emerging & Unverified with the failed checks listed on their coin page, never deleted. If you can point at a specific chain and window with evidence, send it in; a chain can be marked Disputed while we re-check its source.
Does Blocktivity verify the numbers?
We fetch exactly what the chain's API endpoint returns. We do not independently index every chain. The data-status label tells you the confidence level: Official API means the chain's own foundation supplies it; Auditable API means we run automated cross-checks; Self-Reported means we take the number on trust. Blocktivity is transparent about this — that's the point.
Is ranked position for sale?
No. Sponsors get a highlighted visual treatment — a label and visual cue — but their rank in the table is determined by their actual transaction data, not their sponsorship. We never sell rank position.
Why do some chains have full history and others don't?
It depends on whether the chain's data provider serves a date-range endpoint. We ask every provider for one, and the Full history badge appears as soon as one exists — no blame, no pressure, just an honest reflection of what we can verify.
See also: API docs for the technical submission spec, About for the full manifesto, and Add Your Chain to submit a listing.