Smart contracts get the headlines. Consensus bugs get the existential incidents.
A faulty vault can drain a pool. A faulty fork-choice rule, networking stack, or validator client bug can split a network, censor finality, or strand bridges that assumed "the chain" was one thing. Most protocol security budgets still overweight application Solidity and underweight the software that decides which blocks are canonical.
This note is for L1 / L2 teams, restaking and validator operators, and anyone scoping a "protocol audit" that somehow never opens the consensus clients.
What consensus review is not
It is not a second pass over the same token contract with a different logo on the report cover.
Consensus review asks:
- Who can propose and attest?
- What economic and cryptographic assumptions keep that set honest?
- How do nodes learn about blocks and votes over the network?
- What happens under partition, delay, and equivocation?
- How do upgrades and emergency controls change those answers in production?
If the engagement never touches client code, P2P behavior, or validator economics, call it what it is: an application audit.
Where we look
### 1. Validator set economics and slashing
Stake distribution, correlation of operators, slashing conditions, and inactivity leaks decide whether "decentralized" is a property or a press line. We care about:
- Thresholds for finality and for governance that can change consensus parameters
- Whether slashing is enforceable in practice or depends on offchain social consensus
- Restaking and shared security: whose stake is securing whom, and what cascades on a slash
A mathematically elegant fork-choice rule still fails if three cloud regions and one liquid staking token dominate the active set.
### 2. P2P networking and eclipse surfaces
Consensus assumes a view of the peer set. Attackers assume they can shape that view.
Review boundaries:
- Peer discovery and scoring
- Eclipse and sybil resistance
- Block and attestation propagation under load
- RPC and sentry topologies that operators actually run (not the textbook diagram)
Many "consensus" incidents start as networking and operational topology problems that starve honest validators of data.
### 3. Timing, latency, and ordering assumptions
Block times, attestation deadlines, and proposer boosts interact with real latency. MEV-adjacent behavior and timing games sit on that seam. Assumptions that hold on a research network fail when:
- A subset of validators is systematically delayed
- Proposer building is outsourced to a small builder set
- "Honest majority" is redefined by who can land blobs or execution payloads first
Write the timing assumptions down. Then try to break them with delay, not only with crypto bugs.
### 4. Client diversity and implementation risk
One dominant client is a systemic bug waiting for a bad release. Diversity without testing for divergence is also a risk: consensus splits when implementations disagree on edge cases.
Scope should include:
- Spec vs implementation gaps
- Differential testing across clients
- Upgrade coordination and forced forks
- Resource exhaustion and DoS on validation paths
### 5. Upgrade mechanisms and emergency powers
Timelocks, security councils, and "temporary" pause switches often sit above the consensus rules everyone audited. If a small group can change parameters, client release channels, or checkpoint oracles, that group is part of consensus.
Treat upgrade authority as a consensus surface. Name who holds it and how it is monitored.
A practical review boundary
When we scope consensus work, the diagram includes:
- Spec — fork-choice, finality, validator lifecycle, reward/slash rules
- Clients — implementations in scope, known divergence history, DoS paths
- Network — discovery, eclipse resistance, operator topology assumptions
- Economics — stake concentration, restaking links, governance thresholds
- Time — latency assumptions, builder/proposer roles, censorship metrics
- Change control — who can ship a client, change params, or declare an emergency
If any row is "the foundation handles that," it still decides whether your L2 or bridge is live on Monday.
Closing note
Application audits are necessary. They are not a substitute for reviewing the machinery that defines the chain.
Teams that only read Solidity will keep being surprised by incidents that never touched a token contract. Teams that put validator logic, networking, and upgrade authority in the same threat model find existential bugs while they are still design comments.
AN3 Intel · field notes on L1 and L2 protocol risk.