Chain Reorganization

A chain reorganization, usually shortened to reorg, is an event in which a blockchain node discards one or more blocks it had accepted as part of the main chain and replaces them with a different set of blocks from a competing branch that its rules now prefer. Transactions in the discarded blocks return to the pool of pending transactions; most are later included again, but any that conflict with the new chain are dropped. Reorgs of one block happen naturally from time to time; deep reorgs of many blocks are rare and often a sign of a bug or an attack.

Reorgs are a direct consequence of how many blockchains reach agreement. In proof-of-work systems such as Bitcoin, nodes follow the chain with the most accumulated work, so a heavier branch that appears later wins. Proof-of-stake networks such as Ethereum use a fork-choice rule plus a finality mechanism, after which reorgs should not occur. The risk of a reorg is why exchanges and merchants wait for several transaction confirmations before treating a payment as settled.

Imagine two teams of scribes copying the same book in different rooms. Each adds a page whenever it finishes one, and occasionally both rooms finish a page at the same moment with slightly different wording. For a short while there are two versions. The rule is that everyone switches to whichever version grows longer first.

When the other room pulls ahead, your room tears out its latest page and copies theirs instead. That swap is a reorganization. Any notes written only on the torn-out page must be added again later, and if one of them contradicted something in the winning version, it is thrown away. The deeper the swap, the more pages are torn out, which is why people wait for several pages before trusting a note.

Common causes include:

• Natural forks. Two miners or validators produce valid blocks at almost the same time. The network briefly splits until one branch gets the next block, and the losing block becomes a stale block.
• Network delays. Slow propagation means some nodes see blocks late and build on an outdated tip.
• Software bugs. Different client versions may disagree about which blocks are valid, creating competing chains until the bug is resolved.
• Attacks. An attacker with enough hash power or stake can secretly build a longer chain and release it, as in a 51% attack.

In March 2013, a database incompatibility between two versions of Bitcoin's software split the network; developers and miners resolved it by agreeing to favour the older version, and a branch of more than 20 blocks was abandoned. Ethereum Classic suffered several deep reorgs from 51% attacks in 2019 and 2020, which were used for double spending against exchanges. In May 2022, before Ethereum's switch to proof of stake was completed, its Beacon Chain saw a seven-block reorg, which researchers traced to a fork-choice update that not all validators had deployed. Smaller chains with low hash power have been reorganized many times, sometimes with rented mining capacity.

On proof-of-work chains, finality is probabilistic: each additional block makes a reorg exponentially less likely but never impossible, which is described under probabilistic finality. Bitcoin users often treat six blocks, about an hour, as a practical safety threshold. Ethereum's proof-of-stake design uses Casper FFG checkpoints, described under Casper (Ethereum); once a checkpoint is finalized, reversing it would require validators holding at least one-third of the stake to be penalised. Blocks after the last finalized checkpoint can still be reorganized in principle, but in practice reorgs on Ethereum are rare and short. For payment systems, the comparable idea is settlement finality.

Services that accept crypto deposits set confirmation thresholds based on each chain's security, the size of the payment and its history of reorgs; small chains may need hundreds of blocks. Zero-confirmation transactions carry the highest risk. Bridges and layer 2 networks must also wait for finality on the chains they connect, since a reorg on one side could leave assets released on the other. Developers monitor block explorers and node logs for orphaned blocks, and some networks add rules that penalise or limit deep reorganizations.