When you send bitcoin and check the status, you'll see "1/6 confirmations" — or just "unconfirmed" — and wonder why the money isn't available yet. The reason is that blockchains have no single authority that can finalize a transaction. Every new block added on top of yours is, in effect, the rest of the network voting that your transaction happened and is permanent. The more votes, the harder it becomes to rewrite history.
This is different from a bank transfer, where a central authority marks a transaction as settled because it has the power to enforce that decision. Blockchains have to build finality out of math and economic incentives instead.
In Bitcoin, when your transaction gets included in a block, that block gets added to the chain. That's not finality — it's the first step.
After your block, miners keep building new blocks, each one referencing the block before it. This creates a chain of accumulated computational work. To rewrite your transaction — cancel it or double-spend — an attacker would need to redo that accumulated work: not just for your block, but for every block piled on top.
The probability math is specific. With one confirmation, an attacker controlling 10% of the network's hash rate has roughly a 45% chance of building an alternative chain that overtakes the honest one. Not acceptable for high-value transfers. At six confirmations, that same attacker's success probability drops below 0.1%.
Satoshi Nakamoto worked through this in the original Bitcoin whitepaper. Six confirmations became the informal standard for irreversibility — roughly one hour at Bitcoin's 10-minute block target. Why not one or two? Because there's no moment when a proof-of-work block is "officially final." Finality accumulates asymptotically as more blocks pile on. Each additional block makes reversal exponentially more expensive.
Proof of stake is a different model entirely. Ethereum uses a finality mechanism called Casper FFG, which checkpoints the chain every 32 slots (roughly 6.4 minutes). When two consecutive checkpoints are justified by two-thirds of all validators, the earlier one becomes finalized.
Finalized means something precise: reversing a finalized Ethereum block would require slashing more than one-third of all staked ETH. With 30+ million ETH staked as of early 2026, that's tens of billions of dollars destroyed. Economic finality arrives at roughly 12.8 minutes — qualitatively different from Bitcoin's probabilistic model, and once it lands, the security guarantee is enormous.
Before those checkpoints (~12.8 minutes), Ethereum transactions have soft confirmation — they're in a block, but not yet protected by the slashing mechanism. Fine for low-value transfers; not sufficient for high-value settlement.
Exchanges require more confirmations than the bare protocol minimum because they're managing risk, not just reading a rulebook. A platform processing millions in daily volume runs the probability math at six Bitcoin confirmations and decides that's acceptable. Others require three. Some require more for large withdrawals. This is policy, not protocol.
The network enforces no minimum waiting period. Your transaction is technically "confirmed" after one block. How many confirmations a counterparty demands before releasing funds is their risk decision — it's not a consensus rule.
The binding constraint here is physics as much as math: Bitcoin's 10-minute block target exists partly because global internet propagation times (~150–200ms trans-Pacific one-way) mean faster blocks would create frequent orphans. You can't simply halve the confirmation window by halving the block time without degrading security.
Three developments are shifting how confirmations work in practice.
Ethereum's finality model changed the landscape for EVM-compatible chains. Once Casper FFG checkpoints a block, the security guarantee is economic rather than probabilistic. Many applications now treat 12.8-minute finality as sufficient for high-value settlement — something that wasn't possible under Ethereum's old proof-of-work model.
L2 rollups introduced a two-tier confirmation model. A transaction on Arbitrum or Base gets a soft confirmation from the centralized sequencer within seconds. But full settlement to Ethereum L1 — through batch posting and proof verification — takes longer: minutes to hours for ZK rollups, and up to seven days for optimistic rollups during the fraud proof challenge window. For most user-facing activity, the soft confirmation is sufficient. The seven-day withdrawal window matters specifically when moving assets back to mainnet.
Ethereum's single-slot finality (SSF) proposal would collapse the 12.8-minute finality window to roughly 12 seconds, if deployed. It's currently in research and not yet on mainnet.
Ethereum SSF deployed on mainnet without incident. ZK proof generation times shortening to minutes, reducing L2 settlement delays meaningfully. Exchange confirmation requirements converging toward protocol finality windows rather than conservative multiples built on legacy risk models.
A documented double-spend succeeding against a transaction with six or more Bitcoin confirmations. A reorg deep enough to reverse finalized Ethereum blocks — which would require slashing more than one-third of all staked ETH, an economic catastrophe requiring a hard fork to repair. L2 sequencer failures at scale leading to settlement failures.
Now: Six Bitcoin confirmations (~one hour) is the live standard for high-value Bitcoin transfers. Ethereum finality lands at ~12.8 minutes via Casper FFG. L2 soft confirmations arrive within seconds; L1 settlement timelines depend on the rollup type.
Next: Ethereum single-slot finality is on the development roadmap — it would bring economic finality to ~12 seconds if deployed and proven stable.
Later: Post-2140, Bitcoin's fee market replaces block subsidies as the primary security funding mechanism. Whether that changes confirmation security depends on fee market dynamics that won't be tested for decades.
This covers the mechanism — why confirmations exist and how finality accumulates across different consensus models. It doesn't constitute advice on confirmation requirements for any specific transaction, protocol, or commercial context. How many confirmations are appropriate depends on the blockchain, the value at risk, and counterparty risk tolerance. Those judgments belong to the parties involved.




