Blockchain Reorganizations Can Remove Confirmations Without Erasing Transactions

A crypto transfer can show confirmations and later appear pending if nodes switch to a different valid branch. That change affects which blocks make up the active chain; it does not rewrite a transaction inside a block that has been removed from that chain.

Nodes may temporarily follow separate branches when blocks reach them at different times. They use the network’s rules to settle on a branch. Bitcoin (BTC) nodes compare the cumulative work of valid candidate chains, so the branch with more blocks does not necessarily win if another has more accumulated work.

A transaction’s status after a reorganization depends on the branch nodes adopt. If the replacement branch includes the same transaction, it remains in the active chain, though its block and confirmation count may change. If the branch leaves it out, the transaction may be included later, but that is not guaranteed. If the new history includes a conflicting transaction, the original may no longer be valid.

A pending display or deposit delay alone does not establish that a reorganization occurred. A failed transaction, a pending transaction, a replacement transaction and a service provider’s delay in crediting a deposit can occur without any change to the accepted chain. These cases need to be distinguished from blocks actually leaving the active chain.

Reorganizations are not automatically attacks. Differences in block propagation can create short-lived forks. On proof-of-work networks such as Bitcoin, majority computing power can help an attacker build a competing branch, but 51% is not a threshold below which reorganizations cannot happen. Majority power also does not make a block that breaks the network’s rules valid to nodes that enforce those rules.

A reorganization and a double spend describe different things. A reorganization is a change in which transaction history nodes accept; a double spend involves conflicting payments. A recipient may face a loss if a replacement branch drops the payment they relied on and accepts a conflicting one. If the adopted branch retains the original payment, a reorganization alone does not establish that a double spend succeeded.

Ethereum separates choosing the chain head from finalizing checkpoints. Its Gasper consensus system uses LMD-GHOST for chain selection and Casper FFG for finality. Before a block is finalized, nodes may switch to another branch. Finalized history has stronger protection; conflicting finalized histories would signal a serious consensus security failure involving slashable violations by at least one-third of the stake weight.

Confirmation counts and finality describe different protections. A confirmation count measures how deeply a transaction sits in the currently accepted chain. Finality describes the protocol’s assurance that history will not be reversed. Bitcoin’s six-confirmation mark does not make a reorganization impossible, and it is not equivalent to Ethereum’s finalized status.

Layer 2 networks can have their own confirmation stages. In a standard OP Stack system, unsafe data still depends on the sequencer’s history. Safe data can be derived from Ethereum data but remains subject to a reorganization of the corresponding Ethereum block. Finalized data has Ethereum’s finality protection. A challenge to an invalid withdrawal claim in the standard bridge does not itself reorganize the Layer 2 chain.

When a confirmation count changes, checking the transaction hash and network, whether its block remains in the active chain, and other nodes or network announcements can help distinguish a reorganization from a display or synchronization issue. A pending status alone does not show that the original payment failed or that it should be sent again.