The Pre-Audit Readiness Checklist

Most of the money teams waste on audits is spent before the audit starts.

We read every line of the code we are given. So when a codebase arrives with a moving scope, no tests, and no written assumptions, a meaningful part of the engagement goes into reconstructing what the system is supposed to do — work you are paying senior auditors to do, and work you could have done yourself for free.

This is the list we walk through before quoting. Teams that clear it get tighter quotes, shorter engagements, and a report where the findings are about their protocol instead of their process.

What this covers

24 checks across 6 areas — scope, build, tests, docs, deployment, and the operational assumptions auditors cannot infer from code
The freeze rule and why a scope that moves mid-audit costs more than it looks
What to write down before day one — the short document that removes the most expensive category of back-and-forth
The three findings we report on almost every unprepared codebase

How to use this

Work top to bottom. Anything you cannot tick is either something to fix before the audit, or something to tell your auditors explicitly. Both outcomes are fine. Silence is the expensive one.

1. Scope

The exact commit hash to be audited is decided and written down.
The file list is explicit — in scope and out of scope, by path.
Code is frozen at that commit for the duration, with fixes on a branch.
Third-party dependencies are pinned to versions, not ranges or main.
Anything already known to be broken is disclosed up front.

The freeze rule. Every commit that lands mid-audit invalidates review already done. Auditors either re-read the changed paths or note that their review no longer covers them — the first costs you days, the second costs you coverage. Branch your fixes and merge after the report.

2. Build and reproducibility

A clean clone builds with documented commands and no undocumented steps.
The toolchain version is pinned and stated.
The build succeeds on a machine that is not a developer’s laptop.
Any required environment variables or keys are documented, with safe dummy values for local runs.

If your auditors cannot build it on day one, you have paid for a day.

3. Tests

The test suite runs green on the frozen commit.
Coverage is measured and the number is known, even if it is low.
Critical paths — value transfer, access control, upgrades — have tests.
Failing or skipped tests are either removed or explained.

Coverage is not a security metric. It is a comprehension metric: it tells your auditors which paths you have reasoned about, and where to look harder.

4. Documentation

You do not need polished docs. You need the things that are not in the code:

What the system is for, in one paragraph.
The roles and who holds them — admin, pauser, upgrader, operator.
What each privileged role can do, stated as capability, not intent.
The invariants that must never break, written as sentences.
Known trade-offs and accepted risks.
Any external protocol you integrate with, and what you assume about it.

Invariants are the highest-leverage thing on this list. “Total shares never exceed total deposits” is checkable. “The vault is safe” is not. Write five invariants and you have given your auditors the shape of every bug that matters.

5. Deployment and operations

The deployment sequence is written down, including initialization.
Upgrade mechanism and its access control are documented.
Key custody is stated — who holds what, on what hardware, with what threshold.
There is a written answer to “what do we do in the first hour of an incident?”
Monitoring and alerting exist, or their absence is a known accepted risk.

Auditors read code, but the majority of real losses involve keys, upgrades, and operations. If the only place your deployment process exists is one engineer’s memory, that is a finding.

6. Assumptions auditors cannot infer

Which actors are trusted, and how far.
Expected ranges for values that could be adversarial — prices, decimals, supply, gas.
Which chains and which forks you target.
Behavior you consider acceptable under extreme conditions.

The three findings we report on almost every unprepared codebase

Undocumented privileged capability. A role can do something the team did not realize it could — usually via an upgrade path or an unbounded setter.
Unstated integration assumption. The code assumes an external contract behaves a certain way, and nothing enforces or checks it.
Initialization gap. The deployed state depends on a sequence that is not enforced on-chain and not written down.

All three are cheap to find and cheap to fix — before an audit. During one, they consume review time that could have gone to your actual protocol logic.

Before you send the repo

A short readiness note beats a polished wiki. Send your auditors:

the commit hash and file scope
build and test commands
five invariants
the roles table
your known-issues list

That is usually one page. It is the highest-return page you will write all quarter.