Why an open-source explorer matters
An explorer is an interpretation. It reads a chain, decides how to aggregate it, and renders the result. Every one of those decisions could be wrong, and with a closed explorer you have no way to check — you either trust the output or you run a node and reconcile by hand.
With Blockscout you read the indexer. When a balance looks wrong, you can find the code that computed it. When two explorers disagree, you can see what one of them is doing differently. That is not a theoretical benefit: explorers disagree about token balances more often than people assume, usually over how they handle non-standard contracts that emit irregular transfer events.
The second reason is economic. Etherscan decides which chains it supports, and that decision is commercial. A new rollup cannot simply buy its way onto the list. Blockscout means a chain can have a credible explorer on the day it launches by running one, and that has made it the de facto standard for the entire rollup ecosystem.
The API key change, and what it broke
On 1 July 2026, Blockscout moved API traffic onto a keyed Pro API. Code that had been calling hosted instances anonymously stopped working.
The free tier is not stingy — roughly 100,000 credits a day at five requests per second, which covers most non-commercial use comfortably. But the change matters for one specific reason that has nothing to do with volume: a keyed API cannot be called from browser code. Anything that was calling a Blockscout instance directly from a front end now needs a server in between.
This is the same constraint Etherscan has always had, and it is why the number of genuinely browser-callable explorer APIs keeps shrinking. The survivors are Blockstream, mempool.space, Blockchair and 3xpl. Our API comparison tracks the current state, because it has now changed twice in eighteen months.
The one silver lining: if you self-host, none of this applies. Your instance, your rules, no key.
Instance quality varies, and that is the real catch
Blockscout's greatest strength creates its most common problem. Because anyone can run an instance, the explorer you land on for a given chain might be operated by the Blockscout team, by the chain foundation, by a third-party infrastructure provider, or by a single person who set it up eighteen months ago.
The symptoms of a neglected instance are recognisable: indexing lag of several thousand blocks, token balances that do not reconcile, contract verification that fails on valid input, or an old release with fixed bugs still present. None of this reflects on the software; all of it reflects on that deployment.
Two quick checks before you trust an instance. Compare its latest block height against the chain's own RPC or a second explorer — a gap of more than a few blocks means it is behind. And look for the version indicator in the footer; a release well over a year old is a warning.
| Symptom | Likely cause | What to do |
|---|---|---|
| Recent transactions missing | Indexer lagging the chain tip | Check tip height against the chain RPC; wait or use another instance |
| Token balance looks wrong | Non-standard transfer events, or an incomplete token re-index | Cross-check on a second explorer before acting on it |
| Verification rejects valid source | Compiler version unavailable on that instance | Try Sourcify, or verify on a differently-operated instance |
| Contract shows as unverified elsewhere | Verification is per-instance, not global | Re-verify on each instance you need it on |
Contract verification, and where it lags
Blockscout verifies contracts properly — flattened Solidity, standard JSON input, multi-part source, Vyper, and integration with Sourcify, the decentralised verification repository. Mechanically it is sound.
The gap is coverage, and it is a network effect rather than a technical failure. When a project deploys on Ethereum mainnet it verifies on Etherscan, because that is where people will look. It may or may not also verify on Blockscout. The result is that a contract can show as verified on one and unverified on the other, which looks alarming and usually means nothing.
The Sourcify integration is the interesting counter-move, because Sourcify verification is portable — verify once, and any explorer that reads Sourcify can show the source. That is the right architecture, and it is slowly gaining ground. On rollups, where Blockscout is often the only explorer, coverage is naturally much better.
Running it yourself
This is the use case Blockscout is actually built for, and it shows. The stack is the indexer, a PostgreSQL database and the Phoenix web application, with Docker Compose configurations published for common setups.
You supply an archive node for the chain. That is the real cost and it dwarfs everything else — an Ethereum mainnet archive node is a multi-terabyte commitment. For a young rollup with a short history it is entirely tractable, which is precisely why rollups adopt this pattern: the chain is small, the explorer is free, and it is running before the first user arrives.
For an individual, self-hosting Blockscout for Ethereum mainnet is a serious undertaking and probably the wrong call. Otterscan against an Erigon node is far lighter if the goal is private lookups for yourself. Our self-hosting guide compares them on disk, memory and setup time.