How to prepare for a smart contract audit

Most of an audit quote is a function of scope: contract count, lines of code, how novel the design is, and whether tests and documentation already exist. Three of those four are fixed by the time you ask. The fourth is preparation, and it is the one under your control.

In plain terms: the same codebase, presented two different ways, produces two different quotes and two different timelines. The difference is not negotiation. It is how many hours the reviewing team spends establishing things you already know.

A typical engagement runs one to three weeks. The preparation below is what keeps it at the lower end of that range.

Name a commit and stop writing to it. Every finding in a report is anchored to a line number at a specific revision, and a branch that moves during the review produces findings against code that no longer exists by the time you read them.

This is the preparation failure with the worst economics. A review of a moving target is not a review that needs updating; it is a review that has to be done again, because coverage of a changed file is not coverage of the file that shipped.

In plain terms: you pay twice, and the second engagement is not discounted, because the work is not repeated — it is new.

Branch off if development has to continue. The audit reads the frozen branch; your team keeps working on another. Fixes land after the report, which is what the re-audit round is for.

A reviewer must be able to compile your contracts and arrive at the same bytecode you deployed. That requires a pinned compiler version, pinned dependency versions, and build settings committed rather than pinned in the repository rather than reproduced from memory.

If the build cannot be reproduced, nothing downstream of it can be verified: not the deployed bytecode, not a proof of concept, not the fix. A report on code that cannot be rebuilt describes source that may or may not correspond to what is running.

In plain terms: this is the one item on the list that stops an engagement rather than slowing it. A build nobody can reproduce is a build nobody can verify, including you, and we will say so plainly before going further.

A failing test suite forces the reviewer to establish whether the failure is a defect, an outdated test, or an environment problem. That is investigative work on a question your team can answer in minutes.

Coverage matters less than people assume, but the places coverage is absent are informative. An untested branch is where assumptions go unexamined, and reviewers read coverage reports partly as a map of where to spend attention.

In plain terms: tests and documentation make the review faster and cheaper. Their absence does not stop it. It transfers the cost of understanding your system from your team to the people you are paying by the engagement.

The documentation that helps a reviewer is narrower than most teams expect. Three things earn their place.

The invariants: what must always be true. Total supply equals the sum of balances. A user cannot withdraw more than they deposited. The pool cannot be left insolvent by any sequence of operations. These are what a reviewer tests the system against, and if you have not written them down, the review spends time inferring them from code.

The trust assumptions: who is trusted, with what, and what happens if that trust is misplaced. Which roles exist, what each can do, which external contracts you depend on and what you assume about their behaviour.

The intended flows: the normal path through a deposit, a swap, a withdrawal, a liquidation. Not prose about the vision — the sequence of calls and state changes.

What nobody reads: marketing material, pitch decks, and architecture diagrams that describe an earlier version of the system. An outdated diagram is worse than none, because the reviewer has to establish that it is outdated.

Decide which contracts are in and which are out, and be deliberate about the boundary. The parts most often excluded for cost reasons are the parts most often exploited: upgrade mechanisms, governance contracts, oracle adapters and the helper libraries everything imports.

An exclusion is not a problem by itself. An unexamined exclusion is. The out-of-scope line in a report is a statement about what nobody looked at, and it is worth choosing deliberately rather than discovering after the fact.

In plain terms: a narrower scope costs less and covers less, in exactly the proportion you would expect. The question is whether the part you cut holds value or controls something that does.

A review generates questions that only your team can answer: whether a behaviour is intentional, what an external contract is assumed to guarantee, why a parameter has the value it has. Those questions arrive throughout the engagement, and a reviewer waiting two days for an answer is a reviewer working around a gap.

One named person, reachable, who knows the system. Not a rotating queue and not a shared inbox. The named engineer is not a formality; response latency is the difference between a question answered and an assumption recorded as a finding.

Two expectations worth setting before you start, because they change how you plan the weeks around the review.

Critical findings should reach you the day they are found, not in the final report. There is no reason to hold a severe finding for a scheduled delivery, and a firm that does is prioritising its own reporting rhythm over your remediation window.

A re-audit round should be part of the engagement rather than an upsell. You fix, the reviewer verifies each fix, confirms nothing new was introduced, and updates the report. A review that ends at the first report leaves you holding fixes that nobody has checked.

Work through this before requesting a quote. Each item either lowers the price, shortens the timeline, or prevents a conversation that stops the engagement.