A smart contract audit is a fixed amount of expert attention. Every hour an auditor spends working out what the code is meant to do, or finding issues a test suite should have caught, is an hour not spent on the subtle problems that cause real losses. Good preparation is the cheapest way to get more out of an audit.

Freeze the code

Pick a commit and stop changing it. Auditing a moving target produces findings against code that no longer exists and misses issues in code that arrived later. If changes are unavoidable, agree with the auditor how they will be reviewed.

Write down what the code must do

Auditors check code against intent. Give them the intent in writing:

  • A short specification of each contract: its purpose, its state and who can call what.
  • The invariants — statements that must always be true, such as "total supply equals the sum of balances" or "only the treasury role can withdraw".
  • The roles and their powers, including every admin function and upgrade path.
  • Known risks and design decisions you are unsure about. Auditors would rather hear your concerns than discover them.

Arrive with tests

A readable test suite with good coverage shows the auditor how the code is meant to behave and removes a class of obvious bugs before the audit starts. Invariant or fuzz tests that attack the rules you wrote down are particularly valuable, because they explore inputs no one thought to write by hand. Report coverage honestly, including what is not covered.

Run the tools yourself first

Static analysis and fuzzing tools are cheap to run and catch common issues. Run them, fix what they find, and document anything you decided to leave with the reason. Paying an auditor to report what a free tool would have found is a poor use of the budget.

Make the scope explicit

List exactly which files and contracts are in scope, which are out, and which external contracts and tokens the system interacts with. Assumptions about external dependencies — how an oracle behaves, whether a token charges fees on transfer — are a common source of losses, and they are only reviewed if someone says they matter.

Plan for the fixes

Every audit produces findings. Reserve time after the audit to fix them, and agree in advance that the auditor will review the fixes. A fix that introduces a new issue is not unusual, and it is much cheaper to catch before deployment.

An audit is not a guarantee

An audit reduces risk; it cannot prove the absence of bugs. For contracts that will hold significant value, a second independent review, a bug bounty after launch and a staged rollout with limits on how much the contract can hold at first are all worth considering. Each one catches different things.

← All insights