Blockchain Protocol Audit

A blockchain protocol audit reviews the consensus, networking, execution, bridge, and sequencing layers of an L1 or L2 blockchain, not just the smart contracts that run on top. We have audited consensus changes for Ethereum, the Lighthouse client we maintain in production, and several Layer 2 rollups. The work involves reading protocol-layer code in Rust, Go, or C++, modelling adversarial validator and sequencer behaviour, and reasoning about the protocol under network partition, fork choice attacks, censorship, and economic incentives.

Request a scoping call

What we cover.

A blockchain protocol audit reviews the layers below the application:

  • 01

    Consensus algorithm. Safety and liveness under faulty validators, network partition, and adversarial scheduling. For Ethereum-style PoS, this includes attestation aggregation, slashing conditions, and the fork-choice rule.

  • 02

    Fork choice and finality. How the protocol selects the canonical chain, what happens under contested heads, and the worst-case behaviour during a finality stall.

  • 03

    Networking layer. Gossip, peer scoring, eclipse and DoS resistance, sync protocols.

  • 04

    State-transition function. The execution semantics — opcodes, precompiles, gas accounting, state access patterns.

  • 05

    Rollup and L2 machinery. Bridges, sequencers, force-inclusion paths, fault-proof or proof-verifier assumptions, and upgrade controls.

  • 06

    Validator incentives. Slashing, rewards, penalties, and the equilibrium behaviour of rational validators under the proposed rules.

  • 07

    Upgrade and migration paths. Hard forks, soft forks, and the procedure for transitioning live state across protocol versions.

Our approach.

Protocol audits begin with a threat-model session between our engineers and yours. The protocol is reviewed against an explicit adversary model: how many validators can be Byzantine, what network conditions are assumed, what economic resources the attacker has.

We then read the protocol implementation alongside the specification. Discrepancies between spec and implementation are findings — sometimes the spec is right and the implementation is wrong, sometimes the spec is wrong and the implementation has been patched without updating the spec.

For consensus changes, we sometimes write reference implementations against the spec and run them against your implementation. This is expensive but catches issues that pure code review will miss.

The same engineers who maintain Lighthouse run protocol audit engagements. That implementation experience is the differentiator: we have read the EIPs from the inside, implemented them, found the spec ambiguities through real implementation, and shipped through coordinated client-team upgrades.

How protocol audits differ from contract audits.

The network is part of the system

Protocol code has to behave under delay, partial failure, peer churn, adversarial scheduling, equivocation, and contested heads. A unit test that passes in a clean environment does not answer those questions. We review the implementation against the conditions a live network will create, including the cases that are rare enough to be missed in ordinary testing.

Specification drift is a security issue

Protocol teams often move fast enough that implementation, spec, tests, and operator guidance fall out of sync. That drift matters. If the client does one thing and the spec says another, downstream teams can build wrong assumptions into tooling, monitoring, or forks. We treat meaningful spec-implementation mismatch as audit surface, not documentation cleanup.

Inputs that make review sharper

  • Current specification, known deviations, and open design questions.

  • Test vectors, simulation harnesses, fork-choice cases, and adversarial network scenarios.

  • Upgrade, migration, and operator guidance for the release being reviewed.

  • Known consensus, networking, or performance concerns that should receive a second pass.

Related research and guidance.

Frequently asked questions.

  • Who actually does this work?

    The same engineers who build Lighthouse, our Rust Ethereum consensus client. We are one of a handful of teams in the world that runs production consensus client code, and the only audit firm that does. This means we audit protocol changes against real implementation experience, not theory.

  • What languages do you read at the protocol layer?

    Rust, Go, and C++ are the most common. We have audited code in all three.

  • Can you audit a fork-choice or finality change?

    Yes. Fork-choice and finality changes are among the highest-risk protocol changes — a bug here can fragment the network or stall finality. We have audited multiple Ethereum consensus-spec changes prior to mainnet.

  • Do you only audit Ethereum?

    No. We have audited Cosmos-SDK chains, Polkadot parachains, Solana programs, and several proprietary L1s. Ethereum is the most common because of where the security work is, but the methodology applies to any consensus protocol.

  • How is this different from a smart contract audit?

    A smart contract audit reviews application code that runs on a blockchain. A protocol audit reviews the blockchain itself — consensus, networking, the state-transition function, fork choice, the economic incentives that make the protocol secure. The skill set overlaps but is meaningfully different.

Other engagements you might be considering.

Scope a blockchain protocol audit.

Tell us about the protocol-layer change you need reviewed. We respond within two business days.

Request a scoping call

Services

Products

Resources

Company

Social

© Copyright 2026 by Sigma Prime. All Rights Reserved.

contact@sigmaprime.io