Lesson 3 — Reading audits: what they cover, what they miss

**What an audit is.** A structured review of a specific commit hash of a smart-contract codebase by a third-party security firm or competitive review platform. The auditor reviews the code, models the protocol's invariants and intended behavior, runs static analyzers, executes property-based tests (often with Foundry's invariant testing or Echidna), and produces a report enumerating findings by severity. Findings have status — typically 'Acknowledged,' 'Fixed,' 'Disputed,' or 'Won't fix.' The published report is a snapshot of the code at the audited commit; any change to the contracts after the audit is, by definition, unaudited.

**Severity classifications.** Most reports use Critical / High / Medium / Low / Informational, sometimes with Gas optimization as a separate category. Critical findings are 'attacker can drain funds' or 'protocol invariant can be broken with on-chain action.' High findings are exploitable under specific conditions or cause major griefing. Medium findings are bounded losses or impair functionality. Low and Informational are quality issues that don't directly enable an attack. The single most important practice in reading audits: read every Critical and High finding's text in full, not just the title. The title is the headline; the body is whether the finding was actually fixed, how it was fixed, and whether the fix introduces new surface.

**What audits routinely miss.** Three broad categories. First, **economic / game-theoretic exploits** — the code does exactly what it's supposed to, but the protocol's incentive design lets an attacker extract value. Oracle manipulation falls here when the oracle is functionally working but vulnerable to flash-loan-funded price moves. Mango, bZx, and many curve-shape attacks live in this category. Audits focus on code correctness; economic auditing is a separate (and less mature) discipline. Second, **integration issues** — contracts that work correctly in isolation but break in combination with other protocols. The Euler exploit (March 2023, $197M) had this character: the donateToReserves function was correct, but its interaction with the protocol's accounting in a specific sequence allowed self-liquidation in a way no individual audit had flagged. Third, **unknown unknowns** — code patterns that hadn't been recognized as dangerous until they were exploited. Read-only reentrancy (which affected Curve and Balancer pools in 2022–2023) was understood theoretically before but rarely caught in audits.

**Multiple auditors and competitive audits.** A common practice is multiple audits from independent firms — Trail of Bits + Spearbit + OpenZeppelin, for example — to reduce single-firm blind spots. Code4rena, Sherlock, and Cantina run competitive audits where many auditors compete to find issues, paid by severity. These often surface findings that traditional engagements miss, particularly economic exploits, because competitive auditors are incentivised to find every issue. But they also produce a long tail of noise (false positives and low-severity findings), and reading a competitive-audit report well requires more skill than reading a traditional one.

**Auditor reputation signals.** Among the firms that have built reputations for serious work: Trail of Bits, OpenZeppelin, Spearbit, Cantina, Code4rena, Sherlock, ConsenSys Diligence, Macro, Halborn. Firms whose reports show mostly Informational findings and no Critical or High findings on protocols that have since been exploited should be treated with greater skepticism. Conversely, no firm has a perfect record — major exploits have followed audits by every named top-tier firm, because the categories audits miss are the categories that produce the most painful exploits.

**How to actually read a report.** First, check the date and commit hash. Is this audit current? Has the protocol changed materially since? Second, scan for Critical and High findings. Read each in full, including the response. Third, check the 'Won't Fix' or 'Acknowledged' findings — these are issues the protocol team chose not to address, and the reasoning is sometimes load-bearing (sometimes a finding is genuinely a false positive; sometimes the team accepted a real risk). Fourth, look at the scope section — what contracts were in scope? What was explicitly out of scope? Many audits exclude bridges, oracles, governance contracts, or upgrade mechanisms. Fifth, cross-reference with on-chain reality: does the deployed code match the audited commit? Etherscan's contract verification page shows the source code; comparing against the audited version is a check anyone with patience can run.

**The signal an audit *does* give you.** A clean, recent audit by a credible firm with no unresolved Critical / High findings, on the actual deployed code, is a meaningful baseline. It tells you that competent reviewers found nothing obviously catastrophic in the code paths they examined. It does not tell you that no economic exploit is possible, that no integration with other protocols will produce surprises, or that no future code change will introduce new bugs. Treat audits as one input into risk evaluation — necessary but not sufficient.