Blockchain Protocol Security Audit: What’s in Scope and What Isn’t

Decision-makers guide to drawing the line (precisely) so your audit finds real risk, not noise.

Summary: A protocol audit should cover chain-specific consensus and data availability assumptions, rollup proof systems and bridges, onchain code and admin controls, external oracles and offchain services, and incident response readiness—while explicitly excluding areas like token price risk or unrelated frontends. This post lays out concrete, current (2024–2025) scoping checklists, examples, and emerging best practices that reduce residual risk without bloating timelines.

---

Why scoping matters now

Since Ethereum’s Dencun upgrade went live on March 13, 2024, rollups post data as “blobs” (EIP‑4844), cutting L2 data costs while shifting new risks to blob gas markets, DA, and proof systems. Your audit scope must reflect those realities—not 2021-era assumptions. (blog.ethereum.org)

In 2024–2025, major L2s shipped or upgraded fault/fraud proofs (e.g., OP Mainnet went to permissionless fault proofs in June 2024; Arbitrum’s BoLD dispute protocol launched on One and Nova on Feb 12, 2025). If you’re building on an L2 stack, your audit must test the exact proof/withdrawal path your users depend on—no hand-waving. (blog.oplabs.co)

Real-world incidents keep reminding us that most losses aren’t “math bugs”—they’re access control and cross‑system issues. In May 2024, a compromised minter role minted 5B GALA; the contract wasn’t “hacked,” the admin process was. Your scope has to pin down admin key risk and operational controls, not just code quality. (news.gala.com)

---

Scope, by layer (and what to exclude)

Think in layers. Security breaks where assumptions cross boundaries.

1) Base protocol and network assumptions

Include (if you run your own L1/L2 or modify core components):

• Consensus and networking surfaces: peer selection, gossip validation, fork‑choice, and DoS tolerance (e.g., post‑EIP‑4844 block/attestation timing; fork rate impacts). (emergentmind.com)
• Execution-layer EIP changes that affect semantics:
  • EIP‑1153 (transient storage)—new state lifecycles; audit for “wipe-after-use” and reentrancy side‑effects.
  • EIP‑5656 (MCOPY)—bounds/copy logic and memory aliasing.
  • EIP‑6780 (SELFDESTRUCT constrained)—upgrade/proxy assumptions relying on selfdestruct are now brittle.
  • EIP‑4788 (beacon root in the EVM)—verify usage and replay/consistency checks. (blog.ethereum.org)
• Data availability: if you rely on alt‑DA (Celestia, EigenDA, etc.), audit the DA guarantees you actually inherit (sampling, proof-of-custody, rate limits/tiers), and your L1 verification path. (docs.celestia.org)

Exclude:

• General network performance or fee forecasts.
• Broader “ecosystem health” of public client diversity unless your product depends on a specific client fork.

Deliverables:

• Threat model with explicit safety/liveness invariants.
• Abuse simulations for blob scarcity (pricing spikes) and degraded DA connectivity.

2) Rollup/stack specifics (OP Stack, Arbitrum, ZK stacks)

Include:

• Proof system state today:
  • Optimistic: challenge game contracts, fault proof VMs, proposer/validator allowlists vs permissionless, upgrade guardians, and withdrawal flow after proofs (OP Superchain fault proofs; Arbitrum BoLD dates and parameters). (blog.oplabs.co)
  • ZK: validity proof verification contracts, circuit constraints, recursion settings, and data availability mode (rollup vs validium vs “prividium”). For ZK Stack/Validium, review L1 DA validators (

    L2DAValidator

    /

    L1DAValidator

    ) and inclusion‑proof wiring. (docs.zksync.io)
• Exit guarantees: can users exit without operator coordination? What’s the practical exit window under your governance? Map to L2BEAT “Stages” requirements you claim to meet (Stage 0/1/2). (medium.com)
• Sequencer fallback: forced inclusion/force‑exit paths, censorship resistance, and timelocks.

Exclude:

• Marketing claims about “Stage 2 soon.” Scope to what is on mainnet today.

Deliverables:

• Walkthrough of a forced exit under adversarial operators, with explicit timelines and signer sets.
• Attack trees for proof denial-of-service and griefing (e.g., interactive games repeatedly reset).

3) Bridges and cross‑chain messaging

Include:

• Bridge trust model: light client vs external relayer/oracle; validator set size and rotation; proof types; pause/upgrade powers.
• Key ceremonies and MPC/HSM arrangements for guardians/relayers.
• Replay protection, domain separation, and message ordering guarantees.

Why it matters: private‑key compromise (or concentrated signers) still dominates bridge losses. The Dec 31, 2023 Orbit Bridge exploit (~$81–82M) was attributed to compromised signers; in mid‑2024 the attacker moved ~$48M via Tornado after dormancy—a textbook case of key/ops risk, not math. Your audit must include signer processes and rotation tests. (cointelegraph.com)

If you use generalized messaging (e.g., LayerZero), include oracle/relayer configuration, nonblocking flows, and upgradability of endpoints/libraries. Explicitly test blocked message queues and replay handling. (docs.layerzero.network)

Exclude:

• “Interoperability roadmaps” to chains you don’t actually connect at launch.

Deliverables:

• Cross‑chain sequence diagram with failure modes and runbooks for signer compromise.

4) Onchain application code (Solidity/Vyper/Huff/Rust)

Include:

• Standards conformance and edge‑cases (ERC‑20/4626/721/1155; permit variants; fee rounding; token hooks; rebasing).
• Upgradeability and proxy invariants (initializers, UUPS/transparent proxy controls).
• Full static analysis and differential fuzzing against invariants (Foundry invariants, Slither detectors; property-based tests). (github.com)
• EIP‑1153 transient storage usage patterns; MCOPY bounds; SELFDESTRUCT assumptions after 6780.
• Gas‑sensitive implementations (Huff/Yul) with formalized pre/postconditions and test harness parity. (docs.huff.sh)

Tools that should be baseline in 2025:

• Slither for static checks (unprotected upgrades, ecrecover misuse, abi.encodePacked collisions, etc.). (github.com)
• Foundry fuzz + invariants; targetSelector/targetContract scoping; stateful sequences to cover reentrancy‑then‑rescue paths. (paco0x.org)

Exclude:

• Frontend websites and non‑custodial browser wallets (separate web/appsec scope).

Deliverables:

• Invariant catalog tied to your protocol math (e.g., “sum of shares equals total supply within 1 wei”).
• Reproduction harnesses for any third‑party incident class your design resembles.

5) Zero‑knowledge circuits and proof systems (if applicable)

Include:

• Under‑constrained circuit detection and determinism proofs for Circom/Halo2/Plonky2/etc. Tools like Circomspect and Picus should be part of CI and audit read‑ahead. (blog.trailofbits.com)
• Constraint counts vs expected bounds; witness sanity; hashing/field conversions; padding and domain separation; verifier parameters on L1.
• Multi‑language circuit coverage (R1CS/PLONK/ACIR) where your stack mixes languages or backends. (github.com)

Exclude:

• “Prover performance tuning” beyond security relevance (benchmarks are nice-to‑have, not security).

Deliverables:

• Proof that each public output is uniquely determined by inputs (no alternative witnesses).
• Verifier gas/limit checks and soundness assumptions documented for auditors and governance.

6) Oracles and external data

Include:

• For Chainlink Data Feeds (OCR), document feed parameters, minimum submissions, and fallback behavior; check for stale reads and aggregator versioning. (docs.chain.link)
• For Pyth’s pull‑oracle model, audit who calls “update price” and how you prevent stale prices or griefing—because consumers must push updates on demand via Wormhole-signed VAAs. Test “no‑update” scenarios. (pyth.network)
• For any cross‑chain oracle delivery, verify signature sets, replay protection, and guardian assumptions.

Exclude:

• Macro judgments on data vendor market share.

Deliverables:

• Alert thresholds and circuit breakers for stale or divergent feeds; simulation of freeze/depeg responses.

7) Admin keys, governance, and operations

Include:

• Key management: threshold (t‑of‑n) and signer diversity; hard timelocks and constrained roles; recovery/freeze procedures; consider MPC (e.g., MPC‑CMP) or HSM-backed controls with rotation SLAs. (fireblocks.com)
• Governance: upgrade delays vs user exit windows; Security Council powers relative to L2BEAT Stage criteria (e.g., Stage 1 vs Stage 2). (medium.com)
• Continuous monitoring and incident response: prebuilt monitors and runbooks (e.g., OpenZeppelin Defender 2.0 Monitor/Actions; Forta real‑time detectors). (blog.openzeppelin.com)

Case in point: Gala’s 2024 incident was pure admin/minter compromise—an audit that excludes keys and runbooks invites a repeat. (news.gala.com)

Exclude:

• HR background checks, enterprise IAM, or SOC2 scope (they’re adjacent but separate audits).

Deliverables:

• RACI for emergencies; automated pause/mitigation actions wired to monitors; signer‑loss tabletop.

8) Account abstraction (ERC‑4337, EIP‑7702) if you support smart accounts

Include:

• Paymaster griefing/DoS resistance, staking/limits, and deterministic validation under ERC‑7562 rules; bundler simulation parity. (docs.erc4337.io)
• EIP‑7702 delegation semantics if you rely on EOAs delegating to smart‑account logic; verify auth lists, clearing flows, and wallets’ signature paths. (github.com)

Exclude:

• Bundler marketplace economics.

Deliverables:

• End‑to‑end tests showing malicious paymaster attempts fail safely; replay and packing protections in any custom VerifyingPaymaster. (alchemy.com)

---

What’s explicitly out of scope (but often confused)

• Token price dynamics, emissions schedules, or “Ponzinomics.” Security can model incentives, not predict markets.
• Centralized exchange integrations, custodial flows, or third‑party KYC vendor security (separate vendor risk).
• Standalone marketing sites/landing pages (do a separate web/appsec pentest).
• End‑user devices and wallets not operated by your protocol.

If any of those directly affect funds flow (e.g., your backend signs withdrawals), pull them into scope or build contractual controls and incident runbooks around them.

---

Practical scoping checklist (start here)

Time box: 60–90 minutes with your engineering lead, PM, and ops.

1. What mainnet state are we auditing?

• Commit hash(es) and tag; compiler versions; deployment addresses; config values; feature flags.

1. If on a rollup or appchain:

• Which proof system is live today? What is the withdrawal path and time? Who can pause or upgrade which contracts? Dates and links to docs/announcements. (blog.oplabs.co)

1. Cross‑chain?

• Enumerate all message paths and signers; identify replay boundaries (chainId/domain separators).

1. Oracles?

• List feeds, update mechanics (push vs pull), heartbeat/deviation thresholds, and stale‑read handling. (docs.chain.link)

1. Admin and governance:

• Thresholds, timelocks, emergency powers; rotation cadence; MPC/HSM providers; recovery drills. (fireblocks.com)

1. Monitoring & response:

• Which monitors (Defender/Forta/custom) are live? What auto‑actions are wired (pause, rate‑limit, circuit‑breakers)? (blog.openzeppelin.com)

1. ZK circuits?

• Languages/backends; determinism proofs in CI (Circomspect/Picus); verifier parameters and gas limits. (blog.trailofbits.com)

1. Invariants (auditor‑ready):

• List 10–20 critical invariants (supply conservation, fee accounting, bounds) mapped to tests/fuzz harness.

---

Emerging best practices we recommend in 2025

• Treat DA as a first‑class risk: If you use EigenDA/Celestia, document retrieval guarantees, anti‑Sybil/anti‑DoS limits (e.g., free‑tier throttles), and onchain inclusion verification. Wire monitors for DA failures that block your L2’s safety exit. (docs.celestia.org)
• Adopt permissionless proofs as soon as feasible: If you’re on OP Stack, plan toward permissionless proofs; if on Arbitrum, ensure BoLD configuration matches your chain’s upgrade calendar and that your runbooks assume permissionless challengers. (blog.oplabs.co)
• Continuous monitoring with automated response: Set Defender Monitors for admin role changes, large mints/burns, and governance executions; wire Actions to timelocked pauses and rate‑limiters; add Forta Attack Detector or Firewall for pre‑chain risk gating where appropriate. (docs.openzeppelin.com)
• Prove ZK circuit determinism: Make under‑constraint checks a CI gate; require counterexample artifacts for any failed pass before shipping. (docs.veridise.com)
• Make admin keys boring: Favor t‑of‑n with signer diversity (jurisdiction/cloud), MPC for high‑value roles, and strict ops runbooks. Publish timelocks and exit windows aligned with L2BEAT Stages so users can evaluate risk. (fireblocks.com)

---

Example: drawing a tight scope for a Superchain DeFi protocol

Context: You deploy on OP Mainnet (fault proofs live) and plan an L3 for private order flow using a ZK Stack Validium.

In scope:

• OP Mainnet withdrawal path and new fault‑proof‑driven output oracle interactions; break‑glass/guardian powers and their timelocks. (blog.oplabs.co)
• L3 Validium DA commitments and inclusion checks on L1 using ZKsync’s

  L2DAValidator

  /

  L1DAValidator

  contracts. Stage classification for the L3 (not marketing claims). (docs.zksync.io)
• Bridge between L3↔OP Mainnet: message replay domains, sequencer downtime behavior, and operator censorship mitigations.
• Oracles: for Pyth, explicit “who updates the price” policy (bot or taker?) and protocol behavior on missed updates; add stale‑read circuit breakers. (pyth.network)
• Admin: MPC for mint/burn/upgrade; Defender monitors for role changes; runbooks for pausing only affected modules. (blog.openzeppelin.com)
• ZK circuits: under‑constraint checks and gas limits; verifier parameterization documented. (blog.trailofbits.com)

Out of scope (for this audit):

• Marketing site and analytics pipeline.
• Centralized matching engine SRE posture (to be covered by a separate appsec/infra review).
• Future migration to BoLD on an Arbitrum instance—until dates/configs are final. (docs.arbitrum.io)

---

How we run protocol‑grade audits at 7Block Labs

• Pre‑audit hardening (1–2 weeks): we give you a “red list” from static analysis (Slither), Foundry fuzz/invariants scaffolding, and CI gates for ZK determinism (if applicable). Fixes here save audit hours. (github.com)
• Scope lock (D‑7): pin commit hashes, deployment addrs, EIP assumptions, L2 proof mode, DA layer settings, and admin key topology, with a RACI for incidents.
• Audit execution (2–4 weeks): parallel tracks for onchain code, proofs/bridges/oracles, and ops/governance. We deliver PoCs and minimal patches, not just findings.
• Live readiness: wire Defender/Forta monitors + Actions; run tabletop drills for bridge/oracle/DA failure, including blob scarcity spikes. (docs.openzeppelin.com)
• Post‑audit: publish a public‑facing “assumptions and limits” note so users understand exactly what’s secure—and what depends on external trust.

---

Final word: write your scope like an adversary would

A precise scope draws bright lines around:

• The proof and DA guarantees you actually have today.
• The admin powers that can change user funds’ fate.
• The external data and cross‑chain dependencies your protocol can’t out‑smart on its own.

Do that, and your audit won’t just pass—it will stand up to the next real‑world stressor.

---

References and further reading:

• Ethereum Dencun (mainnet: Mar 13, 2024) EIPs list (1153/4788/4844/5656/6780/7044/7045/7514/7516). (blog.ethereum.org)
• Post‑4844 operational impacts and blob mechanics. (eip4844.com)
• OP Stack fault proofs (Stage 1) and withdrawal flow changes. (blog.oplabs.co)
• Arbitrum BoLD launch (Feb 12, 2025) and adoption notes. (docs.arbitrum.io)
• ZK Stack Validium DA inclusion contracts and architecture. (docs.zksync.io)
• Celestia DA sampling primer (DAS) for DA assumptions. (docs.celestia.org)
• EigenDA security model and slashing notes. (docs.eigencloud.xyz)
• Orbit Bridge exploit; bridge signer/ops risk. (cointelegraph.com)
• Pyth pull‑oracle model and cross‑chain delivery. (pyth.network)
• Chainlink Data Feeds architecture (OCR). (docs.chain.link)
• Defender 2.0 monitoring/response; Forta Attack Detector/Firewall for real‑time detection/prevention. (blog.openzeppelin.com)
• Slither and Foundry invariants as audit baselines. (github.com)
• Circomspect/Picus for under‑constraint ZK checks. (blog.trailofbits.com)
• ERC‑4337 security (paymasters, ERC‑7562), and EIP‑7702 alignment. (docs.erc4337.io)

7Block Labs can help you lock this down. If you’d like our one‑page scope template (with the invariant catalog starter), ask and we’ll share it.