How to read a block explorer: transactions, fees, confirmations and addresses

A block explorer is a window onto one node, not onto the network itself

A fully validating node checks the chain’s rules. Pruned nodes may discard old block files after validation; an explorer also needs historical data and indexes to offer its history pages. A block explorer is a website that sits on top of one of those nodes and turns its database into pages you can click through: one page per block, one per transaction, one per address. The mempool.space documentation defines it as “a tool that enables you to explore real-time and historical information about the blockchain,” and the project describes itself as “the fully-featured mempool visualizer, explorer, and API service.” Blockstream’s explorer offers a similar interface with a documented data feed.

Two things follow from that design. The explorer shows you one node’s view, which is an operator’s report, not independent proof of validity, and is especially local for pending transactions, because, as the same documentation says, “there is no one global mempool: every node on the network maintains its own.” And whoever runs the site can see what you look up, which is one reason the mempool project encourages people to run their own copy on hardware ranging “from a simple one-click installation on a Raspberry Pi” upward. For reading history, any reputable explorer will do; for your own transactions, the private option exists.

Read a transaction in a reproducible order

First identify the network and transaction. Check whether it is pending or included, then record the block hash and height if present. For an ordinary non-coinbase transaction, inspect the previous outputs spent, new outputs created and fee calculated from their difference.

Next distinguish output values from wallet ownership: a change output may belong to the sender, and a recipient address is not automatically a person. Record the observation time and chain tip when citing a confirmation count. Explorer labels add interpretation that should be kept separate from the raw transaction fields.

Fees, mempools, and the limits of an unconfirmed payment

A transaction is unconfirmed relative to an observed chain if it has not been included there. It may be accepted in a node’s mempool, dropped under local policy, or unknown to that operator. Check the transaction response and its observation time rather than assuming every signed or broadcast transaction is still waiting in every node.

The mempool view on the front page of mempool.space shows the queue sorted by fee rate, measured in satoshis per virtual byte, and projects which transactions will fit in the next blocks. “Since space in the Bitcoin blockchain is limited, bigger transactions pay more in mining fees than smaller transactions,” and a higher rate generally means quicker confirmation. If yours is stuck, the docs say, “there’s no need to panic”: it will either confirm or not, and a wallet that supports replace-by-fee can resubmit it at a higher rate. Our guide to fees and the mempool goes into the auction in detail.

The developer guide’s warning is worth quoting whole: “Zero confirmation transactions (unconfirmed transactions) should generally not be trusted without risk analysis.” An unconfirmed payment can be replaced by a conflicting one, and the recipient “will see the incoming transaction notification disappear or turn into an error message.” Unconfirmed means not yet included in the explorer’s accepted chain; a signed transaction may already have been created and relayed.

Confirmations and block height: how deep is deep enough

Every block carries the hash of the previous block’s header, which chains them together and means, as the developer guide says, that “a transaction cannot be modified without modifying the block that records it and all following blocks.” Blocks are numbered by height, “the number of blocks between them and the first Bitcoin block.” For a transaction still in the accepted chain, confirmations equal tip height minus its block height plus one. A transaction in the tip has one confirmation, not zero. Reorganizations can change that count.

How many is enough depends on what is at stake. The developer guide says software handling high-value payments “should wait for at least six confirmations before treating a payment as accepted,” and that fewer may suit lower-risk cases. Six is a convention, not a law of nature, and explorers will happily show you a count in the hundreds of thousands for anything old.

The genesis block is the other example worth looking up. Its explorer record shows height 0, a timestamp of 3 January 2009 at 18:15:05 UTC, a size of 285 bytes, exactly one transaction, and no previous block hash at all, because there was nothing before it. Every confirmation count on the network is, in the end, a distance from that block. The genesis block wallet page tells the rest of its story.

Reading an address page without over-reading it: an address is not a person

An address page lists every transaction that has paid to or spent from that address, plus totals. In the Esplora data feed those are the sum of funded outputs and the sum of spent outputs, and the balance is one minus the other, with a separate pair of tallies for anything still in the mempool. That much is fact. Everything beyond it is inference, and the inference most people make first, that an address is a person, is the one most likely to be wrong.

The developer guide advises against reusing addresses, since reuse lets observers “easily track the receiving and spending habits of that person,” and it recommends a fresh address for each payment. Well-behaved wallets do exactly that, so one person is normally many addresses, and a single address’s balance says little about anyone’s wealth. The reverse also holds: a service that holds coins for many customers can pool them under one address, so one address can be thousands of people. Our address graph research explains how analysts cluster addresses and how uncertain those clusters are, and the article on whether Bitcoin is anonymous explains what the chain does and does not reveal.

The habit to build is to read an address page as a record of coins, not of motives. A large incoming transaction is a large incoming transaction; whether it is a purchase, a transfer between one owner’s own wallets or an exchange moving its reserves is not on the page.