Consensus Failure

Overview

Consensus systems are designed around explicit assumptions about faults, message delivery, validator participation, and software behavior. Liveness fails when the network cannot make progress, even though it may avoid conflicting decisions. Safety fails when correct observers can accept incompatible histories or finalized states. A protocol may intentionally sacrifice liveness during uncertainty to preserve safety, so the absence of new finalized blocks is not automatically evidence that ledger history has split.

Operational causes range from infrastructure outages and network partitions to incompatible upgrades or bugs shared by many clients. In weighted BFT systems, losing enough voting power can prevent a quorum, while control or equivocation above the tolerated threshold can threaten safety. Proof-of-work networks can reorganize deeply if an attacker or alternative branch gains sufficient work. The relevant failure mode depends on the active consensus and fork-choice rules.

Payment systems should distinguish delayed confirmation from genuine Consensus Failure. Warning signals include provider disagreement about block IDs, Delayed Finality, unusually deep reorganizations, conflicting quorum certificates, or widespread node rejection. During an incident, automatic release thresholds may no longer be appropriate. Systems should pause irreversible payouts or cross-chain actions when the evidence they normally rely on is unavailable or contradictory.

Recovery can involve restoring connectivity, replacing faulty software, coordinating an upgrade, slashing misbehavior, or socially selecting a chain. Such actions can change assumptions that ordinary transaction logic cannot resolve. Teams need incident procedures that preserve raw observations, stop duplicate processing, and reconcile the eventual Canonical Chain. Post-incident analysis should document whether safety, liveness, or only one service provider failed, because the remediation and customer impact are different.