Block confirmation

A block confirmation counts each block built on top of the block that

contains a given transaction. The block of inclusion is sometimes called

"one confirmation", and every block after that adds another. Explorers

display the confirmation count on every transaction page so a viewer can

gauge how safely settled the transaction is.

Why confirmations matter

A transaction hash included in the latest

block exists on the chain as of right now, but that latest block could

still be reorganised away on chains with probabilistic finality. Each

subsequent block makes a reversal exponentially harder, because reversing

requires re-mining (or re-proposing) every block on top.

Explorers surface confirmations so users can answer a practical question:

"is it safe to act on this transaction yet?" A merchant accepting a

bitcoin payment, for example, traditionally waits for

six confirmations before treating the payment as settled.

Probabilistic vs deterministic finality

Different chains converge on finality in different ways.

• Probabilistic finality (Bitcoin, Litecoin, Dogecoin, Bitcoin Cash,

Dash, Zcash, Monero): there is no point at which a block is officially

"final". Reversal probability shrinks rapidly as confirmations grow.

Conventions like "six confirmations" are heuristics, not protocol rules.

See bitcoin and the other UTXO chains in the

chain index.

• Deterministic finality (Ethereum post-merge, Solana, Aptos, Sui, and

many others): the protocol explicitly finalises blocks after a defined

process. On ethereum, a block is "finalized" after

two epochs of attestations (roughly 12-15 minutes under healthy

conditions). Once finalized, reversal requires slashing a supermajority

of validators and is treated as protocol-breaking.

• Hybrid views: Ethereum exposes safe, finalized, and latest

block tags. latest is one confirmation; safe is several but not

finalized; finalized is the strongest guarantee.

• solana blocks pass through processed, confirmed,

and finalized commitment levels. RPC consumers pick a level depending

on how strong a guarantee they need.

• sui and aptos finalise transactions

within seconds via their consensus protocols, so the practical

confirmation count needed is small.

How explorers compute confirmations

Confirmation = current_head_block_number - inclusion_block_number,

possibly with +1 depending on whether the chain counts the inclusion

block itself. The exact number you see on a transaction page is whatever

the explorer's node reports as the chain tip minus the

block number the transaction landed in.

This is why the confirmation count increases every time you refresh a

transaction page: the head moves on, and the transaction stays in the

same block.

Common gotchas

• Confirmation count is informational, not authoritative. The

authoritative record is the block hash of the

block that contains the transaction, plus the chain's finality rules.

• A high confirmation count on a chain with strong finality is not

needed; one or two confirmations after a finalized tag is enough.

• A high confirmation count on a chain with weak proof-of-work hashrate

may still be reorganised. The convention numbers (six on Bitcoin, more

on weaker forks) reflect economic, not protocol, assurance.

• Confirmations on a layer-2 rollup are inherited partly from L2 sequencer

ordering and partly from the L1 settlement layer. A receipt confirmed

on optimism is not the same kind of "confirmed" as

one finalised on Ethereum L1; serious settlement guarantees wait for L1

finality.