Finality Violation

Overview

A finality violation is a safety failure in which two conflicting blocks, checkpoints, or state histories both satisfy the system’s finalization rule. Once this happens, honest applications can receive valid-looking but incompatible Finality Proofs. The event is more serious than a normal fork near the chain head because the protocol has certified mutually exclusive outcomes.

The distinction between safety and liveness is essential. If validators stop reaching a quorum, finality may be delayed while the last finalized checkpoint remains unchanged. That is a Consensus Failure or liveness incident, but not yet a violation of finality. A violation requires conflicting finalized decisions, not simply missing new ones.

Possible causes include equivocation by enough voting power, compromised validator keys, inconsistent client implementations, a flawed validator-set transition, or a verifier that counts signatures incorrectly. Evidence should identify the conflicting roots, validator set, signed messages, voting weights, rounds, and fork versions. Without preserved raw evidence, later analysis may confuse an RPC inconsistency with a true protocol-level failure.

Response procedures should halt high-risk settlement, compare independent clients, preserve signatures, and determine whether one history resulted from invalid verification. Bridges and custodians may need emergency controls because assets can be released on both sides of a conflict. Any recovery that chooses one finalized branch over another creates a Finality Reversion for users who relied on the discarded branch.

When applying Finality Violation, teams should separate directly observed protocol facts from interpretation. a finality violation means conflicting histories were both certified as final; delayed finality alone does not constitute this safety failure. For Finality Violation, keeping the underlying identifiers and validation context makes incident review, reconciliation, and future migrations more reliable.