What Are Block Confirmations?

In brief

A transaction is unconfirmed while it sits only in mempools. It has one confirmation when it is in a block that your node accepts as part of its best chain. Each child block on that chain adds a confirmation.

On Bitcoin, settlement is probabilistic. The whitepaper and the developer guide treat accumulated proof of work as the cost of a rewrite. Six confirmations became a common merchant habit, not a protocol constant. A majority of hash power can still attempt a deeper reorg.

On Ethereum, some interfaces count the containing block as the first confirmation and then report descendant depth, but this is application vocabulary rather than a consensus status. Ethereum’s protocol distinguishes the fork-choice head, justified checkpoints, and finalized checkpoints.

On Solana, RPC responses expose processed, confirmed, and finalized commitment states. getSignatureStatuses separately reports confirmations as the number of blocks since confirmation; it returns null when the transaction is rooted and finalized by a supermajority of stake.

Confirmations measure depth on a chosen history. They do not by themselves tell you the recipient was the right person or the token was not a fake.

From broadcast to first inclusion

You sign. Nodes put the transaction in their mempools. A block producer includes it.

Before inclusion, an explorer may show pending, unconfirmed, or nothing at all, depending on its node’s local mempool. More Bitcoin confirmations make a reversal progressively harder; they do not create an absolute protocol finality flag.

If two miners find a Bitcoin block at the same height, your transaction might be in only one side of a short fork. Nodes follow the chain that later accumulates more work. The losing block becomes stale. Transactions in it can return to the mempool.

That is why “1 confirmation” on Bitcoin is already better than zero and still weaker than “buried under an hour of honest work.”

How wallets count

Typical display logic:

1. Zero — in the mempool, or not seen.
2. One — in the tip block your data source likes.
3. N — the containing block plus its descendants total N confirmations.

The counter is only as honest as the node behind it. A dishonest or lagged RPC can show confirmations on a fork your own full node would reject.

Bitcoin: work, not a magic six

Each new Bitcoin block commits to the previous header. Changing an old transaction means redoing the work of that block and every block after it, then outrunning the honest chain.

An attacker with less than half of the hash power still has some chance of catching up from a finite deficit, but that probability falls as honest work accumulates. Majority hash power makes sustained rewriting much more reliable. Separately, coinbase outputs cannot be spent for 100 blocks, a consensus maturity rule that limits fallout if a reward’s block becomes stale.

Six confirmations is a widely copied exchange policy from an era when an hour of Bitcoin work was the usual example. It is not in the consensus rules. A very large payment may wait longer. A soda-machine payment may wait zero and accept the risk.

Do not import “wait six” onto other chains.

Ethereum: inclusion, justification, finality

ethereum.org’s transaction page:

1. A signed transaction is broadcast and may enter execution-client transaction pools.
2. A proposer includes it in a block, and the block may become the fork-choice head.
3. A checkpoint containing that block or one of its descendants can later become justified, then finalized.

Slots are 12 seconds and epochs are 32 slots. That schedule is not a confirmation policy, and a slot can be empty. Casper-FFG processes stake-weighted checkpoint votes; at least two-thirds of active stake is required for justification, and finalized checkpoints are protected by accountable-safety conditions under which conflicting finalization implicates at least one-third of stake.

So:

• “1 confirmation” in an explorer usually means included in its current canonical chain.
• “Safe for a small transfer” might be a few slots, depending on the app.
• “Treated as irreversible under Ethereum’s economic finality” is finalized, which is an epoch-scale event, not “the next block.”

Layer-2 withdrawals add their own waits (optimistic challenge windows). Those are not L1 confirmation counts. See the live Layer 2 article and the optimistic-rollup article in this batch.

Solana: commitment and roots

Solana RPC terminology:

• Processed — the node has processed the block on its current best fork; it can still be rolled back.
• Confirmed — more than two-thirds of active stake directly voted on the block.
• Finalized — the cluster recognizes the block at maximum lockout, its strongest standard commitment.

A leader processing your transaction in a slot is not the same as cluster finalization. The confirmations field is also not a Bitcoin-work measurement: it becomes null, rather than growing forever, once the transaction is rooted and finalized. Use Solana’s commitment words instead of translating them into “Bitcoin confirmations.”

What confirmations do not tell you

They do not prove:

• the token contract is the one you meant;
• the address was not poisoned;
• an exchange has credited your account (that is their database);
• a wrapped asset is backed.

They only speak to reorg risk on that ledger, under that consensus rule.