A transaction can be "confirmed" one minute and gone the next. That is a chain reorganization, or reorg: the network discards a block your transaction was in and continues from a different branch. Most of the time it is harmless and one block deep. Occasionally it is an attack that reverses millions of dollars. Either way, if your code treats the latest block as settled, a reorg is where it breaks.
This explainer covers what a reorg is, why chains do it on purpose, how deep they can go, and how to handle them safely in production.
What Is a Reorg?
A reorg happens when a node discards a chain of blocks it had previously accepted as the head and switches to a different, competing branch the protocol now considers better. The discarded blocks become orphaned, and any transactions that lived only in them fall back into the mempool or disappear.
Nodes do this on purpose, following the fork-choice rule: a deterministic rule for picking the canonical chain when competing branches exist.
- Bitcoin and other Nakamoto PoW chains follow the heaviest chain, the branch with the most accumulated proof-of-work.
- Ethereum (PoS) uses LMD-GHOST, which picks the branch with the greatest weight of validator attestations.
- Avalanche (Snowman) converges nodes onto one branch through repeated sub-sampled voting.
When a node sees a competing branch that scores higher under its rule, it reorgs to it. This is designed behavior, not a bug.
Why Reorgs Happen
Natural, shallow reorgs. Two valid blocks can be produced at almost the same height before the first has propagated across the network. Some nodes build on one, some on the other, and the fork-choice rule resolves the tie. These are typically one block deep and benign, a normal consequence of propagation latency.
Consensus edge cases. Ethereum's notable 2022 reorg (below) came from a late block proposal combined with clients adopting a fork-choice patch inconsistently. No attacker involved, just a timing and implementation mismatch.
Malicious, deep reorgs. An attacker with enough resources builds a competing chain in secret, then releases it to overtake the public one:
- 51% attack: controlling a majority of hashpower lets an attacker rewrite recent history and double-spend.
- Selfish mining: withholding mined blocks to build a hidden lead.
- Finality attacks (PoS): reverting a finalized Ethereum block requires controlling two-thirds of stake or burning at least one-third of all staked ETH, which is economically punishing by design.
How Deep, and What Breaks
| Depth | Cause | Typical impact |
|---|---|---|
| 1 block | Near-simultaneous blocks, latency | Benign; a few transactions briefly re-ordered or returned to the mempool |
| 2 to 7 blocks | Consensus timing bug, network partition | Dropped or re-ordered transactions, indexer confusion; exchanges should not have credited yet |
| Deep (hundreds+) | 51% or majority attack | Double-spends, stolen exchange deposits, reversed settlement |
The damage is almost always about treating an unconfirmed state as final:
- Double-spends: a payment "confirmed" in an orphaned block is reversed, and the attacker re-spends the same coins.
- Dropped transactions: anything only in orphaned blocks returns to the mempool or vanishes.
- Broken dApp and indexer state: anything that read
latestand acted on it may now be wrong. - Exchange deposit crediting: the classic loss vector. Confirmations exist precisely so you wait until a reorg of that depth is implausible before crediting.
Reorgs in the Wild
- Ethereum, May 2022: a seven-block reorg on the beacon chain, the deepest in years, caused by a late proposal plus uneven client adoption of the proposer-boost fix. Finality was never lost; it was a timing issue, not an attack.
- Ethereum Classic, January 2019: a 51% attack reorged 100+ blocks and double-spent ~$1.1M; Coinbase detected the deep reorg and Gate.io confirmed multiple double-spends.
- Ethereum Classic, August 2020: three 51% attacks in one month, with reorgs of 3,693, 4,000+, and 7,000+ blocks. ETC later deployed defenses to make deep reorgs exponentially costlier.
- Bitcoin Gold, May 2018: a 51% attack double-spent ~$18M from exchanges.
How Chains Reduce or Eliminate Reorgs
The fix for deep reorgs is finality, the guarantee that history past a point cannot change.
- Ethereum (post-Merge) finalizes checkpoints roughly every two epochs (about 12.8 minutes). Reverting a finalized block requires validators to burn a third of all staked ETH.
- Polygon PoS cut finality to about 5 seconds with Heimdall v2 (July 2025), capping reorg depth at two blocks, and its Rio upgrade (October 2025) moved to a validator-elected block producer that Polygon states eliminates reorgs entirely.
- BFT chains (CometBFT/Tendermint, Avalanche) finalize each block as it is committed, so there are no reorgs by construction.
We go deeper on this in blockchain finality explained.
What This Means for Your Code
Reorgs are why "wait for confirmations" exists. In practice:
- Use the right block tag. On EVM JSON-RPC,
latestis the newest block and can be reorged;safeis recent and unlikely to reorg;finalizedis settled by Casper FFG and effectively cannot be reorged. Uselatestfor general reads,safefor status, andfinalizedbefore anything irreversible like a payout, bridge mint, or deposit credit. - Handle
removedlogs.eth_getLogsand log subscriptions signal reorgs through theremovedfield: when a block is orphaned, its logs are re-sent withremoved: true, and the new branch's logs are emitted. The same transaction's logs can therefore arrive more than once. - Make indexers idempotent. Treat
removed: trueas a rollback, design writes so replays do not double-count, and read at finalized depth for irreversible bookkeeping.
These reads run through your RPC endpoint, so a provider that reliably serves finalized reads and clean log streams is part of getting reorg handling right. See what is RPC in blockchain for the basics.
The Takeaway
A reorg is the chain doing exactly what it is designed to do: follow the branch the fork-choice rule says is canonical. Shallow reorgs are routine and harmless; deep ones are attacks that finality is built to prevent. The practical lesson is the same at every scale: do not treat latest as settled. Wait for confirmations or finality proportional to what is at stake, and make your indexing reorg-aware.
Building something that needs reliable finalized reads and reorg-safe log streams? Create a free Dwellir account for an endpoint across 100+ networks.
