Every blockchain runs a version of the same game: miners or validators race to extend the chain, and the longest (or heaviest) chain wins. Most of the time this works smoothly — one block gets added, everyone accepts it, the process repeats. But occasionally, two valid blocks get produced at nearly the same time, or a node disconnects and reconnects with a different view of history. The result is a chain reorganization, usually shortened to reorg.
A reorg isn't a hack. It's a feature of how these systems handle disagreement. The chain does what it's designed to do — it resolves competing versions of history and picks one. The interesting question is what happens to the transactions that were in the losing branch.
Think of a blockchain as a tree, even though it's usually depicted as a line. That line is the canonical chain — the path the network has collectively agreed on. But the tree can have branches: short-lived forks that form when two valid blocks are produced at roughly the same time.
This happens more than you'd think. In Ethereum, slots occur every 12 seconds, and validators occasionally produce valid blocks for the same slot. In Bitcoin, two miners might find a valid block within seconds of each other, before either announcement has propagated across the whole network.
When a fork forms, different nodes temporarily hold different views of the chain tip. One group sees Block A as the latest; another sees Block B. Both blocks are valid. Then more blocks get added on top. Whichever branch grows longer (in Bitcoin) or accumulates more validator attestations (in Ethereum) wins. The shorter branch gets abandoned — and this is the reorg. Every node following the losing branch reorganizes its local chain to match the winner.
The transactions in the abandoned blocks don't disappear. They get kicked back to the mempool, where they wait to be included in a future block. Usually they are. But "usually" isn't "always." If a transaction depended on specific ordering, or if the fee was too low to get re-included quickly, there's no guarantee.
Small reorgs — one or two blocks — are routine and unremarkable. Large ones are a different story.
A deep reorg can be weaponized. This is what's meant by a 51% attack: if an attacker controls enough hash power or stake to outpace the honest chain, they can secretly mine a competing branch, make a payment on the public chain, wait for it to get confirmed, then release their longer secret branch and erase that payment from history. Double-spend accomplished.
The attacker didn't break cryptography. They just won the "who has the longest chain" contest. Bitcoin's security model assumes they can't do this consistently — and with the network's current size, they're almost certainly right. With smaller chains, it's already happened. Ethereum Classic, Bitcoin Gold, and Vertcoin have all experienced successful 51% attacks in the last several years.
A few variables determine how dangerous a reorg actually is.
Depth. A one-block reorg is trivially recoverable. A six-block reorg in Bitcoin hasn't happened in over a decade. A twenty-block reorg would represent something close to a crisis.
Attack cost. For Bitcoin, the cost is enormous — you'd need to outpace the entire rest of the network, running on purpose-built ASICs consuming billions of dollars in electricity annually. For a small PoW chain, the same attack might cost a few thousand dollars rented from a cloud mining service. The spread between major and minor chains is dramatic.
Finality model. Ethereum's Casper FFG provides deterministic finality roughly every two epochs — about 13 minutes. Once a checkpoint finalizes, reorganizing it would require destroying at least one-third of all staked ETH, currently around $30 billion worth. That's not a practical attack surface. Pre-finality, though, there's a window where reorgs remain possible, and how the sync committee determines chain head can theoretically be manipulated by a sufficiently large validator.
MEV-related reorgs have drawn research attention. Sophisticated block builders can profit by rearranging transaction ordering within a block. In some scenarios, there's financial incentive to reorg the most recent block and replace it with one that captures more MEV — sometimes called a time-bandit attack or reorg for profit. Ethereum's LMD-GHOST fork choice rule provides some resistance (past attestations aren't cheaply discarded), but the concern is real enough that it shows up regularly in researcher discussions.
Ethereum's roadmap includes Single Slot Finality (SSF) as a long-term objective — finality within one slot rather than across two epochs. If it ships, the reorg window shrinks dramatically, essentially to within a single 12-second slot.
For smaller PoW chains, nothing structural has shifted. The attack surface is the same as it's been: if a chain can be rented by an attacker for a few thousand dollars of hash power for an hour, profit-driven reorgs remain viable.
Single Slot Finality deployed on Ethereum mainnet without incident. No successful deep reorg of a finalized Ethereum checkpoint demonstrated in practice. Smaller PoW chains implementing protocol-level reorg resistance — for instance, mandatory longer confirmation windows for high-value transactions — that holds under adversarial testing.
A successful multi-block reorg on Ethereum before finality, driven by MEV incentives at scale and demonstrating that the current fork choice rule doesn't provide adequate resistance. A confirmed double-spend on a chain previously considered secure by market participants. SSF delayed or shelved indefinitely, leaving the two-epoch window as permanent rather than transitional.
Now: Shallow reorgs are normal network behavior. No active threat to major chains. For Bitcoin, six confirmations remains a standard risk-management convention for large payments. For Ethereum, the pre-finality window (~13 minutes) is what matters for high-value transactions.
Next: MEV-driven reorg incentives are an active research and monitoring area. SSF is on Ethereum's roadmap with no committed timeline as of mid-2026.
Later: Full SSF deployment would materially change the picture — but that's a multi-year horizon.
This covers the reorg mechanism and the threat model around it. It doesn't address transaction replacement rules within the mempool, the economics of mining profitability as it affects attacker feasibility, or how specific exchanges set confirmation thresholds. It's also not guidance on which confirmation depth to use for any particular application — that depends on the value at risk and the specific chain.
The mechanism is what it is. Whether it represents a live concern depends on the chain's size, finality model, and the value of what's being transacted.




