⏪ Chain Reorganization: Rewriting Recent History
See how the network replaces a shorter chain with a longer, valid one
Your Progress
0 / 5 completed🔄 Chain Reorganization
A chain reorganization (or "reorg") happens when your node switches from one version of blockchain history to another. Let's understand when and why this occurs!
🎯 What is a Reorg?
Imagine you're following Chain A, believing it's the main blockchain. Suddenly, Chain B appears with more accumulated work. Your node must "reorganize" - abandoning Chain A and switching to Chain B.
🎮 Interactive Reorg Simulator
Adjust the reorganization depth and watch what happens:
Block #10 is the fork point. Chain A continued but Chain B (with reorg depth of 3) had more accumulated work, causing blocks 11-13 to be orphaned and replaced.
⚠️ Reorg Depth & Safety
The deeper the reorganization, the more risky it becomes. This is why services wait for multiple confirmations!
Very unsafe - reorgs common
Moderate safety - exchanges wait
Bitcoin standard for transactions
High confidence threshold
🔍 Anatomy of a Reorg
Your node receives blocks from a competing chain. Initially ignores them if they're shorter.
Node calculates accumulated proof-of-work. Competing chain now has MORE total work than current chain.
Node disconnects current tip blocks back to fork point. These blocks become "orphaned" or "stale."
Competing chain's blocks are validated and connected. Transactions from orphaned blocks return to mempool.
Account balances, UTXO set, and smart contract states are recalculated based on new history.
💡 Key Insights
1-2 block reorgs happen regularly. They're a natural part of distributed consensus, not a security failure.
6+ block reorgs are extremely unusual and could indicate an attack or serious network issues.
The more valuable the transaction, the more confirmations you should wait for before considering it final.
Block explorers show reorg events. Services monitor these to detect potential network issues or attacks.