Block explorer chain coverage, registered vs fresh-indexed
Chains where each block explorer family serves a working indexer, probed daily against the vendor's own machine-readable registry, with a separate view over the 50 most active mainnets.
This benchmark measures how many blockchains each block explorer family actually serves, not how many its marketing page claims. Every family gets the same daily probe. one call to its own machine-readable registry (the registered count) and one freshness probe per registered mainnet, where a chain only counts as verified when the latest indexed block is younger than 60 minutes. A reachable web server with a stalled indexer does not count. Raw chain counts reward hosting ghost rollups, so a third number is published alongside. coverage of the 50 most economically active mainnets, which is the question integrators actually ask. Marketing claims in this space disagree wildly, the same vendor is cited at 100+, 800+ or 3000+ chains depending on the page, and no other source verifies any of these numbers on a live cadence.
Methodology
We benchmark block explorer APIs on three numbers per family, once per day. registered, the mainnet count the vendor self-declares through a machine-readable surface (Chainscout registry, Etherscan chainlist, Routescan blockchains endpoint), verified, the number of those chains whose explorer API returned a latest indexed block younger than 60 minutes, and top-50, how many of the 50 most active mainnets pass the same freshness gate. Registries rot and raw counts can be inflated by ghost chains; the three numbers together separate the claim, the catalog, and the working product. The cohort is limited to explorers with free, reproducible API access.
Frequently asked
Which block explorer supports the most blockchains?
Blockscout currently leads at 195 fresh-indexed mainnet chains across 4 measured families. Fresh-indexed means the explorer's own API returned a latest block younger than 60 minutes on that chain within the last daily cycle, so the leaderboard reflects working indexers rather than registry entries or marketing claims, which for the same vendor range from 100+ to 3000+ chains depending on the page.
Why three numbers per explorer?
Because they answer different questions. registered is what the vendor self-declares through its own machine-readable surface and rots as chains die or migrate. verified is what the daily probe demonstrated: a latest indexed block younger than 60 minutes. top-50 restricts the same gate to the 50 most economically active mainnets, because raw chain counts reward hosting ghost rollups and the integrator question is whether the chains people actually use are covered.
Does a Blockscout instance run by a chain team count for Blockscout?
Yes, with the distinction kept auditable. Blockscout is open source and most instances are operated by chain teams; the registry's hostedBy field is preserved by the harness so anyone can split vendor-run from chain-run. The count measures the software family's working footprint, which is exactly the claim being verified, and the same rule benefits every family equally: Routescan and Etherscan run their own indexers and get credit for every chain those serve.
Why is a reachable explorer not automatically verified?
Because the failure mode that matters is the silent one: a web server that answers 200 while its indexer stalled hours or weeks ago. The probe reads the timestamp of the latest indexed block from each family's own API and only counts chains where it is younger than 60 minutes. The window tolerates slow block producers while still catching stalled pipelines, and it can be tightened as the cohort matures.
How often are the counts refreshed?
Once per day, roughly 600 spaced calls across the cohort, all on free surfaces. A failed or quota-truncated cycle publishes nothing and the previous values carry forward, so a temporary outage never zeroes a family's row.
Source code github.com/ChainBench/OpenChainBench/tree/main/harnesses/explorer-chain-coverage