State transition and execution logic
Block and transaction validation, execution ordering, fee calculations, state commitment, replay behavior, precompiles, VM boundaries, and mismatches between specification and implementation.
L1, L2, client, and consensus security
Blockchain security audits for the code every validator must trust.
Adversarial review of execution clients, consensus and validator logic, state transitions, bridges, networking, serialization, runtimes, and other chain-critical components across Rust, Go, C, and C++.
- 8+ critical findings
- 40+ high / medium findings
- 57 blockchain protocols protected
- Public findings across Sherlock and HackenProof
01 / Scope
Find the disagreement that turns one valid chain into two realities.
Chain-critical vulnerabilities often live between layers: specification and implementation, validator and client, parser and state machine, bridge and finality source. The review follows those boundaries end to end.
Consensus and validator behavior
Fork choice, finality assumptions, proposer and validator rules, evidence handling, timing, reorganization safety, slashing paths, and conditions that can split honest nodes.
Networking and serialization
Peer-to-peer message handling, WebSocket and RPC surfaces, framing, parsing, canonical encoding, resource exhaustion, malformed inputs, and trust boundaries between services.
Bridge and cross-chain security
Proof verification, message lifecycle, relayer assumptions, replay protection, finality dependencies, asset accounting, administrative controls, and recovery from partial failure.
02 / Method
A review process designed to find exploitable assumptions.
The audit starts from safety and liveness invariants, then tests how malicious peers, malformed data, edge-case state, timing, reorganization, and implementation differences can violate them.
- 01
Architecture and invariant mapping
The review establishes which components can create or validate state, where implementations must agree, what roles are trusted, and which failures threaten safety, liveness, or funds.
- 02
Cross-implementation review
Specifications, clients, libraries, and boundary formats are compared to find disagreements that can produce invalid state, consensus divergence, bypassed validation, or incompatible network behavior.
- 03
Adversarial execution and validation
High-risk paths are tested with malformed, reordered, boundary, and resource-intensive inputs. Findings are validated against realistic attacker capabilities and deployment conditions.
- 04
Reporting and remediation
Each issue connects root cause to chain-level impact, identifies the affected component and triggering conditions, and is rechecked after the engineering team implements a fix.
03 / Deliverables
What your team receives
- A severity-ranked report tied to safety, liveness, and asset impact
- Reproducible triggering conditions and affected components
- Specification-versus-implementation mismatch analysis
- Attack narratives grounded in realistic node and network behavior
- Engineering-focused remediation guidance
- Fix verification against the original chain invariant
Best fit
When to book a review
- Before testnet, mainnet, or a major network upgrade
- Before onboarding a new execution or consensus client
- After changes to block validation, fees, proofs, or state transition rules
- When introducing a bridge, runtime, VM, or serialization format
- After a fork, incident, consensus divergence, or liveness failure
- When an application audit does not cover the underlying chain assumptions
04 / Questions
Audit questions protocol teams ask
What blockchain components can be included in an audit?
A review can include execution or consensus clients, validator software, runtimes, virtual machines, state transition functions, RPC and peer-to-peer networking, bridges, proof verification, serialization libraries, relayers, and chain-specific system contracts. Scope is tailored to the system's security boundaries.
Which implementation languages are supported?
Public research includes C++, Rust, Go, Solidity, and Move, with additional work across mixed-language blockchain stacks. The key requirement is a clearly defined repository, specification, and deployment context for the components under review.
Can a pre-mainnet blockchain or client be reviewed?
Yes. Pre-mainnet review is often the best time to test consensus assumptions, unsafe defaults, network boundaries, state migration, and recovery behavior before operational constraints make architectural fixes expensive.
How is a blockchain audit different from a smart contract audit?
Smart contract audits focus mainly on application-layer state and value flows. Blockchain security audits extend into consensus, execution, validator behavior, networking, serialization, storage, and cross-client agreement. Systems spanning both layers can be scoped as one coordinated review.
Does the review include denial-of-service and liveness risk?
Yes when those surfaces are in scope. Resource exhaustion, malformed network inputs, unbounded processing, stuck state, recovery failures, peer behavior, and conditions that prevent progress can be as critical to a chain as direct asset theft.
Need an independent security review?
Put the protocol in front of an attacker before launch.
Share the repository, scope, deployment target, and timeline for a direct audit conversation.