Chain Reorganization

Overview

How a blockchain can briefly disagree with itself

A blockchain network is operated by many participants who may not learn about new blocks at precisely the same time. Two valid competing blocks can be produced near one another, so different nodes may temporarily see different tips of the chain. The network's consensus rules determine which branch becomes canonical. A chain reorganization, often called a reorg, occurs when a node replaces some of its recent chain history with another valid branch. Transactions in the removed blocks may return to a pending state or appear differently in the accepted chain.

How the underlying system works

A node generally follows the chain-selection rules of its consensus protocol. Competing blocks, network delays or other protocol-specific events can change which recent history is canonical. The frequency and consequences vary significantly among blockchains; an Ethereum finalized checkpoint is not equivalent to an ordinary recent Bitcoin block.

Payment monitoring must account for transactions that were previously recorded as included and are then no longer found in the accepted chain. Systems should re-evaluate confirmation counts, reverse provisional internal events when appropriate and avoid duplicating credits if a transfer reappears. An audit log should retain both the old observation and the new canonical evidence. High-value transfers justify stronger finality requirements.

Why a confirmed-looking payment can need rechecking

A merchant receives a transaction and sees it included in block 800. Before the merchant's chosen confidence threshold is met, the network adopts a competing branch that does not include that transaction. The payment service must update its observation instead of assuming that the first block was permanent. The transaction might later be included again, but that is a new observation with new block context. Systems that track only a txid and one initial confirmation may miss this change. The provider should keep block references and revisit recent blocks after chain updates.

Reorganizations and finality are chain-specific

Short-lived reorganizations have different frequencies and consequences across protocols. In finality-based proof-of-stake designs, reorganizing finalized history can be far more severe than changing a not-yet-finalized head. Avoid borrowing Bitcoin terminology mechanically for other networks. A merchant's system should distinguish detected, included, sufficiently confirmed and finalized states as relevant. Reorg handling also needs idempotent database updates so it does not create duplicate orders or impossible state regressions without an audit record.

Further reading and related concepts

Reference documents: Bitcoin Developer — Block Chain, Ethereum.org — Gasper and Finality.

Related glossary topics: Confirmation, Transaction Finality, Bitcoin (BTC).