Reorg Protection

Reorg protection refers to the practices that guard a recipient against a chain reorganization quietly undoing a transaction they believed was settled. A reorganization, or reorg, happens when the network adopts a different branch of the blockchain as the canonical one, discarding blocks that were briefly considered valid. Transactions confirmed only in the discarded blocks return to the mempool and may or may not reappear in the replacement chain. Reorg protection is not a protocol feature you switch on; it is a set of habits — chiefly waiting for confirmation depth proportional to the value at risk.

How reorgs occur

Most reorgs are benign and shallow. When two miners find valid blocks at nearly the same time, the network briefly splits into two views until one branch gains the next block and accumulates more proof-of-work, at which point every node converges on it and orphans the loser. One-block reorgs of this kind are a normal, periodic consequence of block propagation delays across a global network — nobody is attacking anything. Deeper reorgs are far rarer and require either extraordinary luck or a large amount of adversarial hashpower deliberately mining a private chain to rewrite recent history, the classic double-spend scenario. The economics are the defense: outpacing the honest network for even a handful of blocks means out-hashing it for that entire stretch, and the cost in energy and hardware scales with every additional block of depth.

Confirmations as protection

The primary defense is depth. Each confirmation buries a transaction under another block of proof-of-work, so a reorg deep enough to erase it must redo everything above it — making reversal exponentially less likely with each block. The customary six confirmations is a convention, not a law; the right number scales with value at risk. A coffee can reasonably clear on one confirmation or even zero for trusted counterparties, while an exchange crediting a large deposit may want six or more, and may raise thresholds during episodes of unusual hashrate concentration or network instability. Recipients of high-value payments should also remember what a reorg actually does: a discarded transaction returns to the mempool rather than vanishing, so funds are not destroyed — but a payment can become un-received, and in a deliberate double-spend the attacker's conflicting transaction takes its place, which is precisely the outcome confirmation thresholds exist to prevent.

The miner's side of the ledger

Reorgs cost miners directly. A block that gets orphaned earns nothing: its block reward is only spendable if the block stays canonical, and the coinbase's 100-block maturity rule exists precisely so newly minted coins cannot be spent and then erased by a shallow reorg. Well-connected pools and fast block propagation reduce orphan rates for everyone, which is why relay improvements matter to network health. For a home or solo mining operator, the takeaway is the same as for recipients: a found block is real income only after depth accumulates on top of it.

Sovereignty angle

Reorg awareness is part of verifying rather than trusting. Running your own node means you observe reorgs directly instead of learning about them from an explorer, and you apply your own confirmation policy instead of inheriting an exchange's. That policy — how many blocks equals settled, for what amount — is one of the few consensus-adjacent decisions each participant genuinely makes alone.

See confirmations depth and probabilistic finality for the underlying mechanics: Bitcoin never declares a transaction absolutely final, it only makes reversal progressively unaffordable — which, backed by real energy, turns out to be the strongest settlement guarantee ever engineered. Depth is cheap; trusting an unconfirmed promise is not. In a system with no referee, patience is the settlement layer.