Reorgs: How a Confirmed Transaction Can Un-Happen

A reorganisation happens when the network switches from one version of recent history to another. Blocks that were part of the chain are discarded, and the transactions in them return to the pending state.

This is normal, expected, and the reason confirmation thresholds exist.

Why it happens

Two miners or validators can produce a valid block at nearly the same moment. Both propagate. Different parts of the network see different blocks first, and for a short period two competing versions of the chain exist.

The tie resolves when the next block arrives, extending one branch. Nodes following the shorter branch switch to the longer one. The discarded block is orphaned and its transactions go back into the mempool, where they will be included in a subsequent block.

Nothing has gone wrong. This is the protocol functioning under the constraint that information takes time to travel.

How deep they normally go

On major proof-of-work chains, one block deep is routine and two is uncommon. Anything deeper is rare enough to be individually notable.

On proof-of-stake chains with explicit finality, reorgs can occur among recent blocks but cannot extend past the finalised point without validators being penalised severely. That boundary is the practical guarantee.

Why exchanges wait for confirmations

Each additional block on top of a transaction makes reversal exponentially less likely, because an attacker would have to outpace the entire network across all of them.

A venue crediting a deposit is taking a risk that the transaction is reversed and the credited funds are gone. Their confirmation requirement is a risk decision, calibrated to the value and the chain.

This is why deposit crediting times differ between assets and between venues, and why the threshold is higher for larger amounts at some platforms. Venues that publish their confirmation requirements, such as a platform with real on-chain withdrawals, let you predict when funds will be available rather than guessing.

The attack version

A deliberate deep reorg is a double spend. The attacker pays someone, waits for the payment to be accepted, then produces a longer chain in which the payment never occurred.

On large networks this requires an enormous share of hash power or stake, sustained long enough to outpace everyone else, and it destroys the value of the asset being attacked in the process. This is why it has not happened on major chains.

On small networks it has happened repeatedly. A chain whose total hash power can be rented for a few thousand dollars an hour is genuinely vulnerable, and several have suffered successful double spends.

What it means for you

For ordinary transactions, nothing. Wait for the confirmations your wallet or venue requires and the transaction is settled.

For large amounts, wait longer. The confirmation threshold that is appropriate for a small payment is not appropriate for a large one.

On small chains, be considerably more cautious. The security of a chain is proportional to the cost of attacking it, and that cost varies by orders of magnitude between networks.

Watching one happen

Block explorers show orphaned blocks. Several sites track them specifically, and watching the rate over time is the most direct way to understand how often this occurs.

For most major networks the answer is: frequently enough to matter for the first confirmation, and almost never beyond the third.