A smart contract audit is a time-boxed security review of a specific version of your code by independent specialists, ending in a report of vulnerabilities ranked by severity. It lowers risk; it does not certify that code is safe. Teams that get the most from audits arrive with a frozen commit, a written specification and a test suite that already catches the easy bugs.
What auditors actually do
Most of the value comes from experienced people reading code against a mental model of how it should behave. Tools support that work:
- Manual review: line-by-line reading, threat modeling each actor (users, admins, other contracts, MEV searchers), and checking every external call and assumption.
- Static analysis: Slither, Aderyn and similar tools flag known patterns such as reentrancy, shadowed variables or unchecked return values. Output is noisy and needs triage.
- Fuzzing and invariant testing: Foundry invariant tests, Echidna and Medusa throw random sequences of calls at the system and check that properties such as "a user can always withdraw their deposit" never break.
- Formal verification: tools like the Certora Prover, Halmos (symbolic execution of Foundry tests) and the Solidity SMTChecker try to prove properties for all inputs rather than sampled ones. Powerful for core accounting logic; expensive to set up and only as good as the properties written.
- Economic review: for DeFi, modeling flash-loan attacks, oracle manipulation and incentive failures that are logically "correct" code but exploitable.
Vulnerability classes auditors look for
| Class | What goes wrong |
|---|---|
| Reentrancy (including cross-function and read-only) | External call made before state is updated, letting the callee re-enter and act on stale state |
| Access control | Unprotected admin or initializer functions; roles granted too broadly |
| Oracle and price manipulation | Spot prices from a single pool moved by a flash loan within one transaction |
| Accounting and rounding | Precision loss, rounding in the user's favor, ERC-4626 first-depositor inflation attacks |
| Signature handling | Replay across chains or contracts, missing nonces or deadlines, unchecked signers |
| Upgradeability | Storage collisions between versions, uninitialized implementations, unsafe upgrade authority |
| Token integration | Fee-on-transfer, rebasing or non-standard ERC-20 tokens breaking assumptions |
| Denial of service | Unbounded loops, griefing that blocks withdrawals or liquidations |
| MEV exposure | No slippage limits or deadlines, making users easy sandwich targets |
The ethereum.org security guide is a good primer for your own team before the audit begins.
The audit process step by step
- Scoping. Share the repository, the list of in-scope files, lines of code and any external integrations. The firm estimates effort in auditor-weeks and books a slot, often weeks ahead.
- Preparation. Freeze a commit hash. Provide a specification, architecture diagram, known risks, invariants and a test suite that runs with one command. Every hour auditors spend understanding undocumented intent is an hour not spent finding bugs.
- Review. Usually two or more auditors work in parallel, with a channel open for questions. Expect questions about intent; answer quickly.
- Report. Findings are ranked, typically critical, high, medium, low and informational, with impact, likelihood, proof of concept and recommendation.
- Fix and re-review. You fix issues on a new commit; auditors verify each fix and check that fixes did not introduce new bugs. The final report states which commit was reviewed.
- Publish. Publish the report and make sure the deployed bytecode matches the audited commit. Changes after the audit are unaudited code.
Firms, contests and bounties
Three models complement each other. Private audit firms give you a dedicated team, a predictable schedule and continuity. Audit contests on platforms such as Code4rena, Sherlock and Cantina open the code to many independent researchers for a fixed period, with a prize pool paid for valid findings; they offer breadth and are often run after a private audit. Bug bounties, commonly hosted on Immunefi, pay for vulnerabilities found after launch and keep review going for the life of the protocol. A bounty sized meaningfully relative to the funds at risk gives researchers a reason to report rather than exploit.
Choosing an auditor
- Read their past public reports. Are findings specific and well explained, or padded with style nits?
- Check relevant experience: a firm strong on EVM lending may be weak on Solana programs or ZK circuits.
- Ask who exactly will review your code and for how many days.
- Avoid audits promised in a couple of days for complex code, or "audit badges" sold with token launches.
- For high-value systems, use more than one independent review.
After the audit
Deploy with ownership on a multisig, set up monitoring for unusual events and balance movements, define who can pause what, and rehearse an incident response. Security is a lifecycle covered further in the smart contract development guide, the Solidity development page and the article on why smart contract audits matter. For protocol-level risk, see DeFi development.
Frequently asked questions
How much does a smart contract audit cost?
Pricing is driven by auditor-weeks, which depend on lines of code, complexity and novelty. A small token contract may need a few auditor-days; a large DeFi protocol can take several auditors many weeks. Get quotes from multiple firms using the same frozen scope.
How long does an audit take?
The review itself ranges from a few days to several weeks, plus lead time to book a slot and time for fixes and re-review. Plan the audit into your launch timeline from the start.
Does an audit guarantee my contract is safe?
No. Audited protocols have been exploited, often through code changed after the audit, integrations outside scope or economic attacks. Treat an audit as one layer alongside testing, formal methods, bounties and monitoring.
When is formal verification worth it?
When a small core of logic protects large amounts of value, such as vault accounting, lending health checks or bridge verification. It proves the properties you specify, so writing the right properties is the critical skill.