A smart contract audit is a structured, independent security review of the code, design and deployment plan of one or more smart contracts, carried out to find vulnerabilities, logic errors and unsafe assumptions before the contracts control real assets. Because deployed smart contracts are usually immutable or hard to change, and because a single flaw can let an attacker drain every token the contract holds, the audit is one of the last and most important quality gates before launch.
An audit combines manual line-by-line review by experienced security engineers with automated tooling such as static analyzers, fuzzers and sometimes formal verification. Its result is a report that classifies findings by severity, records the team’s fixes and states the exact code version that was reviewed.
How a smart contract audit proceeds
A typical engagement begins with scoping: the client freezes a specific commit, lists the contracts in scope, and supplies documentation, a threat model and the intended invariants, such as “total deposits always equal the sum of user balances”. A clear specification is essential, because auditors can only call behavior a bug when they know what the code is supposed to do.
The phases below describe how most professional firms structure the work. Duration scales with code size and complexity; a few hundred lines may take several days, while a large lending protocol can occupy a team for several weeks.
| Phase | Main activity | Output |
|---|---|---|
| Scoping | Fix commit hash, contracts and assumptions | Statement of work |
| Familiarization | Read docs, map architecture and roles | System model and threat list |
| Manual review | Trace every function and state change | Draft findings |
| Automated analysis | Run static analysis, fuzzing, invariant tests | Tool results, confirmed issues |
| Reporting | Rate severity and describe exploits | Preliminary report |
| Fix review | Verify patches and check for regressions | Final report with status per finding |
Vulnerability classes auditors look for
Auditors work from a large catalog of known attack patterns in Solidity, Vyper and the EVM, as well as chain-specific issues on other platforms. The most damaging findings, however, are often business logic flaws unique to the protocol, which no generic checklist can describe in advance.
| Class | Mechanism | Typical mitigation |
|---|---|---|
| Reentrancy | External call re-enters before state is updated | Checks-effects-interactions, reentrancy guards |
| Access control errors | Privileged function callable by anyone | Role checks, ownership modifiers |
| Oracle manipulation | Spot price moved within one transaction | Time-weighted or decentralized oracles |
| Integer and rounding errors | Precision loss favors attacker | Consistent rounding direction, fixed-point math |
| Front-running and MEV | Pending transactions reordered for profit | Slippage limits, commit-reveal schemes |
| Upgrade flaws | Storage collisions or unprotected initializers | Storage layout checks, initializer locks |
| Denial of service | Unbounded loops or blocking reverts | Pull payments, bounded iteration |
Beyond code, auditors examine centralization risk: who holds admin keys, whether upgrades are time-locked, and what a compromised key could do. A protocol with flawless code but a single externally owned account controlling an upgradeable proxy still carries a critical trust assumption.
Severity ratings and the audit report
Findings are ranked by impact and likelihood. Firms use slightly different scales, but the levels below are widely recognized, and the final report shows whether each finding was fixed, partly fixed or acknowledged without change.
| Severity | Meaning | Expected response |
|---|---|---|
| Critical | Direct loss or permanent lock of funds | Must be fixed before deployment |
| High | Loss under realistic conditions | Fix before launch |
| Medium | Loss under unlikely conditions or griefing | Fix or document clearly |
| Low | Minor deviation from expected behavior | Fix when convenient |
| Informational | Style, gas optimization, best practice | Optional |
A report is only meaningful together with its commit hash. If the deployed bytecode differs from the audited version, even by a small late change, the assurance does not transfer. Careful users compare the verified on-chain source with the audited code.
Audits compared with other assurance methods
An audit is one layer in a defense-in-depth approach. Teams usually combine it with internal testing in frameworks such as Hardhat or Foundry, competitive audit contests, bug bounties and, for critical components, formal verification.
- Formal verification mathematically proves that code satisfies a specification, but only for the properties written down.
- Competitive audit contests put many independent reviewers on the same code for a fixed period, increasing coverage of unusual attack paths.
- Bug bounty programs reward researchers who find flaws after deployment and provide continuous coverage.
- Monitoring and circuit breakers detect suspicious transactions and pause contracts when an attack is in progress.
Choosing the mix depends on value at risk. A small NFT minting contract may need one audit, while a protocol expected to hold hundreds of millions in total value locked typically commissions two or more independent audits plus a standing bounty.
Limits of an audit and common mistakes
An audit is time-boxed and sample-based; it reduces risk but never proves the absence of bugs. Many exploited protocols had been audited, typically because the vulnerable code was added later, the attack crossed several protocols, or the flaw lay in an economic assumption outside the agreed scope.
- Changing code after the audit without a follow-up review.
- Excluding integrations, oracles or deployment scripts from scope.
- Treating an audit badge as marketing proof of safety for users.
- Ignoring acknowledged medium findings that later combine into a critical exploit.
- Auditing too early, while the design is still changing.
Choosing an auditor deserves the same care as choosing the code itself. Useful signals include published past reports with detailed findings, reviewers with experience in the same protocol category, and a realistic timeline rather than the fastest quote. A team should also budget for the fix review round, because patches written under deadline pressure frequently introduce new defects.
In simple terms
A smart contract is a program that holds and moves money on a blockchain, and once it is live it is often impossible to fix. An audit is like hiring expert locksmiths to try every way into a safe before anyone stores valuables in it.
They read the plans, test the doors and write down every weakness they find. It makes the safe much harder to break, but it does not make it unbreakable, especially if the safe is modified afterwards.
A practical example
A small team builds a lending pool of about 2,000 lines of Solidity that will accept deposits and issue loans against collateral. They freeze the code, write down invariants such as “no account can borrow more than 75 percent of its collateral value”, and hire an audit firm for a three-week engagement.
The auditors report one critical issue: the collateral price comes from a single liquidity pool, so a flash loan could inflate it within one transaction and let an attacker borrow far more than allowed. The team switches to a time-weighted price feed, the auditors confirm the fix, and the protocol launches with a public report and a bug bounty. The flaw never reaches mainnet.