Occasionally a block that appeared in a wallet or explorer disappears, and the transactions in it are back to pending. This is a reorganisation, and it is a normal outcome of a distributed system rather than a fault.

Simultaneous production is inevitable

Block producers work independently and cannot know instantly what others have done. Information takes time to travel between nodes.

If two producers extend the same parent at roughly the same moment, both blocks are valid and both propagate, reaching different parts of the network first.

For a short period the network genuinely disagrees about the tip of the chain, with each side following the block it saw first.

The fork choice rule settles it

Every node follows a rule for selecting among competing branches, usually the one with the most accumulated work or the most attesting stake.

When the next block arrives on one branch, that branch wins under the rule, and nodes on the other side switch to it.

Switching means discarding the losing block and reapplying its transactions where they still make sense. That reapplication is the reorganisation users observe.

Depth is what makes reversal expensive

Single-block reorganisations are common on fast chains and unremarkable. They resolve within seconds and affect nothing that waited.

Reversing a block that already has several successors requires rebuilding all of them faster than the rest of the network extends the current chain.

The cost of that grows steeply with depth, which is exactly why confirmation counts exist and why high-value transfers wait longer than small ones.

Not every reorganisation is accidental

A producer that discovers a highly profitable opportunity in the previous block can attempt to rebuild that block and capture the value instead.

Whether this is worthwhile depends on the reward available compared with the reward for simply extending the chain, so protocols try to keep the ordinary option more attractive.

Penalties for equivocation in stake-based systems attack the same problem directly, by making the attempt costly regardless of what it might capture.

Finality rules cut the tail off

Networks with explicit finality mark blocks as irreversible once enough validators have committed to them, after which a reorganisation is not merely unlikely but a protocol violation.

Reorganisations can still occur below that point, in the recent blocks that have not yet been finalised.

Applications built on such chains therefore distinguish between the fast, revisable tip and the settled portion beneath it, and anything with financial consequence waits for the second.