Block Reorganization Reorg

Block reorganization is a phenomenon in which a certain chain is replaced after a temporary fork of the blockchain. This entry explains how Reorg affects transaction confirmations, security, and exchange deposit wait times.

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

Chain Reorganization (Reorg) is a process in which a node abandons a block it originally accepted and uses another chain that complies with consensus rules as the main chain. It illustrates that “the transaction has entered the block” and “the transaction has achieved sufficient finality” are not the same thing.

Each block references the hash of the previous block. When two blocks in the network are generated almost at the same time, some nodes may see block A first, and other nodes may see block B of the same height first, thus temporarily forming two valid branches. The subsequent branch with a higher consensus weight wins, and the node switches over. The replaced blocks on the original branch are called orphan blocks, stale blocks or removed blocks. The specific names vary from chain to chain.

Reorganization does not modify the content of an existing block. Hash linking causes direct modification to destroy subsequent references; what the node actually does is to undo the state changes brought about by the old branch and then execute the transactions in the new branch. Old branch transactions may also appear on the new chain, be re-entered into blocks later, or be completely invalidated due to conflicts.

How it works

Nodes follow the fork selection rules specified by the consensus. Proof-of-work networks typically compare cumulative work, rather than mechanically comparing the number of blocks; proof-of-stake networks may incorporate validator voting, checkpoints, and finality rules. The so-called “longest chain” is just a simplified expression. More accurately, it is “the effective chain with the highest consensus weight.”

An ordinary reorganization usually goes through:

Two block producers publish blocks of the same height at close times.
Network propagation delay allows nodes to temporarily see different chain heads.
The next batch of blocks or voting gives a branch a higher weight.
The node on the other side finds the common ancestor and rolls back the old branch state.
The node executes the new branch block and updates the transaction pool and account status.

One-level reorganization only replaces one block at the chain head, which is more common and has limited impact. A reorganization with a depth of 6 means that the last 6 blocks have been replaced, which may involve more transactions and significantly increase the suspicion of anomalies or attacks. Different networks have different block production speeds, validator distribution and finality designs, and the same confirmation number cannot be used to measure security.

Example

Suppose a certain proof-of-work chain produces one block every 10 minutes on average. When a transaction first enters a block, it is confirmed once; when it is followed by five blocks, it is usually confirmed six times, and it takes about 60 minutes. If there is only one level of competition caused by two miners producing blocks at the same time, the first confirmation is most likely to be replaced; with each additional level, the resources required for attackers or lagging branches to catch up usually increase, but the probability will not be simply “cleared”.

Assume further that the exchange receives a deposit worth 50 USDT and a deposit worth 5 million USDT. Even if the two are on the same network, the platform may require manual review or more confirmations for large deposits because the losses caused by a reorganization are different. Confirmation policies are risk management parameters, not chain protocol commitments.

Proof-of-stake chains may provide economic finality. For example, after a block reaches a certain type of checkpoint, it will not be rolled back normally unless a large number of validators violate the rules and bear penalties. This finality is different from “a few seconds have passed” and is subject to the protocol definition and client state.

Risks

A reorganization can return a previously confirmed transaction to the mempool, include it in a new order, or invalidate it because of a conflict. Risk increases with transaction value, reorganization depth, block-producer concentration, and weak finality. Confirmation requirements should vary by network and exposure.

Common misconceptions

Myth 1: Once confirmed, it is absolutely irreversible

Probabilistic finality networks may still undergo shallow reorganization after the first confirmation. More confirmations are generally more stable, but “enough” depends on the network and the amount.

Myth 2: Reorganization means the blockchain is hacked

Short-term forks may be normal network competition. Only by combining depth, frequency, conflicting transactions and computing power or validator anomalies can we determine whether it is an attack.

Myth 3: Transactions in removed blocks must disappear

Valid transactions without conflicts can usually be returned to the transaction pool and confirmed again. What really matters is whether the input has been consumed by other transactions on the new chain.

Myth 4: 12 confirmations on all chains are equally safe

Block time, consensus weight, participant concentration and finality rules are different, and the number of confirmations cannot be directly compared across chains.

Sources

Blockchain Technology Overview - NIST (accessed: 2026-07-28)
Bitcoin Developer Guide - Bitcoin.org (accessed: 2026-07-28)