Consensus Bug and Chain Split
A defect in the consensus rules or in their implementation makes nodes disagree about valid history, halting the chain or splitting it into two.
How it happens
Every full node independently validates blocks against a rule set, and the network only functions while all of them reach the same verdict on the same data. A bug in serialization, in a database layer, in signature checking, or in a newly activated rule can cause one group of nodes to accept a block that another group rejects, at which point the chain forks and both sides continue building. Some bugs are worse than a split: an inflation bug can create units that the rules were meant to forbid, and a liveness bug can stop block production entirely until operators coordinate a restart. Resolution requires human coordination among developers, operators, and exchanges, and any transaction confirmed on the losing branch is reversed.
What you can actually observe
Look for a public incident history of halts, deep reorganizations, and emergency releases, and for whether the chain has a documented restart procedure. Client diversity data shows how many independent implementations validate the rules, and time-to-finality or confirmation-depth conventions show how long a reorganization can plausibly reach back. Post-incident write-ups, when they exist, are the most informative disclosure a chain publishes.
Precedent
Bitcoin's 2010 value overflow incident produced a transaction creating units the rules were meant to forbid and required a patched release and a reorganization, and a 2013 split between two Bitcoin Core versions with different database behavior was resolved only when operators coordinated a return to the older rules.
What makes it more or less material
Consider how many independent client implementations exist, whether the chain has halted before, how deep a reorganization the finality design permits, and how quickly exchanges and bridges would notice a divergence.
Related factors
Assets this applies to
The largest assets we classify in the categories this factor applies to. Presence here means the factor is relevant to that kind of asset, not that it has occurred.