Finality Threshold

Overview

A finality threshold specifies how much consensus support is required to finalize a block, checkpoint, or state. It converts a set of Consensus Votes into a decision by comparing their valid weight with the protocol’s required quorum. The threshold can be expressed as validator count, stake, voting power, accumulated work, or a combination of conditions.

In many Byzantine fault tolerant systems, more than two-thirds of voting power must support a value. This allows safety when less than one-third is faulty, assuming the protocol and network conditions match the model. Other systems use linked checkpoints, multiple rounds, or separate justification and finalization thresholds. A wallet or bridge must therefore implement the network’s actual rule rather than importing a generic “two-thirds” test.

Threshold calculation requires an exact denominator. Offline, slashed, newly activated, or recently exited validators may be included or excluded according to epoch-specific rules. Signatures must be unique, valid, and bound to the same block and round. Counting duplicate messages, stale validator weights, or votes for descendants as direct support can incorrectly produce a false Finality Proof.

Operational dashboards should show both the required threshold and observed valid support, including which validator set was used. Near-threshold conditions can extend Finality Time even while blocks continue to be produced. Payment teams should not treat high participation as equivalent to finality until the exact protocol rule has been satisfied and independently verified.

When applying Finality Threshold, teams should separate directly observed protocol facts from interpretation. meaningful only when calculated from valid, nonduplicated votes using the correct validator set and protocol rules. For Finality Threshold, keeping the underlying identifiers and validation context makes incident review, reconciliation, and future migrations more reliable.