What Is a Blockchain Explorer? How They Work and What Powers Them

You deploy a contract from Hardhat. The terminal prints a transaction hash. You paste it into Etherscan and the page loads: status Success, gas used, the contract address that was created, and a list of internal calls you do not remember writing. One of them is a DELEGATECALL into a proxy you forgot was wired up by your deploy script. Five seconds of clicking, and you have a complete picture of what actually happened on-chain.

That experience feels lightweight, but a lot of infrastructure sits behind it. The page is not querying a node when you load it. It is reading a Postgres or ClickHouse database that was filled by an indexer running constantly against archive RPC endpoints, decoding every block, every receipt, every trace, every event log against ABIs the explorer keeps up to date. The "search engine for blockchains" framing is correct, but it underplays the engineering.

This guide is for builders. It covers what an explorer actually is, the node-indexer-UI pipeline that powers one, what data each layer is responsible for, the open vs closed-source landscape in 2026, and what changes if you decide to run your own.

What Is a Blockchain Explorer?

A blockchain explorer is a web application and API that lets you look up blocks, transactions, addresses, contracts, and events on a specific blockchain. It works by ingesting raw chain data through a node, decoding and storing it in a structured database, and exposing the result through a UI and a set of APIs.

The "search engine" analogy is useful but incomplete. When you type a transaction hash into Etherscan, the page is not running a eth_getTransactionByHash against a live node and rendering the result. It is reading a pre-indexed Postgres row that was written when the block containing that transaction was processed by an indexer hours, days, or years ago. The chain is the source of truth. The explorer is a derived, denormalised view of the chain optimised for reads.

It also helps to be precise about what an explorer is not:

• Not an RPC node. A node serves raw JSON-RPC. An explorer consumes RPC and presents decoded, enriched data. See What is RPC in blockchain for the underlying protocol.
• Not an indexer. Indexers like The Graph, Ponder, Goldsky, Envio, Subsquid, and SubQuery turn chain events into application-specific databases. Explorers are general-purpose indexers with a UI bolted on. Most explorers contain an indexer; standalone indexers do not contain an explorer.
• Not an analytics platform. Dune and Nansen layer SQL, entity labels, and dashboards on top of indexed chain data. They answer "which addresses have done X across these protocols," not "what happened in this transaction."

If you keep those three distinctions straight, the rest of the architecture is easier to reason about.

How a Blockchain Explorer Actually Works

Almost every modern explorer is built on the same three-layer model:

Node (data source) -> Indexer (structured database) -> UI / API (presentation)

Each layer has different scaling characteristics, different failure modes, and different infrastructure costs. Treating them as one box is the main reason developers underestimate how much work an explorer is.

1. The node layer

At the bottom is one or more blockchain nodes. For an EVM explorer this is typically an archive node running Geth, Nethermind, Reth, Erigon, or Besu, exposing JSON-RPC over HTTP and WebSocket. The methods the indexer relies on most:

• eth_getBlockByNumber and eth_getBlockByHash to fetch block headers and transaction lists
• eth_getBlockReceipts to pull every transaction receipt for a block in a single call (a much cheaper pattern than per-transaction eth_getTransactionReceipt)
• eth_getLogs for historical event log range scans during backfill
• eth_subscribe("newHeads") over WebSocket to push new blocks the moment they are produced
• debug_traceTransaction and debug_traceBlockByNumber (Geth-style) or trace_block and trace_transaction (Parity/Erigon-style) for internal transactions and call traces
• eth_getCode and eth_getStorageAt for contract bytecode and slot-level state
• The Beacon API on Ethereum post-merge for validator, attestation, and consensus-layer data

Non-EVM chains expose different methods. Substrate uses chain_getBlock and state_getStorage, Solana uses getBlock and getTransaction with commitment levels, Bitcoin uses the bitcoind REST/JSON interface. The role of the node layer is the same in every case: be the deterministic source of truth that the indexer reads from.

2. The indexer layer

The indexer is where most of an explorer's actual code lives. It runs in two modes simultaneously:

• Backfill. Process historical blocks from genesis (or a checkpoint) up to the chain tip. On Ethereum this is roughly 22 million blocks, on Solana hundreds of millions of slots. Backfill is bound by your RPC throughput and your database write speed, not by the chain.
• Realtime. Subscribe to new heads, ingest each new block as it lands, and forward-fill the database. On Ethereum this is one block every 12 seconds, on a high-throughput L2 it can be several blocks per second.

For each block, an indexer typically does the following:

1. Fetch the block header and the full transaction list
2. Pull all receipts for the block in one eth_getBlockReceipts call
3. For each transaction, decode the input field by looking up the first 4 bytes (the function selector) against a database of known ABIs
4. For each event log, take topics[0] (the keccak256 hash of the event signature), look up the matching ABI, and decode the indexed and non-indexed parameters
5. Fetch traces (debug_traceBlockByNumber or trace_block) and store every internal call: CALL, DELEGATECALL, STATICCALL, CREATE, CREATE2, SELFDESTRUCT
6. Classify token transfers by matching log signatures: ERC-20 Transfer(address,address,uint256), ERC-721 Transfer(address,address,uint256) (same signature, different indexing), ERC-1155 TransferSingle and TransferBatch
7. Resolve ENS or other naming services for known addresses
8. Write everything into the database in a single transaction so the block is either fully indexed or not at all

The standard storage backend is PostgreSQL. Blockscout, the dominant open-source EVM explorer, runs on Postgres v17+. Heavier analytical workloads use ClickHouse. 3xpl is built on ClickHouse and exposes raw SQL access. Bitcoin's mempool.space uses MariaDB. The pattern is the same regardless of engine: append-only writes during indexing, read-heavy from the API layer.

The hardest part of the indexer is reorg handling. When the chain reorganises, the canonical block at height N changes. The indexer has to walk back parent hashes, mark orphaned blocks and their transactions as invalid, and re-index the new canonical chain. Post-merge Ethereum makes this easier because finality is explicit (roughly 2 epochs, ~12.8 minutes), and anything older than that will not reorg. On chains without explicit finality the indexer has to keep a rolling window of "tentative" blocks that can be rewritten.

3. The presentation layer

On top of the indexer sits the UI and the API. The UI is a frontend over the same APIs everyone else calls. The APIs are where most production traffic actually goes:

• Etherscan exposes a REST API with method-style query parameters (?module=account&action=balance&...)
• Blockscout exposes both a REST v2 API and a GraphQL endpoint at /api/v1/graphql
• 3xpl exposes a ClickHouse SQL interface
• mempool.space exposes a REST + WebSocket API documented openly

Most teams hit the API more often than they hit the UI. Block explorers are read by other infrastructure: bots checking confirmations, frontends rendering activity feeds, compliance tools labelling addresses, and CI pipelines verifying contracts after deploys.

Why Archive Nodes and Trace Methods Matter

The indexer description above assumed the node could answer historical and trace queries. That assumption is the expensive one.

A standard full node only retains state for the most recent ~128 blocks on Ethereum. After that, you can still read block headers and receipts, but eth_call and eth_getStorageAt against an old block will fail. Explorers serve historical state queries constantly ("balance at block 14,000,000", "storage slot 3 of this contract one year ago"), so the node behind an explorer must be an archive node that retains the full state trie from genesis.

Archive node footprints are non-trivial:

• Ethereum archive: ~12 TB on Geth, ~3.5 TB on Erigon, growing continuously
• Arbitrum archive: 38+ TB and growing roughly 3 GB per day
• Solana archive: hundreds of TB depending on retention strategy

On top of the disk requirement, the indexer needs trace methods. debug_traceTransaction and trace_block are how an explorer reconstructs internal transactions: the CALL and DELEGATECALL activity that does not appear in eth_getLogs. Without traces, an explorer cannot show you that a router contract internally moved ETH through three sub-calls before the swap settled.

Most managed RPC providers gate trace methods behind premium tiers and apply 40-80x compute-unit multipliers on trace requests. A self-hosted Arbitrum archive with traces lands in the $2,610-$9,800 per month range once you account for high-IOPS storage, redundancy, and bandwidth, per Dwellir's writeup on the hidden cost of archive nodes. Multiply by the number of chains an explorer supports and the infrastructure bill becomes the dominant line item.

What You Can Actually Look Up

Once the three layers are in place, an explorer exposes the following data model. Every reasonably complete EVM explorer covers all of it:

• Blocks: height, hash, parent hash, timestamp, gas used and limit, base fee per gas, transaction count, blob count post-EIP-4844, validator or proposer
• Transactions: hash, nonce, from, to, value, gas limit and used, effective gas price, status (0x1 success, 0x0 revert), input data decoded against ABI when available, position within block
• Internal transactions / traces: the call tree of a transaction including every CALL, DELEGATECALL, STATICCALL, CREATE, CREATE2, and SELFDESTRUCT, with from, to, value, input, and output for each frame
• Receipts and event logs: cumulative gas used, log indices, and for each log the emitting address, topic0 (keccak256 of the event signature), additional topics, and decoded parameters when the ABI is known
• Token transfers: ERC-20 Transfer, ERC-721 Transfer, ERC-1155 TransferSingle and TransferBatch, classified and aggregated per address
• Contract metadata: bytecode at address, ABI if verified, source code if verified, creator address, creation transaction, compiler version and settings
• Address details: native balance, nonce, full transaction history, token balances, name tags, ENS reverse resolution, contract or EOA classification
• Pending transactions: the mempool view, where the explorer offers it
• Gas tracker: live base fee, recent priority fee distribution, estimated wait times. See Ethereum gas fees explained for what those numbers mean.

The distinction between transactions, traces, and logs is worth holding onto. Logs are what contracts choose to emit. Traces are what actually executed. An explorer that indexes only transactions and logs misses ETH movements that happened via internal CALLs, because internal value transfers do not produce logs. This is why "internal transactions" exists as a tab on Etherscan and Blockscout at all: the underlying chain has no concept of an internal transaction, only the trace reveals it.

Block Explorer vs Indexer vs Analytics Platform

These three categories overlap enough to confuse new developers. The simplest separation:

A standalone indexer does not give you a UI. You configure it with the events and addresses you care about, and you query its database from your own application. An explorer gives you a generic UI that covers the entire chain. An analytics platform sits on top of indexed data and adds human-curated entity labels (this address is Binance, this contract is Uniswap V3) plus a SQL or dashboard interface.

If you only need to surface chain activity inside your own app, an indexer is usually the right tool. If you need a public, browsable view of a chain, you need an explorer. If you need to answer "how much volume did all DEXs do last week, broken down by chain," reach for analytics.

Verifying a Smart Contract

Verification is the explorer feature most builders interact with directly. An unverified contract on Etherscan or Blockscout shows only EVM bytecode. A verified contract shows the original Solidity (or Vyper) source, the ABI, and a Read/Write tab that lets anyone call view functions and submit transactions through the explorer's UI.

Verification works by recompiling and matching bytecode:

1. You submit the contract address, chain ID, source files, and a metadata.json produced by the Solidity compiler. The metadata file pins the exact compiler version, optimisation settings, EVM target, and library addresses.
2. The explorer recompiles the source with those exact settings.
3. It fetches the deployed runtime bytecode using eth_getCode and compares it byte-for-byte with the locally compiled output.
4. A full match means the entire bytecode matches, including the trailing CBOR auxdata that contains the metadata integrity hash. A partial match means the executable body matches but the metadata bytes differ, typically due to differences in comments, file paths, or whitespace in the source.

The flow is automated through hardhat-verify and Foundry's forge verify-contract --verify flag. Both compute the same metadata.json the explorer expects and submit it via the explorer's API.

Sourcify is the open, chain-agnostic alternative. It stores verified source and metadata in a public IPFS-backed repository, and any explorer can read from it. Blockscout integrates Sourcify natively, so a contract verified on Sourcify shows up as verified on every Blockscout instance for that chain.

Major Block Explorers in 2026

The explorer market in 2026 is split between Etherscan and the Etherscan-compatible API ecosystem on one side, and open-source Blockscout on the other, with specialised tools filling specific niches.

Etherscan

Etherscan was founded in August 2015 by Matthew Tan. It is closed source, runs on Etherscan-controlled infrastructure, and is the de facto labelling authority for Ethereum addresses. The free API tier caps at 3 requests per second and 100,000 calls per day. The V1 API was deprecated on August 15, 2025; V2 covers 60+ chains under a single API key.

Etherscan also operates an Explorer-as-a-Service offering for chains that want a hosted, branded explorer. Public pricing has surfaced in the $1.5M-$2M per chain per year range for the full product, with a roughly $300K floor for basic data-only access. That number is part of why so many L2s have moved off Etherscan.

The track record in 2024-2025 is mixed:

• April 2024: a 12+ hour multi-chain outage affected several Etherscan-hosted chains
• November 2024: during Devcon, Etherscan removed free API access for ~10% of chains, including Base, Avalanche, BNB Chain, and Optimism
• Late 2023: Etherscan exited the Avalanche-built Snowtrace, which moved to Routescan
• July 2025: Mantle sunset its Etherscan-built explorer in favour of community alternatives like mantlescan.xyz

These events are the operational risk argument for not building your business logic against a single closed explorer's free tier.

Blockscout

Blockscout is the open-source explorer most teams reach for when they need control. It is written in Elixir with a PostgreSQL backend, licensed under GPLv3 with a custom Blockscout amendment, and has 4.5k+ GitHub stars. It runs on 3,000+ chains. Per Blockscout's L2 Transparency Layer analysis, 67% of L2s tracked by L2Beat (94 of 149 projects) use Blockscout.

Blockscout's typical RPC profile during indexing is around 200 requests per second, dropping to roughly 100 RPS at steady state once the chain is fully backfilled. It exposes a REST v2 API and a GraphQL endpoint, and offers free public APIs on Base and OP Mainnet that anyone can use without a key.

The honest trade-off versus Etherscan: Etherscan has the stronger labels, the more polished UI, and a longer track record on mainnet Ethereum. Blockscout is the open, self-hostable, multi-chain default. For an L2 or appchain launching today, Blockscout is the lower-risk choice precisely because the team launching the chain controls the explorer.

Routescan

Routescan operates a multi-chain hosted explorer family (Snowtrace for Avalanche, Cronoscan, Wemix Scan, and others) using an Etherscan-compatible API. When Etherscan walked away from the Avalanche-built Snowtrace in late 2023, Routescan took over and rebuilt it. The Etherscan-compatible API matters because most ecosystem tooling (Hardhat, Foundry, ethers, viem) targets that interface by default.

Otterscan

Otterscan is the lightest-weight explorer in the ecosystem. It runs as a single static frontend, requires only an Erigon archive node behind it, and uses Erigon's ots_ RPC namespace for everything an explorer needs. There is no separate database. It is MIT-licensed, fits on a laptop, and is the right tool if you want a private explorer for your own dev work.

Specialised tools

• Tenderly is a debug-and-simulation platform with explorer-like UI across 90+ EVM chains. It is the standard tool for tracing reverts and replaying transactions against alternative state.
• Phalcon by BlockSec specialises in DeFi security forensics, with attack-pattern detection and call-tree visualisation built around exploit analysis.
• Solscan was acquired by Etherscan in January 2024 and is the dominant Solana explorer. SolanaFM was acquired by Jupiter in September 2024.
• Subscan is the Polkadot and Substrate ecosystem default, covering ~100 networks. Subscan is documented as using Dwellir as an infrastructure provider in Polkadot governance referendum 1727.
• beaconcha.in covers the Ethereum consensus layer: validators, attestations, slashings, and finality data not visible in execution-layer explorers.
• mempool.space is the Bitcoin reference. It is fully open source, runs on a Raspberry Pi class device, and ships its own visualisation of the mempool itself.
• Mintscan, Big Dipper, and Ping.pub cover the Cosmos ecosystem.
• HyperScan (Blockscout-based), HyperEVMScan (Etherscan-style), and HypurrScan (HyperLiquid L1) are competing for HyperEVM coverage. The Tempo testnet, which launched on December 9, 2025 backed by Stripe and Paradigm at a $5B valuation, shipped with Blockscout as its day-one explorer.

Can You Run Your Own?

Yes, and a growing number of teams do. The path depends on what you want to control.

Self-host Blockscout if you want a full-featured, public-grade explorer for your chain. Blockscout ships with Docker Compose, Helm charts for Kubernetes, and Ansible playbooks. The Blockscout team also offers Autoscout (managed deployment in minutes) and full Explorer-as-a-Service if you want to avoid the operational burden entirely.

Run Otterscan if you already operate an Erigon archive node and only need a private dev-and-research view. There is no separate database, no separate indexer, and no public exposure required.

Build something custom if your chain has non-standard semantics that no existing explorer handles. This is the path for chains like HyperEVM that mix EVM execution with L1-specific state.

The infrastructure floor for a self-hosted public explorer:

• An archive node with trace methods enabled, for every chain you index
• PostgreSQL with replication for the indexer database
• Roughly 200 RPS to the node during initial backfill, settling to 100 RPS at steady state
• A frontend host and a separately-scaled API tier
• DevOps capacity to handle reorgs, client upgrades, and disk growth

When self-hosting makes sense:

• You operate a regulated entity that needs data sovereignty
• You run a custom L2 or appchain with bespoke instructions or precompiles
• You want privacy on internal queries that would otherwise hit a public explorer
• You have been burned by a hosted explorer's rate limits, outage, or pricing change

The Etherscan November 2024 free API removal and the April 2024 multi-chain outage are the cleanest examples of why teams choose to control their own explorer.

Can Blockchain Explorers Be Wrong?

Yes. Treating an explorer as ground truth is a mistake.

• Reorg races. A transaction shown as confirmed at block N may end up orphaned during a deep reorg, especially on chains without explicit finality. The explorer eventually catches up, but in the gap the UI lies.
• Indexer bugs. Internal transaction decoders disagree across explorers more often than you would expect. Two explorers can show different traces for the same transaction because their trace classification logic handles edge cases (failed sub-calls, self-destructs, nested CREATE2) differently.
• Stale data. API rate limits, backfill lag, and database replication delay all surface as "the explorer says X but the chain says Y."
• Censorship and editorial choices. A hosted explorer can decide to hide an address, redact a transaction, or apply geographic restrictions. This is rare but real.

For high-value queries (compliance, financial settlement, on-chain identity) verify against a direct RPC call to a node you control, or cross-check against a second explorer. Treat the explorer as a fast UX layer, not as the source of truth.

How Explorers Fit Into the Data Stack

Explorers, RPC nodes, indexers, oracles, and analytics platforms all read or write the same underlying chain. They differ in direction and scope:

• An RPC node is the lowest-level interface. It serves raw chain state and accepts transactions.
• An indexer turns chain events into a database optimised for one application's queries.
• An explorer is a general-purpose indexer plus a UI plus a public API.
• An oracle goes the other way. It pushes off-chain data on-chain so smart contracts can read it. An explorer reads on-chain data and surfaces it off-chain. Opposite directions, same boundary.
• An analytics platform layers SQL, entity labels, and dashboards on top of indexed chain data.

The decision rule for builders:

• Reading or writing chain state directly? RPC.
• Need a custom database for one product's queries? Indexer.
• Need a generic, browsable view of a chain for users or support? Explorer.
• Need to answer cross-protocol or cross-chain questions in SQL? Analytics.

The Infrastructure Underneath

Every explorer's quality is bounded by its RPC layer. The indexer is only as fast as the node behind it, only as complete as the trace methods it can call, and only as cheap as the per-request economics of those calls.

Three properties of the RPC layer matter most:

• Archive depth and trace coverage. Without archive state and debug_* or trace_* methods, the indexer cannot serve historical balances or internal transactions. This is non-negotiable for an explorer that wants to be useful.
• Throughput. 200 RPS during backfill is a sustained number, not a peak. Bursty rate limits do not work for indexers; you need a stable ceiling. Batched calls like eth_getBlockReceipts cut request count significantly, but only if the provider supports them.
• WebSocket reliability. New-head subscriptions are how the indexer keeps up with the tip. A flaky WebSocket means missed blocks, which means reorg-handling logic kicks in unnecessarily, which costs database writes.

Multi-chain coverage is where this gets expensive. A multi-chain explorer like Blockscout-on-3,000-chains needs archive plus trace plus WebSocket on every chain it covers, separately. Dwellir's product is built around that requirement: archive RPC across 150+ networks, trace and debug methods included on paid plans, no compute-unit multipliers on heavy methods. Subscan documents Dwellir as one of its infrastructure providers across the Polkadot ecosystem in governance referendum 1727. The HyperEVM explorer race (HyperScan on Blockscout, HyperEVMScan on an Etherscan-style stack, HypurrScan on the L1) is a current example of the same pattern: every team needs the same archive-and-trace foundation, the only question is who provides it.

Conclusion

Explorers are middleware. They translate raw chain bytes into something humans and tools can use, and almost every Web3 workflow touches one. Where you sit determines what to take from this guide:

• Building on a hosted explorer. Know its limits. Rate limits, reorg lag, and trace decoding bugs are all real. Have a fallback API key with a second explorer, and verify high-value lookups against a direct RPC call.
• Considering self-hosting. Budget for archive plus trace RPC, not just for the explorer container. The explorer software is the cheap part; the chain data underneath is the expensive part.
• Choosing a chain to build on. Check the day-one explorer story. A chain with Blockscout shipped at launch and free public APIs is a much better developer experience than one with a half-built Etherscan-style explorer behind a paywall.

If you are running an explorer or an indexer and the archive-RPC bill is becoming the limiting factor: Dwellir's archive RPC across 150+ networks includes trace methods on every paid plan with no compute-unit markup, or contact the Dwellir team to talk through archive and trace requirements for the chains you cover.