A smart contract audit is essentially a code review performed by security specialists. Auditors examine the contract source code looking for vulnerabilities, logic errors, and deviations from the specification. The typical audit for a DeFi protocol takes 2-6 weeks and costs anywhere from $50,000 to over $500,000 depending on the complexity and the auditing firm.
What audits reliably catch are known vulnerability patterns. Reentrancy attacks, integer overflow and underflow issues, access control misconfigurations, and front-running vulnerabilities all have well-documented signatures that experienced auditors can identify. These are the kinds of bugs that have well-established test cases and detection tools. Automated analysis tools like Slither and Mythril can catch many of these before a human auditor even starts reviewing.
Where audits get less reliable is in catching business logic errors. A contract might be technically secure, with no exploitable vulnerabilities in its code, but still have a logical flaw that allows value extraction in ways the designers did not intend. These bugs require the auditor to deeply understand what the protocol is supposed to do and then verify that the code actually does that. This is harder than it sounds, especially for complex protocols with multiple interacting contracts.
Composability risks are particularly difficult to audit. A contract might behave perfectly in isolation but create vulnerabilities when it interacts with other protocols. Flash loan attacks often exploit these interaction patterns. The contract being audited might have no bugs at all. The problem is in how it responds to unexpected inputs from other contracts that did not exist when the audit was performed.
Economic attacks represent another category that traditional audits handle poorly. Oracle manipulation, governance attacks, and liquidity pool imbalances are often not code bugs. They are economic incentive problems that require game-theoretic analysis rather than code review. Some auditing firms have started adding economic analysis to their services, but this remains less mature than traditional code auditing.
The audit report itself deserves attention. Most audit firms classify findings by severity: critical, high, medium, low, and informational. A clean audit does not mean there are no findings. It means all critical and high-severity findings have been addressed. Low and informational findings are often acknowledged but not fixed, which is generally reasonable but worth understanding as a user.
Multiple audits from different firms provide better coverage than a single audit, no matter how reputable. Different firms use different methodologies and have different areas of expertise. Trail of Bits might catch something that OpenZeppelin misses, and vice versa. The most security-conscious protocols get 2-3 audits plus maintain ongoing bug bounty programs.
Bug bounty programs serve as a continuous complement to point-in-time audits. Immunefi hosts bounties for hundreds of protocols, with rewards ranging from thousands to millions of dollars. The economic logic is simple: paying a white hat hacker $500,000 to find a bug is much cheaper than losing $50 million to an exploit. Protocols that combine audits with generous bug bounties tend to have the best security track records.
For users, the practical takeaway is that an audit is necessary but not sufficient. It significantly reduces the probability of certain types of exploits but does not eliminate risk. The presence of an audit should increase your confidence, but it should not be the only factor in your risk assessment. Time in production without incidents, the size and activity of the bug bounty program, and the protocol team track record all matter as well.