Blockchain Security Audit Checklist for Engineering Leaders

A field-tested, practical audit checklist for decision-makers shipping onchain systems in 2025—covering pre-audit scoping, L2/bridge assumptions, contract pitfalls, test/formal methods, operational controls, runtime monitoring, and incident response, with examples and the latest standards.

Engineering leaders at startups and enterprises can use this to go from “we think it’s secure” to “we can prove it, measure it, and react in minutes.”

Why this checklist now

2024–2025 shifted risk patterns: more incidents but lower median loss vs. 2021–2022. Still, multiple single points of failure—admin keys, upgradeable proxies, oracle design, and cross-chain bridges—keep producing outsized tail risk. (halborn.com)
Concrete examples worth baking into your playbooks:
- Munchables (Blast, Mar 26, 2024): a rogue developer leveraged an upgradeable proxy to self-assign a 1M balance and drain 17,411 ETH ($62.5M); funds were later returned. Root causes: insider risk, permissive upgradeability, missing invariant tests. (theblock.co)
- Gala Games (May 20, 2024): 5B GALA minted via a compromised minter role; team contained within ~45 minutes—an access control lapse, not a contract logic flaw. (news.gala.com)

7Block Labs uses the following checklist as our default spine for audits, threat modeling, and incident exercises.

0) Pre‑audit prep (what leaders must freeze, list, and decide)

Before anyone reads code:

Freeze the commit and dependencies
- Tag and hash the exact commit(s) for review.
- Produce a deterministic build (e.g., pinned solc via Foundry/Hardhat; lockfiles for JS tooling).
- Inventory all third‑party code (libraries, wallets/connectors, SDKs) with versions and addresses. Ledger’s Connect Kit incident was a supply‑chain package compromise—most affected teams were not vulnerable at the contract layer but via a poisoned NPM package. Treat frontend/connectors as part of the trust boundary. (ledger.com)
Scope and threat model
- Write down your trust/minimized-trust claims (e.g., “permissionless withdrawals on L2,” “no single signer can move treasury,” “oracle is flash-loan resistant beyond X% in Y blocks”). These become properties and invariants to verify later.
Artifact checklist you hand to auditors
- System diagram (roles, admin paths, emergency flows).
- Deployment plan (proxy pattern, timelock, multisig params).
- Param sheet (caps, fees, pauser behaviors).
- L2/bridge assumptions (see Section 1).
- Monitoring/alerting runbook (see Section 4).

1) Architecture & chain assumptions (L1, L2, and cross‑chain)

Rollup security posture
- Optimism/OP Stack shipped governance‑approved, permissionless fault proofs on OP Mainnet on June 10, 2024 (Stage 1 in L2BEAT terms). This removes reliance on trusted third parties for withdrawals, though a Security Council can intervene on failure. Plan sign‑off around this trust model if you build on OP chains (OP Mainnet, Base, etc.). (docs.optimism.io)
- Arbitrum BoLD (permissionless validation) was activated on Arbitrum One/Nova in Feb 2025, bounding dispute time and making delay‑attacks economically bounded—material for withdrawal and governance playbooks. (theblock.co)
- Use the L2BEAT Stages framework to explicitly document whether your chosen L2 is Stage 0/1/2 and what “training wheels” remain (challenge periods, councils, escape hatches). Your audit report should quote this. (medium.com)
Bridge design and limits
- If you use Chainlink CCIP, configure token‑bucket rate limiters on both token pools and aggregate lanes; set inbound limits 5–10% higher than outbound to handle batching/finality effects; delegate rate‑limit admin to a separate role. Bake these into your incident levers. (docs.chain.link)
Oracle assumptions
- If you consume Uniswap v3 TWAPs, document window length, manipulation cost model, and mitigations (e.g., wide‑range liquidity, median/winsorized approaches) in PoS land—two‑block attacks remain expensive on top pairs, but multi‑block attacks can be feasible for large validators. (blog.uniswap.org)

2) Contract checklist (what to prove in code)

Upgradability (UUPS/Transparent)
- Replace constructors with initialize(); lock implementation with
```
_disableInitializers()
```
  ; maintain storage gaps; consider ERC‑7201 namespaced storage; and run storage layout diffs on every upgrade. Many critical incidents stem from proxy misuse or storage collisions. (docs.openzeppelin.com)
Access control
- Prefer role‑based AccessControl with explicit, least‑privileged roles: UPGRADER, PAUSER, RATE_LIMIT_ADMIN, GUARDIAN.
- Two‑step ownership transfer (pending/accept) for EOAs; timelock for admin actions in production governance paths (see Governance below). (docs.openzeppelin.com)
Allowances and token transfers
- Reduce attack surface by integrating Permit2 for time‑bounded approvals and signature‑based transfers—this avoids “infinite approve” foot‑guns and simplifies revocations. Educate your frontend on batch revocation and expiries. (docs.uniswap.org)
Reentrancy and settlement
- Checks‑effects‑interactions,
```
ReentrancyGuard
```
  , pull payments, and full‑coverage tests on external callbacks.
Economic safety rails
- Add TVL‑aware caps, per‑block/epoch outflow throttles, and rate‑limiters around mint/burn/withdrawal paths. If you adopt the proposed ERC‑7265 circuit breaker pattern, specify per‑asset thresholds and cooldown behaviors (delay vs revert), and who can arm/disarm. Treat it as an additional safety net, not a primary control; it’s still a proposed standard. (ethereum-magicians.org)
Oracle integration
- Combine TWAP with secondary checks (median/percent‑band, “no more than X% delta per N blocks”), and rehearse edge cases (halted pools, liquidity cliffs).

3) Verification stack (tests, fuzz, invariants, proofs)

Unit + integration
- Foundry or Hardhat with high branch/statement coverage for critical modules, plus differential tests against reference models or prior versions.
Fuzz and invariants
- Foundry invariants for “supply conservation,” “no loss from honest actions,” “can’t drain without decreasing your balance first,” etc.
- Echidna for property‑based fuzzing keyed to your invariants. (github.com)
- Scribble to instrument specs as runtime checks in fuzz/simulation. (docs.scribble.codes)
- Halmos for symbolic testing leveraging your existing Foundry tests—useful for stateful invariants on complex protocols. (github.com)
Static analysis
- Slither baselines in CI (ERC compliance checks, upgradeability checks, reentrancy, uninitialized storage). (github.com)

Deliverables you should expect from your security partner: explicit property list, failing counter‑examples (if any), and proof artifacts or test seeds for reproduction.

4) Operational security (keys, governance, CI/CD)

Keys and multisigs
- Use Safe multisig for all privileged roles with threshold ≥ 2-of-3 (small teams) or ≥ 3-of-5/4-of-7 (larger orgs) and separated custody (no two keys with the same custodian). Modules and Guards are powerful—treat them like code with full audits, because Guards can brick a Safe if misconfigured. (help.safe.global)
- Consider adding a Delay module for spending rules (e.g., 3‑minute delay creates a cancel window for suspicious outflows). Use purpose‑specific Safes (treasury vs ops) to reduce blast radius. (help.gnosispay.com)
Governance and timelocks
- If you use OpenZeppelin Governor, set explicit voting delay/period/quorum, and route execution through a TimelockController (e.g., 48–168 hours). Keep emergency guardians on a separate, transparent path with documented scope. (docs.openzeppelin.com)
CI/CD and supply chain
- Pin dependencies; require CODEOWNERS + protected branches for contract folders; verify NPM packages and use integrity checks. The 2023 Ledger Connect Kit event was a supply‑chain compromise; don’t assume hardware wallet vendors imply safe frontend packages. Run dependency review and SLSA‑style provenance for critical JS. (ledger.com)

5) Runtime monitoring, MEV‑safe ops, and incident response

Monitoring and anomaly detection
- Subscribe to Forta’s Threat Detection Kits (DeFi, bridges, governance, stablecoins). Create playbooks that map alert types to immediate actions (e.g., pause module, rate‑limit tightening, sequencer contact, front‑end kill‑switch). (docs.forta.network)
- If you need enterprise‑grade continuous monitoring, evaluate Hexagate (acquired by Chainalysis in Dec 2024) and similar services; note claims of real‑time threat detection used by major protocols and exchanges. (cryptonews.com)
Emergency coordination and bounties
- Keep SEAL 911 in your runbook; it’s a vetted, volunteer hotline that can triage on‑chain incidents fast and route to responders. (docs.uniswap.org)
- Fund a standing bug bounty: Immunefi alone has facilitated over $100M in ethical hacker payouts; large programs like Uniswap v4 posted a $15.5M bounty. Bounties don’t replace audits—they reduce residual risk between releases. (theblock.co)
MEV and admin operations
- For sensitive admin transactions (setting caps, changing oracles, enabling assets), consider private orderflow via Flashbots Protect RPC with “max privacy” or tuned hints to avoid frontrun griefing and to gain MEV refunds. Document default privacy settings in runbooks. (docs.flashbots.net)

6) Two practical examples you can lift today

Circuit breaker thresholds (ERC‑7265 style)
- Stablecoin pool outflows: trigger at 0.75% of TVL over 5 minutes; cooldown 30 minutes; “delay settlement” mode so outflows queue and can be reviewed/unwound.
- Volatile asset pool: trigger at 1.5% of TVL over 10 minutes; cooldown 10 minutes; “revert on outflow” mode to prevent state drift during investigations.
- Governance: Pauser role can only unpause after 2-of-3 multisig and a post‑mortem link in proposal metadata. This provides reversible brakes without giving admins unilateral confiscation powers. (ethereum-magicians.org)
CCIP rate‑limit configuration
- TokenPool outbound = $2M/hr (refill 555.55…/s), inbound = $2.1M/hr; lane aggregate = $5M/hr USD‑denominated cap. The inbound > outbound buffer accommodates batching/finality, per docs; delegate RATE_LIMIT_ADMIN to a distinct multisig. Put “tighten to 20% of normal” as an immediate incident step. (docs.chain.link)

7) Example 14‑day audit & hardening sprint (what to expect)

Days 1–2: Scope freeze, threat model workshop, property list sign‑off.
Days 3–5: Static analysis baseline (Slither), unit/fuzz test harness augmentation; initial findings. (github.com)
Days 6–8: Invariant design + Scribble instrumentation + Halmos symbolic runs on critical modules. (docs.scribble.codes)
Days 9–10: L2/bridge assumption validation, oracle manipulation cost modeling, MEV‑safe ops drill. (docs.optimism.io)
Days 11–12: Governance/timelock wiring test on a fork; Safe roles/threshold rehearsal; Delay/Guard review. (docs.openzeppelin.com)
Days 13–14: Report, fix‑verification, and incident tabletop (simulate GALA/Munchables‑style scenarios with your exact controls). (cryptoslate.com)

8) Emerging practices to adopt in 2025

L2 fault‑proof maturity
- If you run on OP Stack or Arbitrum, update your “trust/minimized‑trust” claims and bridge UX copy to reflect permissionless fault proofs and BoLD activation—users care about exit trust. (optimism.io)
Permit2 by default for allowances
- Make expiring approvals and signature‑based transfers your baseline UX to eliminate infinite allowance debt. Train support to help users batch‑revoke during incidents. (docs.uniswap.org)
Uniswap v4 hooks threat modeling
- If you integrate or write hooks, follow v4 security guidance and test “flash accounting” settlements thoroughly; budget for the bounty surface if you operate hooks handling pooled value. (docs.uniswap.org)
Proactive supply‑chain hygiene
- Lock and verify frontend packages; add provenance and signed releases. Ledger’s 2023 Connect Kit compromise was a two‑hour window—enough to drain users at scale. Treat UI code channels as critical. (ledger.com)

Final cut‑down checklist (print this)

Architecture
- L2 stage and exit trust documented; bridge limits and runbooks set. (medium.com)
- Oracle windows, bounds, and fallbacks specified; manipulation cost modeled. (blog.uniswap.org)
Contracts
- Proxies: initializers locked, storage gaps verified, upgrade auth gated. (docs.openzeppelin.com)
- Roles: least privilege; two‑step ownership; timelock on prod paths. (docs.openzeppelin.com)
- Allowances: Permit2 integrated; batch revoke UX shipped. (docs.uniswap.org)
- Circuit breaker/outflow caps configured and rehearsed. (ethereum-magicians.org)
Verification
- Unit + invariant tests; Echidna fuzz; Halmos symbolic tests; Slither CI. (github.com)
Ops & governance
- Safe thresholds set; modules/guards audited; delay on large outflows. (help.safe.global)
- Governor params (delay/period/quorum) and Timelock wired and tested. (docs.openzeppelin.com)
- Dependency pinning and provenance; supply‑chain review for wallets/connectors. (ledger.com)
Monitoring & IR
- Forta subscriptions live; Hexagate/enterprise monitoring as needed. (docs.forta.network)
- SEAL 911 in runbook; bug bounty funded (Immunefi/Cantina). (docs.uniswap.org)
- Flashbots Protect RPC for admin ops; privacy hints documented. (docs.flashbots.net)

Closing

Security is not a one‑off audit; it’s an evidence‑driven practice you can schedule, measure, and improve. Use this checklist to structure your next release, attach proof (tests, invariants, limits), and harden your incident muscle memory.

If you want a partner who ships code and evidence, 7Block Labs can run the full sprint—threat modeling, verification harnesses, governance wiring, monitoring, and an incident tabletop—tailored to your stack and timeline.