2026-10-10

Audit Deliverables That Prove Depth: What to Require in Your Contract

Which audit deliverables show real depth: scope by commit, system model, invariants, reasoned severity, proofs of concept, fix verification and a coverage statement.

Audit Deliverables That Prove Depth: What to Require in Your Contract

The audit report is the only part of an audit most people ever see, so it ends up standing in for all the work. Depth doesn't show up in the page count. It shows up in specific artifacts that are hard to produce without actually understanding your system. If you write those artifacts into the statement of work, you can tell a deep review from a thin one before you pay the final invoice.

Here is a deliverables list a skeptical CTO can put into the contract.

1. Scope pinned to a commit and a file list

Require: the repository, the exact commit hash reviewed, the list of files and contracts in scope, what was explicitly out of scope, and the compiler and dependency versions assumed.

Why it proves depth: without it, nobody can say what the audit covers. Nomad's 2022 loss came from a later upgrade. Curve's 2023 losses came from a compiler bug in specific Vyper versions. A scope section that names commits and toolchain versions is what lets you notice when you have drifted outside what was reviewed.

2. A system model written by the reviewers

Require: a section in the reviewers' own words that describes actors and privileges, trust assumptions, asset flows, external dependencies (oracles, bridges, keepers) and upgrade paths.

Why it proves depth: you can't write this without understanding the system. It also gives you a free check: if their model is wrong, their findings are suspect. It matches the first Rekt Test questions: "Do you have all actors, roles, and privileges documented?" and "Do you keep documentation of all the external services, contracts, and oracles you rely on?"

3. Invariants, ideally as runnable tests

Require: a list of the properties the reviewers believe must always hold (solvency, conservation of balances, access-control boundaries, liquidation correctness), with notes on which ones were tested and how. Ideally, deliver them as Foundry or Echidna invariant tests you can keep running.

Why it proves depth: Trail of Bits' study of its own findings rated dynamic analysis as the most promising automated method for severe bugs, but "usually only with the addition of a custom property to check." Writing those properties is expert work, and it pays off long after the engagement ends. Ask for it as a deliverable. The Rekt Test also asks whether you "define key invariants for your system and test them on every commit."

4. Findings with reasoned severity and an exploit path

Require: for every finding, the affected code, impact, likelihood and preconditions, a severity tied to a published rubric, and a recommended fix. For High and Critical findings, require a proof of concept: a failing test, a forked-mainnet transaction sequence, or at least a step-by-step exploit path.

Why it proves depth: public rubrics from Code4rena, Sherlock and Immunefi all treat severity as a function of impact and likelihood in context. A reviewer who can't argue severity or show the exploit hasn't finished the analysis. A proof of concept also becomes your regression test.

5. A coverage statement, including what they didn't do

Require: reviewer names and reviewer-days, which components got the most attention, which techniques were used (manual review, static analysis, fuzzing, formal methods), and an explicit list of areas reviewed lightly or not at all.

Why it proves depth: an honest "we did not review the keeper bot or the deployment scripts" is worth more than an implied claim to cover everything. It tells you where to spend next: a second firm, a contest, or a bounty.

6. Fix verification, by commit

Require: a fix-review phase where reviewers check each remediation at a named commit and record a status per finding (fixed, partially fixed, acknowledged, disputed), plus a note on any new code the fixes introduced.

Why it proves depth: the code you deploy is the fixed code, not the code that was audited. Without fix verification, the version users rely on was never reviewed. If the fix review finds that fixes introduced new behavior, that's a good sign the reviewers are still paying attention.

7. Operational and deployment notes

Require: observations on admin key setup, upgrade authority, initialization parameters, pause mechanisms and monitoring hooks, even when operations are formally out of scope.

Why it proves depth: Chainalysis attributes 43.8% of value stolen in 2024 to private key compromises (2024 data), and its 2025 report puts the year at over $3.4 billion stolen, with the Bybit compromise alone at $1.5 billion through key infrastructure, not contract code. Reviewers who understood your system will have opinions about how it is run. Ask for them in writing.

Contract language you can reuse

The final report shall include: (a) scope by repository, commit hash, file list and toolchain versions; (b) a system model authored by the reviewers; (c) a list of system invariants with test status, delivered as runnable tests where practical; (d) for each finding, impact, likelihood, preconditions and severity reasoning against a named public rubric, with a proof of concept for High and Critical findings; (e) a coverage statement including reviewer-days and areas not reviewed; (f) per-finding fix verification at a named commit; (g) operational and deployment observations.

Using the deliverables

Read the system model first and correct it if it's wrong. Run the invariants in CI. Use the coverage statement to plan the next layer of review. Publish the report with its scope, commit and date so users can check what was reviewed. Don't publish it as a badge. Our article on what leadership can truthfully say after an audit (coming later in this series) builds on these deliverables.

Sources

Sponsored