What Actually Happens During a Chain Reorg

Every exchange makes you wait a certain number of confirmations before crediting a deposit, and the number differs by asset for reasons that are rarely explained. The explanation is reorganisation — reorgs — and it is the reason “confirmed” and “settled” are not synonyms.

Blocks are a claim, not a verdict

A blockchain is not a queue that blocks join permanently. It is a tree, and the network follows a rule for choosing which branch counts as canonical.

Two miners can find valid blocks at nearly the same moment, each extending the same parent. Both are legitimate. Different parts of the network see one first and build on it, and for a short period two competing branches exist. When one branch gets extended before the other, nodes following the shorter branch switch. That switch is a reorg.

Transactions in the abandoned block are not destroyed. They return to the mempool and are generally mined shortly afterwards — unless they conflict with something in the winning branch, in which case they never confirm at all.

That last case is the one that matters. It is precisely the mechanism behind a double-spend: get a merchant to accept a transaction, then ensure a competing branch containing a conflicting transaction wins.

Proof-of-work: probabilistic, never absolute

Under proof-of-work, nodes follow the branch with the most accumulated work. Rewriting history means producing an alternative branch with more work than the one everyone else is extending — you must out-compute the rest of the network from your fork point onwards.

The cost grows with depth. Undoing one block means winning one race. Undoing six means out-producing the entire network across six blocks in a row. On a chain with substantial hashrate, that becomes prohibitive quickly, which is where the six-confirmation convention comes from — not from a proof, but from a judgement about when the cost of attack exceeds any plausible gain.

Critically, this is probabilistic finality. The probability of a deep reorg becomes negligible; it never becomes zero. Shallow one-block reorgs, by contrast, are routine and unremarkable — a normal consequence of propagation delay rather than evidence of an attack.

Why small chains are genuinely different

The security of proof-of-work is not a property of the algorithm. It is a property of how much hashrate is pointed at that specific chain.

For a chain using a widely-deployed hash function but commanding only a small share of the total hashrate for it, an attacker does not need to build hardware. They can rent capacity on the open market and briefly exceed the chain’s entire mining power. Several smaller networks have suffered deep, deliberate reorgs this way — dozens of blocks rewritten, exchange deposits reversed after crediting.

This is why a serious exchange requires vastly more confirmations on a small chain than on a large one. It is not caution theatre. The underlying security assumption is quantitatively different.

Proof-of-stake and explicit finality

Ethereum’s consensus takes a different approach. Time is divided into twelve-second slots, grouped into epochs of thirty-two slots. Validators vote on checkpoints, and once a checkpoint accumulates votes from two-thirds of staked value across two consecutive epochs — roughly thirteen minutes — it becomes finalised.

Finalised means something stronger than “very unlikely to change.” Reverting a finalised checkpoint requires validators controlling at least a third of all staked ether to have signed contradictory attestations, which is detectable and triggers slashing — their stake is destroyed.

So the security model shifts. Under proof-of-work, attacking costs you electricity you would have spent anyway; you keep your hardware. Under proof-of-stake with slashing, attacking costs you your capital, permanently and automatically. The penalty is inside the protocol rather than in the market.

Before finalisation, though, proof-of-stake chains reorg too. Short reorgs from propagation issues and missed proposals happen, which is why an unfinalised Ethereum transaction is not settled either.

What this means in practice

Confirmation counts encode a risk judgement. They combine the chain’s security budget with the size of the transaction. One confirmation for a coffee is sensible. One confirmation for a seven-figure transfer on a small chain is not.

Zero-confirmation acceptance is a business decision. It can be perfectly rational for low-value, high-volume, reversible commerce. It is not a technical guarantee of anything.

Finality varies enormously by chain, and the marketing term “fast finality” usually needs unpacking. Fast under what assumption, reversible under what conditions, penalised how?

A deep reorg is an event, not a background risk. Networks and exchanges respond publicly when one occurs. Silence at depth is the normal state.

The word “confirmed” is doing less work than it appears to. What it means is that the cost of undoing your transaction has risen to a particular level — a level you should be choosing deliberately.

Educational content only. Nothing here is financial advice.