A clean audit report does not mean your protocol is safe. It means a specific firm, in a specific window of time, examined a specific scope of code. The gap between "audited" and "safe" is where most exploits live.
This is the checklist we use internally when we run a Smart Contract Audit, and the one we recommend protocol teams use when evaluating any auditor's proposal, ours included.
1. Scope is written down before any code is read
The single most important sentence in any audit report is the scope statement. Read it first. It tells you which contracts, which functions, which commit hash, and which assumptions were in scope.
A scope that excludes the deployment process, the upgrade path, the initialization logic, or integration with external protocols is a scope that misses where exploits actually happen. If your auditor's scope statement is one paragraph, that's a problem.
2. Manual review is the deliverable, not the tooling
Slither, Mythril, and Foundry tests are baseline. Any auditor showing you a tool report as the deliverable is selling you a cheaper version of something you can run yourself.
The work you are paying for is senior auditors reading every line of in-scope code, with the protocol's economic logic in mind, hunting for the patterns that pattern-matching tools cannot find: oracle assumptions, reentrancy across function boundaries, broken access control, upgrade-path risks.
3. Threat modeling happens before line-by-line review
A serious audit starts with one or two days of not reading code. The auditors model:
- What does the protocol do, in plain language?
- Who would attack it, and what would they target first?
- What are the highest-value invariants that, if broken, drain the protocol?
- What dependencies (oracles, bridges, other protocols) does it inherit risk from?
That model then directs the line-by-line review. Without it, the review becomes generic and misses the protocol-specific risks.
4. Invariant tests are written, not just run
Foundry invariants and Echidna properties are how you prove the contract behaves as designed under conditions humans cannot enumerate. The auditor should be writing new properties, not just running yours.
Specifically, ask: what invariants did you write that we didn't have? That answer separates a real audit from a checkbox audit.
5. Flash loan conditions are tested explicitly
Almost every major DeFi exploit since 2020 used flash loans to amplify a smaller vulnerability. The audit should explicitly test:
- Can a single-block sequence drain any function?
- Does any pricing logic depend on spot prices that flash loans can move?
- Is the TWAP window long enough that a single block cannot manipulate it?
- Are state changes from the same address within a block bounded?
If the auditor cannot tell you they specifically tested under flash-loan conditions, the audit is incomplete.
6. The upgrade path is in scope
Most audited contracts are upgradeable. Most upgrade paths have their own privileged contracts (proxies, timelocks, governance). A bug in the upgrade path bypasses the audit of the implementation contract.
Verify: who can upgrade, on what timelock, with what protections, and is the multisig that controls upgrades reviewed as part of the audit?
7. Privileged roles are enumerated and held by the right addresses
For every privileged function, the report should answer: which address can call this, and what kind of address is that? An EOA holding onlyOwner on a treasury contract is a finding. A 2-of-3 multisig with all signers on the same hardware vendor is a finding. A timelock with a 30-second delay is a finding.
We cover this in depth on the Wallet Setup engagement, which often runs in parallel with the contract audit.
8. Re-audit after fixes is in the contract
The audit you ship is the post-fix audit, not the initial-finding audit. Make sure the engagement includes a re-audit of the changed code, not just an issue-by-issue patch review. Patches frequently introduce new bugs.
9. Public summary is owned by you
Your community will ask to see the report. Negotiate up front who publishes, in what format, and on what timeline. A good auditor does not block publication after fixes are applied.
10. The audit is not the end
Once mainnet is live, the relevant disciplines are Wallet Surveillance on treasury and admin keys, an Incident Response retainer for the moments where the first hour matters, and a bug bounty program with payouts proportional to the value at stake.
If you are launching a DeFi protocol, all four, audit, surveillance, response, bounty, are baseline. Anything less is hope, not security.
What to ask before you sign
Three questions to put to any auditing firm before signing:
- Show me a recent report you wrote. Read the writing quality, the depth of finding descriptions, the post-fix re-audit. The report is the deliverable.
- Who specifically will work on this engagement? Senior auditors are the value. Junior staff plus tooling is not what you are paying for.
- What are three vulnerabilities you've found in protocols similar to ours? If they cannot answer with specifics, they have not done this work before.
The protocols that survive their first year are the ones that treated the audit as the start of a security function, not the end of a checklist.