Smart Contract Audits: What They Catch, What They Miss

A smart contract audit is often treated as a stamp of safety: audited means safe, unaudited means risky. The reality is narrower and more useful once you understand it. An audit is a structured review that catches specific, known categories of mistakes — it is not a guarantee, and audited protocols have still lost user funds to exploits. This piece covers what an audit actually does, and where its limits are.

What an audit actually checks

A smart contract audit is a manual and automated review of a contract’s code, typically performed before deployment, looking for known vulnerability patterns: reentrancy bugs, integer overflow and underflow, access control mistakes that let the wrong address call a privileged function, and logic errors that diverge from the contract’s stated intent. Auditors also check the contract against the project’s own documentation, looking for places where the code does something different from what it claims to do.

Because smart contracts execute exactly as written and are difficult to change once deployed, this category of bug is unusually consequential — a flaw that a traditional application could patch quietly can, on a live contract holding real value, be exploited the moment it is discovered. That is the core reason audits exist as a distinct practice rather than being folded into ordinary code review.

What audits reliably catch

Established, well-understood vulnerability classes are where audits earn their reputation. Reentrancy — where a malicious contract calls back into the auditing contract before its first call finishes, draining funds through repeated withdrawals — is a textbook case that experienced auditors check for as a matter of routine, precisely because it caused some of the earliest, most expensive exploits in the space. Access control gaps, unchecked external calls, and predictable-randomness issues fall into the same category: known failure modes with known detection methods.

For these categories, a competent audit meaningfully reduces risk. A contract that has been through review by a reputable firm is measurably less likely to fail to a known attack pattern than one that has not.

What audits do not catch

Audits are far less reliable against novel exploits, complex multi-contract interactions, and economic design flaws that have nothing to do with a coding mistake. A contract can be implemented exactly as specified and still be exploitable because the specification itself has a flaw — an oracle price feed that can be manipulated, an incentive structure that rewards behaviour the designers did not anticipate, or a governance mechanism that a well-funded attacker can temporarily capture. None of these are bugs in the traditional sense, and no amount of code review catches a design flaw that the auditor is not specifically looking for.

Audits are also a snapshot. A contract can be audited, then modified afterward without a follow-up review, or composed with other contracts in ways the original audit never considered. DeFi’s core feature — permissionless composability, where any contract can call any other — is also the reason an audit of one contract in isolation cannot guarantee safety once it starts interacting with contracts nobody reviewed together.

What this means in practice

Treat an audit as meaningful risk reduction against known categories of bugs, not as proof of safety. A published audit report is worth reading, not just citing — check what scope it actually covered, whether findings were resolved or merely acknowledged, and how recently it was performed relative to the current, possibly modified code. An audit reduces risk; it does not remove it, and no legitimate project should imply otherwise.