An audit is a snapshot. Specific contracts, at a specific commit, reviewed by specific people, under a scope that somebody wrote down.
Everything outside that scope was never looked at. That sentence explains most post-audit exploits.
Read the scope before the findings
When you receive an audit report, the section people skip is the one that matters most. It lists the files reviewed and the commit hash. Anything not in that list — your frontend, your deployment scripts, your key management, your oracle configuration, your multisig thresholds, the contract you added two weeks later — was not examined.
We’ve reviewed post-incident reports where the exploited component sat clearly outside the audit scope, and the team genuinely believed they were covered because they had a report with a firm’s logo on it. That’s not the auditor’s failure. It’s a misread of what the product is.
When to get one
When the contracts are frozen and hold value. Feature-complete, tests passing, and you’ve stopped adding things. Auditing while you’re still building is paying for a review of code that won’t exist by launch.
Before deposits, not after. Obvious, and routinely ignored. If you’ve already taken user funds, get the audit now, but understand you did it in the wrong order and price the risk accordingly.
When you’re upgrading something that already holds value. New version, same rule. An upgrade to a live contract is exactly where teams get comfortable and skip the review.
When counterparties require it. Exchanges, launchpads, institutional partners and insurers all ask. This is often the practical trigger even when the engineering case was already there.
What an audit will not do
It won’t catch every economic design flaw. Most large protocol losses in recent years were not straightforward code bugs — they were oracle manipulation, liquidity assumptions that failed under stress, or incentive designs that behaved rationally in a way nobody modelled. Auditors review code. Economic soundness is a different discipline, and if your protocol has non-trivial financial mechanics you should commission that separately.
It won’t cover your keys. A perfectly audited contract controlled by a single hot wallet on a laptop is not secure. Key management, multisig configuration and signer discipline sit outside almost every audit scope and are involved in a meaningful share of real incidents.
It won’t stay valid. The report describes one commit. The moment you deploy a change, part of it stops applying.
It won’t protect your frontend. DNS hijacks and compromised frontends have drained users from protocols whose contracts were never touched.
The controls that go around it
An audit works as one item in a stack, not on its own:
- Test coverage that means something. Not line coverage — branch and state coverage on the paths that move money.
- Invariant and fuzz testing. Property-based testing catches classes of bug that reading code does not.
- A bug bounty that pays. A live bounty with meaningful rewards buys you continuous review from people who are motivated to find things.
- Monitoring and alerting. Know within minutes when something unexpected happens on-chain, not when a user tweets about it.
- A rehearsed incident plan. Who can pause, who holds which key, who speaks publicly, and how quickly. Rehearse it. The first time you run this procedure should not be during an incident.
- A staged rollout. Deposit caps at launch, raised over time as the contracts survive real usage, cost you very little and cap the downside enormously.
Choosing a firm
Match the firm to the risk profile. Read their published reports — most reputable firms publish — and look at the depth of findings on protocols that resemble yours. A firm that has reviewed twelve lending markets will see things in your lending market that a strong generalist will miss.
Ask who specifically does the work. Firms vary in how much the named partners are actually involved. It’s a fair question and the answer tells you a lot.
Ask about the re-review. Fixing findings introduces new code. If fix verification isn’t in the engagement, you’ve got unreviewed changes in your final deployment.
What drives cost and effort
Audit pricing varies widely, and the drivers are fairly consistent:
- Lines of code in scope, and more importantly how much of it is novel versus standard OpenZeppelin patterns.
- Complexity of the financial logic. A vault with dynamic interest curves and liquidations takes far more review than a straightforward token.
- Number of external dependencies. Every oracle, bridge and integrated protocol widens the surface.
- Whether you need a re-review after fixes, which you should.
- Firm reputation and availability. The best-known firms have queues, and that queue is a real planning input.
- Documentation quality. Auditors reading a well-specified protocol spend their time on the logic. Auditors reverse-engineering intent from code spend it on comprehension.
The honest summary
Get an audit. Get it at the right point. Read the scope. Fix what it finds, including the mediums. Publish the whole report, including what you chose not to fix and why — the projects that get burned on this are the ones whose users find the unfixed findings on their own.
Then keep going, because the audit is the beginning of your security posture, not the end of it. A report is not a guarantee. Anyone who tells you otherwise is selling something.
Common questions
What does a smart contract audit actually cover?
An audit covers the specific contracts, at the specific commit hash, listed in the scope document — nothing else. It does not cover your frontend, your keys, your deployment scripts, your oracle dependencies, your multisig setup or any code you change afterwards. Most post-audit incidents happen in exactly those places. Read the scope section of any audit report before you read the findings, because the scope is what tells you what was never looked at.
When should you get an audit?
When the contracts are feature-complete and you have stopped changing them, but before anything of value is deposited. Auditing a moving codebase wastes the engagement, because every change after the review invalidates part of it. If you are still adding features, freeze first. If you have already deployed and taken deposits, audit now and accept that you are doing it in the wrong order.
Does one audit make a protocol safe?
No. An audit reduces risk, it does not eliminate it. Protocols with multiple audits from reputable firms have still been exploited, usually through economic design flaws, oracle manipulation, or a component that was out of scope. Treat an audit as one control among several — alongside test coverage, invariant testing, a bug bounty, monitoring, and a rehearsed incident response plan.
How do you choose an audit firm?
Match the firm to the risk. Read published reports from firms you are considering and look at the depth of findings on protocols similar to yours. A firm that has repeatedly reviewed lending markets will see things in your lending market that a generalist will not. Ask who specifically will do the work, because the name on the invoice is often not the name doing the review.
What should you do with the findings?
Fix them, get the fixes reviewed, and publish the report including the issues you chose not to fix and why. Publishing a clean summary while quietly accepting several medium-severity findings is a trust problem waiting to surface. Serious users read the full report, and the acknowledged-but-unfixed section is the part they read most carefully.
