Consensus and finality
When is a transaction actually done? The answer is different on every network, and on some of them the honest answer is “probably, by now”.
In a bank transfer there is a moment the payment becomes irrevocable, defined by law and by the operator's rules. Distributed ledgers have no such authority, so finality has to be constructed — and different systems construct it differently.
Probabilistic finality
Under proof of work, a transaction is never mathematically final. It becomes progressively harder to reverse as blocks pile on top, because reversing it means outpacing the whole network from that depth.
Nothing in Bitcoin defines a transaction as settled at six blocks. The figure comes from the whitepaper's own probability calculation and has become an industry habit. An exchange crediting a deposit after six confirmations has made a commercial risk judgement, and for a large enough amount a cautious operator may wait longer.
Economic finality
Modern proof-of-stake designs add something stronger. Once a block is finalised, reversing it requires validators holding a large fraction of all staked tokens to sign contradictory statements — which the protocol detects and punishes by destroying their deposits.
So reversal remains possible and carries a known, enormous, automatic penalty. That is a different guarantee from proof of work's, and arguably a firmer one: the cost of the attack is not merely spent, it is confiscated.
Reorgs
When two valid blocks are produced at nearly the same moment, the network briefly holds two versions of history. Whichever chain is extended first wins, and transactions in the losing block return to the waiting pool to be included later.
Short reorganisations of one or two blocks are routine and uninteresting. Deep ones are rare, serious, and have occasionally resulted from software bugs rather than attacks.
Why this matters practically
- Waiting for confirmations before treating a payment as received is not excessive caution; it is the only protection available.
- The right number of confirmations scales with the amount at risk and with how much hashing power or stake secures that particular chain.
- Smaller chains with modest security have been reorganised by attackers who rented capacity for a few hours. The cost of attack, not the design, is what differs.
- Cross-chain bridges must choose a finality assumption for each chain they connect, and choosing wrong is how several of them were drained.
A transaction on a well-secured chain with many confirmations is about as settled as anything gets in this field. The same transaction on a lightly-secured chain after one confirmation is a probability, not a fact. Treating all confirmations as equivalent is a category error that has cost exchanges real money.