Question from BitcoinTalk: “My Bitcoin transaction disappeared. Someone said there was a reorg. What happened?”
Short answer: A blockchain reorg (reorganization) happens when two miners find blocks at the same time and the network eventually chooses one chain over the other. Your transaction may appear to “unconfirm” but it will reconfirm on the winning chain. Deep reorgs (more than 2-3 blocks) are extremely rare on Bitcoin.
What Causes a Reorg
Miners race to find new blocks. Sometimes two miners find valid blocks at nearly the same time. The network temporarily splits into two versions.
The rule: The longest chain (most accumulated proof of work) wins. When one chain overtakes the other, miners abandon the losing chain and its blocks are “reorganized” (reorged) out.
Example:
- Block 100,001 is found by Miner A
- Block 100,001 is also found by Miner B (at the same time)
- Half the network builds on A’s block, half on B’s block
- Miner A finds Block 100,002 — now A’s chain is longer
- Miners on B’s chain switch to A’s chain
- B’s block 100,001 is “reorged” out — transactions in it return to unconfirmed
How Many Confirmations Are Safe
| Blockchain | Safe Confirmations | Time | Reorg Risk |
|---|---|---|---|
| Bitcoin | 6 confirmations (~60 min) | Very low | ~0% |
| Ethereum | 12-20 (~3-5 min) | Low | <0.1% |
| Solana | 1 (block is final) | 400ms | Very low |
| Litecoin | 6-12 (~15-30 min) | Very low | ~0% |
| Polygon | 64 (~10 min) | Low | <0.1% |
| Most PoS chains | Finality after 1 epoch | Minutes | Low |
What this means: When an exchange or wallet says “wait for 6 confirmations” before treating a Bitcoin transaction as final, this is why — to ensure no reorg can undo it.
Deep Reorgs: When to Worry
Most reorgs are 1 block deep and happen daily on every proof-of-work chain.
Deep reorgs (3+ blocks) are rare because:
- The network is widely distributed
- Miners have financial incentives to build on the longest chain
- Mining pools coordinate to avoid deep reorgs
Notable deep reorgs:
- Bitcoin (2013): ~30 blocks during a software bug (resolved quickly)
- Bitcoin Cash (2018): Multiple deep reorgs during hash wars
- Ethereum Classic (2020): Multiple deep reorgs during 51% attacks
A 51% attack (where one entity controls >50% of hashing power) can cause deep reorgs, but this is economically impractical for major chains.
What to Do During a Reorg
Nothing. Your transaction will reconfirm on the winning chain. If you received crypto and it was “undone” by a reorg, the sender can resend once the chain stabilizes.
Verdict
Reorgs are a normal part of how proof-of-work blockchains reach consensus. Exchanges and services account for this by waiting for sufficient confirmations before treating transactions as final. One-block reorgs happen daily; deep reorgs are extremely rare on major chains.
Related: How Blockchain Works | Proof of Work vs Proof of Stake | How to Check Transaction Status
Practical steps if you are building on or accepting crypto
If you run a business that accepts Bitcoin or other proof-of-work crypto, set a confirmation policy that matches your risk tolerance. For small-value goods — coffee, digital downloads — one confirmation may be acceptable because the cost of a successful reorg attack far exceeds the sale price. For high-value transactions, six confirmations on Bitcoin or the equivalent on another chain is the industry standard. Exchanges use this same logic when they credit your deposit.
If you are a developer building on a chain that experiences reorgs, design your application to be idempotent. That means a transaction arriving a second time (after a reorg) should not trigger duplicate side effects. In practice this means checking whether an order, credit, or state change has already been processed before acting on the re-included transaction. Wallets and block explorers handle this automatically, but application-level code must account for it.
For individual holders, reorgs are essentially invisible. Your wallet will show a transaction drop from confirmed to unconfirmed and then re-appear as confirmed on the new chain. The only time a reorg matters to you is if you relied on a single confirmation to make a decision — sending goods, crediting an account, or spending received funds before they were deep enough.
How to verify a reorg actually happened
If someone claims a reorg affected your transaction, you can check for yourself. Go to a block explorer such as mempool.space (for Bitcoin) or Etherscan (for Ethereum) and look at the block height at the time your transaction was first included. If that block is no longer in the main chain — if the explorer shows it as orphaned or no longer part of the canonical head — a reorg occurred. Most explorers flag orphaned blocks clearly. Comparing the block hash your wallet recorded with the current chain tip is another way to confirm whether your original block survived the reorg.
Because shallow reorgs are invisible to most users, they rarely warrant concern in isolation. The confusion usually arises when a payment that looked confirmed suddenly appears unconfirmed again — for example a merchant who accepted a single confirmation and later saw the funds revert. Understanding that this is a normal, revisable state of the network, rather than a sign that funds were stolen, is what separates a useful reaction from a panicked one. For any transaction that matters, the confirmation threshold exists precisely to make these reversals an astronomically unlikely outcome before you rely on the payment.