Blockchain reorganisations: why confirmations can change
Share this article
Select & copy this link with your device’s copy command.
A blockchain reorganisation happens when a node replaces part of its recent chain with another valid branch. A transaction that appeared confirmed on the old branch may consequently lose that confirmation.
This does not automatically mean fraud or a broken network. It helps to separate a block being seen, a transaction being included & the network’s rules for deciding which history to follow.
Why two branches can exist
In Bitcoin, two miners can produce valid blocks at roughly the same time. Different nodes may learn about different blocks first. Both blocks can reference the same parent, creating competing recent branches.
Bitcoin nodes follow the valid chain with the greatest cumulative proof-of-work. Calling it simply the “longest chain” can hide that distinction: accumulated work matters. Blocks outside the selected branch become stale. Bitcoin’s developer guide explains this selection process.
A small example
Imagine a fictional Bitcoin-like sequence. Everyone initially agrees on Block A. One branch adds Block B, containing Transaction X. Another branch adds Block C, then Block D.
Assume all three new blocks have the same difficulty. The C–D branch has more accumulated work than the B branch, so a node that followed B switches to C–D. If X is absent from C & D, its previous inclusion no longer belongs to that node’s active chain.
The example illustrates competing histories, rather than a transfer between them. X might be included in a later block if it remains valid. That future inclusion is a separate event; it is not guaranteed by the earlier screenshot.
Confirmations describe the current chain
A confirmation count is meaningful only in relation to the chain the observer currently follows. A changing count deserves investigation, but the count alone does not explain the cause.
In our example, two screenshots taken at different times could truthfully show different states for X. To compare them, retain the network, transaction identifier, block identifier & observation time. “It said confirmed yesterday” is less precise evidence.
Finality differs between networks
Ethereum’s proof-of-stake system also distinguishes ordinary inclusion from finality. Validators vote on checkpoint blocks; the protocol uses those votes to justify & finalise checkpoints. Reversing finalised history involves different conditions from replacing a recent unfinalised branch. Ethereum’s finality explanation describes these rules.
A Bitcoin confirmation count & an Ethereum “finalised” label therefore do not describe identical mechanisms. Nor is one website’s waiting policy a universal rule for every chain.
When evaluating a transaction claim, name the network, its reported state & when that state was observed. That is more useful than treating every green confirmation badge as the same promise.
Sources checked 14 September 2026. The branching example is fictional. Information only. 18+.
Discussion
Ask a question, add useful context or share a source. Keep it relevant & respectful.
Comments are reviewed before publication.