Consensus Safety Checklist

When we audit a Layer-1 consensus protocol, we are not looking for “bug bounties.” We are looking for the exact set of assumptions that, if violated, let two conflicting blocks become final. This checklist is the one we run internally before we sign off on a review.

1. Quorum intersection under view changes

A BFT protocol remains safe only if every pair of quorums shares at least one honest validator. The math is simple: with n = 3f + 1 and quorum q = 2f + 1, any two quorums intersect in f + 1 nodes, at least one of which must be honest. The part teams forget is that this intersection must hold across views, not just inside a single height. If the leader changes between PREVOTE and PRECOMMIT and the timeout lengths allow old votes to be reused, a double quorum becomes possible.

Red-team question

Can a validator be induced to lock on a block in one view and then vote for a competing block in a later view without unlocking? If the answer is not an immediate “no,” there is a safety bug.

2. Message replay and height confusion

Votes and commits must be bound to (height, round, blockHash). We have seen production code where the commit message omitted the round number. An attacker can replay an old commit certificate in a later round, and nodes that do not check the round accept it as a valid finality proof. Binding every message to a monotonic, chain-wide (height, round) tuple is the minimum.

3. Equivocation detection and slashing

Safety is cheap if the only penalty is a log line. Equivocation — signing two conflicting votes or two conflicting blocks — must be cryptographically provable and economically costly. The slashing condition must cover:

• Double signing within the same round.
• Signing a block that conflicts with a previously committed ancestor.
• Amnesia attacks where a validator pretends to have forgotten a lock.

If the slashing bond is smaller than the profit from a double-spend, the mechanism is decorative.

4. Network partition tolerance

A consensus protocol that finalizes blocks under a minority partition will fork when the partition heals. Test this explicitly: split the network 30/70 for exactly the duration of the finality latency, then heal. If the minority side has produced and finalized any block, the protocol is unsafe. Safety requires either:

• A synchronous assumption short enough that the minority stalls, or
• A fork-choice rule that abandons the minority fork and loses liveness briefly.

Neither is free.

5. Block validity is not enough

A block can be valid — well-formed, correct signatures, valid state transition — and still be unsafe. Safety is a property of the ordering relation, not the block. Two valid blocks at the same height with different contents are the threat. Always ask: what is the canonical tie-breaker, and who controls it?

Closing note

Consensus audits should be boring. If the review feels exciting, it means the assumptions are being discovered rather than verified. The checklist above is how we keep them boring.