Confirmation
Additional blocks that increase confidence a tx is final.
A confirmation indicates that a blockchain transaction has been included in a block and, depending on convention, that additional blocks have been built after it. Each added canonical block generally makes reversal less likely. Confirmations are a risk measure, not a universal guarantee, and their meaning depends on the network's consensus and finality model.
Before inclusion, a transaction is pending and can be delayed, replaced, dropped, or rejected. Once a miner or validator includes it, a block explorer can show one confirmation under interfaces that count the inclusion block. Other systems show zero until the next block. This difference explains why two services can display different numbers for the same transaction without disagreeing about its block.
Confirmations matter because recent blocks can be reorganized. Under proof of work, a competing chain with more accumulated work may replace recent history. The deeper a transaction is buried, the more work an attacker generally needs to reverse it. Proof-of-stake chains may provide explicit finality after validator votes, so applications can use protocol states such as safe or finalized instead of only counting blocks.
The required threshold should reflect risk. A small payment may be accepted quickly, while an exchange or bridge can wait longer for a high-value deposit. Network security, congestion, attack conditions, and deposit source all matter. A fixed “six confirmations” rule associated with Bitcoin should not be copied automatically to Ethereum, a Layer 2, or a small chain.
Confirmation also does not mean the intended contract action succeeded. A reverted smart contract transaction can be included and confirmed while consuming gas. Users should inspect execution status, logs, asset transfers, and the correct network. Cross-chain activity may require source finality plus a bridge message and separate destination confirmation.
Applications should present pending, included, safe, finalized, failed, and replaced states clearly. Store block hashes with heights and handle reorgs by reversing provisional database actions. Users handling significant value should follow current guidance from the receiving service and verify unusual delays through an explorer. Confirmations provide growing evidence that history will persist, but operational acceptance remains a risk decision rather than a magical number.
Frequently asked questions
- The appropriate number depends on network consensus, transaction value, current conditions, and the cost of reversal. A cheap retail payment may need fewer than a large exchange deposit. Follow current network-specific guidance and use finalized checkpoints where available. Counting blocks from another chain or relying on a fixed rule across all networks can create unsafe assumptions.
- No. A confirmation usually counts inclusion and blocks added afterward, providing increasing probabilistic confidence on some chains. Finality is the point at which consensus rules consider reversal impossible or economically exceptional under defined assumptions. Proof-of-stake networks may expose safe and finalized states, while proof-of-work applications commonly choose a confirmation threshold based on acceptable risk.
- Interfaces may count the inclusion block as the first confirmation or only count blocks built after it. They may query different nodes, lag behind the chain, or distinguish safe and finalized status differently. Temporary forks can also produce inconsistent results. For valuable transfers, compare the block hash and status through reputable sources rather than relying only on a label.