What Is a Block Explorer?

In brief

A block explorer usually has three layers:

1. Node or RPC access supplies protocol data such as blocks, transactions, receipts, account state, and a local pending-transaction view.
2. Indexes and parsers reorganize that data so it can be searched by transaction hash, block height, address, token, contract, or program.
3. Interface and metadata present human-readable pages, decoded calls, labels, charts, token logos, and risk notices.

Only some displayed fields are direct protocol objects. Others are calculations, decoded events, traces, third-party labels, or the explorer operator’s interpretation. An explorer does not make a transaction confirmed, own an address, reverse a transfer, or establish consensus. Nodes following the network’s rules do that work; the explorer reports one infrastructure stack’s view.

Most browsing is read-only. Some explorers also offer connected-wallet tools that prepare or submit transactions or contract calls. Once a user signs, that is a wallet interaction routed through the interface—not proof that the explorer controls the chain.

What an explorer actually reads

Different chains expose different objects.

Bitcoin

Bitcoin Core’s getblock RPC returns a block’s hash, height, confirmations, header fields, chainwork, transaction IDs, and optionally decoded transactions. getrawtransaction can return transaction inputs, outputs, witness data, block association, and confirmations, but historical lookup depends on providing a block hash or running the appropriate index.

A Bitcoin “address balance” is not a balance field stored in the block header. The explorer derives it by indexing transaction outputs associated with scripts it recognizes and subtracting spent outputs. That makes address pages useful views, but they should not be mistaken for an account object in Bitcoin’s consensus model.

Pending Bitcoin information is local. getmempoolentry reports data from that node’s mempool, including fee, dependencies, and replacement status. Another node may not have the same transaction or may apply different relay policy. “Pending on explorer A” means explorer A’s infrastructure currently sees it.

Ethereum and other EVM chains

Ethereum clients expose JSON-RPC methods for blocks, transactions, receipts, logs, code, and account state. Explorers index those responses and often run additional tracing and decoding systems.

Several familiar explorer rows are derived:

• Token transfers are commonly reconstructed from contract event logs.
• Method names are decoded from calldata using an ABI or signature database.
• Internal transactions are not ordinary signed transactions in a block; they are explorer representations of value-moving calls reconstructed from execution traces.
• Token balances are contract state interpreted according to a token interface and the explorer’s token catalog.

A transaction receipt reports execution success or failure and gas used. A failed Ethereum transaction can still consume gas because validators executed it before the state-changing portion reverted. An explorer’s green “success” means the EVM execution represented by that receipt succeeded; it does not mean the user intended the call or received a genuine token.

Solana

Solana’s getBlock and getTransaction RPC methods can return encoded transactions, status metadata, fees, balances, inner instructions, logs, and token-balance changes at a requested commitment level. With jsonParsed, the RPC node uses program-specific parsers where available and falls back to less-decoded fields when it cannot parse an instruction.

That fallback is an important general lesson: readable instructions depend on software knowing the program format. A raw signature and account list may be authoritative chain data while the action label beside them is parser output.

How to read a transaction page

Check these in order:

1. Network or cluster. Mainnet, testnet, devnet, and rollup networks are separate ledgers. The same-looking address can exist on several.
2. Transaction identifier. Copy the full hash or signature rather than matching the first and last characters.
3. Status and inclusion. Distinguish pending, included, confirmed, finalized, failed, dropped, or replaced according to that chain’s model.
4. Block or slot. Confirm where the transaction was included and whether that block remains on the selected history.
5. Actual asset identifier. Check the token contract or mint, not only its ticker, name, or logo.
6. Value and fee units. BTC, satoshis, ETH, wei, SOL, lamports, token decimals, and displayed fiat estimates are different data.
7. Decoded action. Treat labels as an aid. For unfamiliar contracts or programs, inspect raw inputs, logs, and the verified program identity.

Block timestamps also need care. Bitcoin’s header time is miner-supplied within consensus limits, not a timestamp for every transaction. Solana’s RPC labels block time as estimated and may return null. An explorer’s wall-clock display is not necessarily an exact execution time.

Address and account pages

An address page often combines protocol facts with an indexer’s history. It may show:

• current native-asset balance;
• token holdings;
• transaction and transfer history;
• labels such as “exchange,” “bridge,” or “phishing”;
• portfolio values based on external prices.

Labels and fiat values are metadata, not consensus. Token lists can include spam assets sent without the holder’s request. A copied symbol does not identify the legitimate token. On account-based chains, an address can also be a smart contract or program-owned account rather than a person.

Absence is not always proof of absence. An explorer may not index an old event type, a pruned RPC may lack history, a token parser may fail, or the provider may be behind the chain tip.

Contract source verification is not an audit

EVM explorers may show “verified” source code. Source-code verification recompiles submitted source and compares the result with deployed bytecode. Sourcify’s documentation is explicit: a match helps establish that the human-readable source corresponds to on-chain code, but it does not determine whether that code is safe.

Keep four questions separate:

1. Does this source reproduce the deployed bytecode?
2. Is this the correct chain and contract address?
3. Is the contract a proxy, and if so what implementation and admin can it use?
4. Has anyone competently reviewed the behavior and upgrade powers?

“Verified” answers only the first question under the verifier’s matching rules. It is not a security seal, an identity guarantee, or an endorsement by the explorer.

Confirmations are the provider’s reported view

Bitcoin confirmation counts depend on which valid chain the queried node currently treats as best. Ethereum pages may distinguish included, justified, and finalized. Solana RPC calls accept commitment settings such as confirmed or finalized.

An explorer reports those states; it does not create them. During reorganization, outage, or provider lag, two explorers can temporarily disagree. For high-value decisions, confirm the chain tip, commitment/finality terminology, and the provider behind the page. See What Are Block Confirmations? and What Is Finality? for the chain-specific settlement models.

Privacy and security

Public chain data does not make every query private. An explorer operator can observe IP addresses, requested wallet addresses, browser identifiers, and connected-wallet activity. Repeatedly searching a set of addresses can reveal that one user associates them.

Common hazards include:

• phishing domains that imitate a known explorer;
• sponsored links or token pages leading to malicious sites;
• wallet-connect prompts on what should have been a simple lookup;
• copied address labels treated as authoritative;
• API outages or rate limits mistaken for chain failure.

Bookmark trusted domains, avoid signing merely to inspect public data, and query your own node or privacy-preserving infrastructure when address-linkage matters.

Explorer, wallet, node, and oracle

• An explorer searches and presents data.
• A wallet constructs requests and manages signing authority.
• A node validates or serves protocol state according to its software and configuration.
• An oracle supplies external data to a protocol under an explicit trust model.

An explorer API can be useful application infrastructure, but it is not a consensus oracle. A DeFi contract cannot directly ask a normal website what the chain’s truth is, and critical software should not confuse one provider’s index, labels, or price feed with consensus state.