What Is a Reorg (Chain Reorganization) in Blockchain Terms?
Blockchains are often described as permanent and unchangeable, and for the most part that’s true. But there’s a specific, well-understood exception that happens near the very front of the chain, before enough time has passed to lock things in place.
The short answer
A chain reorganization, or reorg, happens when a blockchain network replaces a set of its most recently added blocks with a different, competing set that ends up being longer or otherwise deemed more valid by the network’s rules. This typically happens only to very recent blocks, not deep history, and it’s the underlying reason confirmations matter: waiting for more confirmations reduces the chance that a specific transaction ends up on the losing side of a reorg.
Why competing versions of the chain can briefly exist
This is one of several ways a blockchain can behave differently from a traditional centralized database, where a single authoritative record never needs this kind of self-correction. Blockchain networks are decentralized, with many independent nodes and miners or validators working somewhat simultaneously. Occasionally, two valid blocks get created and propagated across the network at nearly the same time, creating a temporary fork where different parts of the network are, briefly, following different versions of the most recent history. The network’s consensus rules include a method for resolving this, typically by favoring whichever chain has more accumulated work or validation behind it. Once one version wins out, nodes following the other version switch over, and the blocks unique to the losing version get discarded, which is the reorg itself.
What happens to transactions caught in a reorg
- Transactions in the discarded blocks return to an unconfirmed state. They generally don’t just disappear; they typically go back into the pool of pending transactions and get included in a future block, assuming they’re still valid.
- Very recent activity is most exposed. Reorgs almost always affect only the newest blocks, since the further back in the chain a block is, the more accumulated confirmation it has, making it exponentially harder to displace.
- Deep reorgs are treated as serious events. A reorg reaching many blocks deep would suggest a fundamental problem with network consensus, and established, well-secured networks are designed to make that extremely unlikely.
Why this connects to confirmation counts and pending status
This is the underlying reason exchanges wait for multiple confirmations before treating a deposit as final rather than crediting it the moment it first appears in a block. A transaction with just one confirmation carries a small but real chance of ending up in a block that gets reorganized away; a transaction with many confirmations behind it is dramatically more resistant to that outcome. That’s directly related to why a transaction shows a pending status while it accumulates those confirmations rather than being marked complete immediately.
How this differs from a security attack
A routine reorg caused by two blocks arriving close together in time is a normal, expected part of how decentralized consensus occasionally resolves itself, and it’s distinct from a deliberate attempt to manipulate the chain’s history. A 51 percent attack describes a scenario where an entity controlling a majority of a network’s mining or validating power could deliberately engineer a deep reorg to reverse their own transactions, which is a fundamentally different and far more serious situation than the routine, shallow reorgs that happen naturally on healthy networks.
What to weigh
Reorgs are a normal part of how many blockchain networks reach consensus, and the confirmation-based systems exchanges and wallets use exist specifically to manage the risk they pose. Understanding that recent activity is inherently less final than older activity is a useful mental model, particularly for larger transactions where waiting for additional confirmations before treating funds as fully settled is a reasonable precaution.
The bottom line
A reorg isn’t a sign that something has broken; it’s a visible sign that the network’s consensus process is working as designed, briefly sorting out which version of very recent history the rest of the chain will build on.