What is chain reorganization (reorg)?

An event in which a blockchain discards recently added blocks and replaces them with a longer competing chain, undoing the transactions they held.

Reorgs are a normal consequence of a network where anyone can propose a block. Two miners or validators occasionally produce a block at nearly the same moment, the network briefly disagrees, and one branch wins. Shallow reorgs of one or two blocks are routine on large networks and unremarkable. Deep ones are rare on large networks and have repeatedly happened on small ones.

This is the reason exchanges wait for several confirmations before crediting a deposit. A transaction in the most recent block is included, not settled.

How it works

Nodes follow a fork-choice rule that decides which competing branch is canonical. Bitcoin uses accumulated proof-of-work, so the branch with the most work wins. Ethereum's proof-of-stake fork choice weighs validator attestations and then hardens blocks through finality, after which reversal requires a large share of all staked ETH to be destroyed rather than merely out-competing later blocks.

When a node switches branches, transactions that appeared only on the discarded branch return to the mempool and usually reappear in a later block. They are not destroyed. The exception is a transaction that conflicts with one already confirmed on the winning branch, which is exactly how a double spend against a merchant who accepted zero confirmations would work.

Coinbase transactions are treated more carefully. Bitcoin makes a coinbase output unspendable for 100 blocks precisely so a reorg cannot leave spent coins that never existed (source: Bitcoin developer documentation).

Depth is the whole safety question. Each additional confirmation makes reversal exponentially more expensive under proof-of-work, which is why exchanges pick a number rather than a time.

Example

Illustrative. An exchange requires three confirmations for a Bitcoin deposit. Your transaction confirms in block 900,001, and the exchange still shows it as pending. A one-block reorg replaces block 900,001 with a competing block that also contains your transaction. The count restarts from the new block's height, and the deposit credits a few blocks later than expected. Nothing was lost, but the delay is real, and had you been the recipient accepting zero confirmations, the same reorg is the window in which a conflicting spend could have replaced yours.

Why it matters when you buy

Confirmation requirements are why a deposit can take an hour when the transaction confirmed in ten minutes, and they vary by asset and by venue. If you are transferring funds to buy something at a particular moment, budget for the wait rather than for the block time. The exchange pages note deposit handling, and how to use a block explorer shows how to watch confirmations accumulate.

Related terms

confirmation — the count that measures reorg safety; finality — the point past which reversal is not merely expensive; double spend — the attack reorgs enable; uncle block — a block that lost the race; mempool — where discarded transactions return.

Questions

Can a reorg take my coins?

Not by itself. Your transaction returns to the mempool and is normally reconfirmed. The loss case is a merchant or service that released goods or credit against an unconfirmed transaction that a conflicting one then replaced.

How deep can a reorg go?

On large proof-of-work networks, depth beyond a few blocks requires an implausible share of hash rate. On small networks with little hash rate, reorgs hundreds of blocks deep have occurred, which is why exchanges demand far more confirmations for minor chains.

Does proof-of-stake eliminate reorgs?

No, but Ethereum's finality changes the cost. Short reorgs at the tip remain possible, while reversing a finalized block would require destroying a large fraction of all staked ETH rather than simply building a longer chain.