Chain reorganisations and your deposit

Block 01What a chain reorganisation is

A blockchain is not a single chain handed down by authority; it is whatever chain the network's rules select out of the blocks that exist. When two miners or validators produce competing blocks near-simultaneously, the network can briefly have two versions of the recent history. The consensus rule then decides: the chain with more accumulated work wins, and the other is abandoned. The switch from one to the other is a reorganisation, and the abandoned blocks are said to be orphaned.

Block 02Orphaned blocks and the mempool

When a block is orphaned, the transactions inside it are not destroyed. They failed to be part of the winning history, so they return to the mempool — the waiting area — where they can be included again in a later block on the canonical chain. In most reorgs the affected transactions reappear within a short time, sometimes in the very next block. The transaction is the same; only the block that carries it changes.

Block 03How depth defends a credited deposit

This is the whole reason operators wait for confirmations. To orphan a block that is already buried under several others, an attacker must produce a competing chain with more work than the honest chain has accumulated since — which means outpacing the entire network for the duration. The deeper the block, the more work that requires, and past a certain depth the cost dwarfs the value of any single deposit. Waiting for that depth converts a small chance of reversal into a negligible one, at the price of time.

Block 04If a credit was made too early

An operator that credits at too shallow a depth accepts the reorg risk itself. If a reorg orphans the block and the transaction does not return, the operator may have credited a balance that now has no matching deposit, and its terms usually give it the right to reverse the credit. This is why operators prefer to wait a little longer than strictly necessary: the cost of a reorg is borne by whoever credited early, and the safest policy is the one that never has to claw anything back.

Block 05A reorg is not a theft

Reorganisations sound alarming and are usually mundane — the ordinary result of two blocks racing. They are not, in themselves, an attack, and they do not reach into your wallet. The attacks worth knowing about look different: a deliberate deep reorg by a party controlling enough of the network's work, or a double-spend that exploits an operator crediting too shallow a depth. Both exploit the same gap — credit granted before depth made reversal expensive — which is exactly the gap a sensible threshold closes.

• ordinary reorg: two blocks race
• orphan returns to mempool
• attack: deep rewrite for profit
• attack: credit-then-undo double spend

Block 06A reorgs checklist

Two questions cover almost every reorg worry a depositor has.

• Was the deposit credited? If it was credited at a sensible depth, a normal reorg is already priced out of the equation.
• Did the transaction return? An orphaned transaction normally reappears in a later block; a reorg that dropped it entirely is unusual and worth support contact.