Consensus Quorum

Overview

Byzantine fault tolerant protocols often require more than two-thirds of voting power to commit a block, assuming less than one-third is faulty. Other stages can use different thresholds, and proof-of-stake finality rules can evaluate votes across checkpoints or epochs. The precise inequality matters: “two-thirds” and “more than two-thirds” are not always equivalent at boundary values. Implementations should follow the protocol specification rather than a rounded dashboard percentage.

Quorum is based on eligible voting power at a defined state. Votes from inactive, removed, duplicated, or incorrectly authenticated validators do not count. The verifier must use the validator set and weights applicable to that height or epoch. An Aggregate Signature can compress evidence, but the signer bitmap or public-key set is still needed to calculate whether the required weight participated.

Failure to reach quorum usually affects liveness. The network may stop committing or finalizing blocks while preserving safety. Reaching quorum for conflicting decisions can indicate that too much voting power equivocated or that verification used inconsistent validator sets. Payment systems should therefore distinguish “quorum not yet observed” from “quorum impossible” and from evidence of conflicting quorums, which have very different risk implications.

Operational monitoring should track participation by weight, not node count, and should identify delayed or missing Consensus Vote messages. Settlement logic should rely on verified quorum evidence or finalized state supplied by a trusted consensus client, not an unauthenticated percentage from an explorer. Cross-chain verifiers must also confirm that the quorum certificate belongs to the correct network, block, round, and validator-set transition.