Reorg (Reorganization)

Security Updated Jul 2026

What is a Reorg?

A reorg (reorganization) occurs when a blockchain replaces a previously accepted chain of blocks with a different chain. Transactions that appeared to be confirmed can be reversed — the most extreme case being a 51% attack where an attacker deliberately causes reorgs to double-spend.

Reorgs happen naturally in Proof of Work systems when two miners solve blocks simultaneously. The network temporarily has two competing chains, and the longer one (more accumulated work) wins.

How Natural Reorgs Work

  1. Two miners solve a block at roughly the same time
  2. The network splits — some nodes see Chain A, others see Chain B
  3. The next miner builds on one of the chains (say Chain A)
  4. Chain A is now longer, so all nodes switch to it
  5. The blocks from Chain B are “orphaned” — their transactions are reversed

This is normal and happens frequently. It’s why exchanges require multiple block confirmations before crediting deposits — to ensure a reorg doesn’t reverse the transaction.

Depth of Reorgs

DepthDescriptionRisk
1 blockNormal occurrenceVery low risk — happens regularly
2-6 blocksRare but possibleLow risk — exchanges wait for this many
7+ blocksAbnormalCould indicate attack or severe network issues
50+ blocksAttack51% attack or catastrophic consensus failure

Malicious Reorgs (51% Attacks)

When an attacker controls the majority of hash power (PoW) or stake (PoS), they can deliberately create longer chains to:

  1. Double-spend — send a transaction, let it confirm, then reorg the chain to replace it
  2. Censor — exclude specific transactions from the chain
  3. Disrupt — cause chain instability, undermining trust

Notable 51% Attack Reorgs

ChainYearReorg DepthLoss
Ethereum Classic20193,000+ blocks$1.1M
Bitcoin Gold201822 blocks$18M
Verge2018Multiple$1.7M+

Reorgs on Proof of Stake

Ethereum’s PoS (post-Merge) is designed to make deep reorgs extremely difficult:

  • Finality: After 2 epochs (~12 minutes), blocks are finalized — reorging finalized blocks requires 1/3 of all validators to be slashed (massive economic penalty)
  • LMD-GHOST: The fork-choice rule favors the heaviest accumulated attestations, not just the longest chain

However, pre-finality reorgs (within the 12-minute window) are still theoretically possible if enough validators act maliciously.

How to Protect Against Reorgs

  1. Wait for sufficient confirmations — for large transactions, wait for more blocks
  2. Use chains with strong finality — PoS chains with fast finality (Cosmos, Ethereum post-Merge) reduce reorg risk
  3. Monitor for suspicious chain depth — if a chain has unusually frequent deep reorgs, treat it as high-risk
  4. Don’t accept zero-confirmation transactions — wait for at least 1 block confirmation

Frequently Asked Questions

Q: How many confirmations are enough? A: For Bitcoin, 6 confirmations is the standard for high-value transactions (about 1 hour). For Ethereum, 12-35 confirmations depending on the value. For smaller chains, you may need more — especially if the chain has a history of 51% attacks.

Q: Can a reorg happen on Ethereum after The Merge? A: Pre-finality reorgs (within ~12 minutes) are theoretically possible but very rare and expensive. Post-finality reorgs are practically impossible — they’d require destroying 1/3 of all staked ETH (billions of dollars).

Q: What happens to my transaction if it’s reorged out? A: Your transaction returns to the mempool and may be included in a future block. If it was part of a double-spend attack, it might be permanently replaced by the attacker’s conflicting transaction.