The right explorer depends on the chain

Why state models matter more than logos

Every chain page on this site opens with a state model, because that single property determines more about how you read an explorer than anything else. There are essentially five in use across the networks we cover, and once you can recognise them the interfaces stop being surprising.

The practical consequence is that the same word means different things across these models. "Balance" is a stored number on an account chain and a computed sum on a UTXO chain. "Confirmed" means a block on Bitcoin, a slot on Solana, and a sequencer receipt on a rollup that has not yet settled to Ethereum. Our guide on checking confirmations works through where those differences actually bite.

The second recurring theme is asynchrony. On TON, NEAR, Polkadot and every rollup, one user action becomes several on-chain records with different identifiers, and searching for the wrong one on the wrong chain is the single most common reason people believe funds have vanished. It is nearly always a lookup problem rather than a loss.

What each chain page covers

The same four things, in the same order, so you can move between them without relearning the layout.

First, the explorers that handle that chain properly, ranked, with a line on what each one is actually for rather than a feature list. Second, the structural quirk that catches people out — the thing that is true of this chain and not of others, and that no explorer explains on the page where it bites. Third, the practical consequences of that quirk for anyone sending or receiving value. And fourth, the chain-specific version of questions people ask everywhere: how many confirmations, why did this cost what it cost, where did my tokens go.

We have deliberately not written the same page fourteen times with the names changed. The Bitcoin page spends most of its length on the fee market and change outputs, because those are what Bitcoin users actually hit. The TON page is mostly about asynchronous messages, because that is what breaks on TON. The Monero page is largely about what an explorer cannot show you, because that is the honest subject.

Which chains are missing, and why

Fourteen is not an attempt at completeness and it is not a ranking of importance. It is the set where two conditions hold: there is real search demand for explorer information, and there is something genuinely worth saying about how the chain reads.

Several large networks are absent for the second reason. Most EVM chains read identically to Ethereum — same addresses, same tooling, same explorer behaviour — so a separate page would be the Ethereum page with a different chain ID. Where an EVM chain does differ in a way that matters, such as Base settlement or Polygon checkpointing, it gets its own page.

Others are covered inside a review rather than a chain page. Avalanche's three-chain architecture is explained in our Snowtrace review, Polkadot's governance and XCM in Subscan, NEAR's receipt trees in NearBlocks, Starknet's account abstraction in Starkscan, and Hedera's service model in HashScan. The explanation exists; it just lives next to the tool rather than on its own page.

If a chain you care about is missing and there is something specific about reading it that we have not covered, tell us. We add pages when there is something to say, not to fill a list.

The mistake that spans every chain here

One pattern appears on more of these pages than any other, and if you take a single thing from this hub it should be this.

Whenever a system is asynchronous or spans two chains, one user action becomes several on-chain records with different identifiers. The identifier does not carry across. So searching for the hash you were given, on the chain you think you are on, returns nothing — and the reasonable conclusion is that the funds have vanished.

They almost never have. It happens on Base and every other rollup, where a deposit on Ethereum and its credit on the rollup are separate transactions. It happens on TON, where one action becomes a chain of messages. It happens on Polkadot with XCM transfers, on NEAR with receipt trees, and on Avalanche when you move between its three chains.

The fix is always the same: establish which chain you are actually on, and find the tool that links both halves. Some explorers do this explicitly — Arbiscan's cross-chain message tracker and Subscan's XCM view are the two clearest examples. Most do not, and leave you to match by amount and timestamp.

Before concluding that anything is lost, check that you are searching for the right identifier on the right chain. In our experience that explains the overwhelming majority of these cases, and it takes under a minute.