A general counsel reviewing a protocol before an allocation is usually handed one document: an audit report. The temptation is to read the summary and move on. The summary rarely says what was actually tested, what was deliberately left out, or what has changed in the code since the report was signed. Those three questions matter more than the headline finding count, and the word "audited" answers none of them.
What an audit actually establishes
A smart contract audit is a statement about a named set of files at a specific commit, reviewed by a specific team, using specific methods, over specific dates. Change any one of those and the statement no longer applies. OpenZeppelin's account of its audit process, published 22 January 2025, says the firm identifies "the exact version of the code to audit, avoiding last-minute changes." Its public reports name that version directly: its audit of Across Protocol's contracts-v5 repository, reviewed from 4 to 20 May 2026 and published on 17 August 2026, was performed at commit f9578f0. A diff audit of Open Intents Framework contracts, published on 21 May 2026, covered only the changes between a base commit and a target commit, not the whole codebase.
Manual review, static analysis and fuzzing
OpenZeppelin describes a seven-stage process. At its centre is manual review, with at least two auditors examining the same code independently, combined with automated methods: static analysis, which flags known unsafe patterns, and fuzz testing, which feeds large volumes of generated inputs to the contract to push it into states its authors did not anticipate. Automated tools cover the patterns that are cheap to check at scale; human reviewers cover the logic specific to the protocol.
Formal verification
Some engagements go further, into formal verification, which proves mathematically that code satisfies a written specification for all inputs, within the limits of the prover used, rather than testing it against sample inputs. Certora's engagement on Aave's GHO stablecoin contracts, which ran from 30 January to 28 February 2023, is a public example. The team wrote specification rules, made them publicly available on GitHub, and ran them through the Certora Prover against seven contracts, including the token, the interest rate strategy and the flash minter. The report says the issues found were corrected, and that the fixes "were verified to satisfy the specifications up to the limitations of the Certora Prover." That caveat matters: a proof is only as good as the specification it proves, and a specification can omit a property that matters.
Severity ratings and remediation
Findings are graded. OpenZeppelin uses five levels: Critical, High, Medium, Low and Informational. What the grade does not tell a reader is whether the finding was fixed. OpenZeppelin's clients are entitled to one round of fix review, provided each fix sits in its own pull request. Reports commonly then mark each finding as resolved, partially resolved, or acknowledged, meaning the client chose to keep the risk. That last category is easy to miss. A report with no open Critical findings can still list Medium or High findings the client decided to live with, and a reader who stops at the summary never sees that decision.
A standard for what "audited" means
Because audit scope and depth vary between firms, the Enterprise Ethereum Alliance publishes the EthTrust Security Levels specification, a voluntary certification standard for Solidity smart contracts. Version 2, approved on 13 December 2023, defines three levels. Level S is designed so that, in most cases, code can be certified by an automated static analysis tool. Level M requires stricter static analysis and includes requirements where a human auditor decides whether use of a feature is necessary. Level Q adds analysis of business logic, checking that the code not only avoids known vulnerabilities but correctly implements what it claims to do. For an institutional reader, the value is a shared vocabulary for what was checked that does not depend on one vendor's description.
What an audit does not cover
Code that was never in scope
An engagement has a boundary, and it is often narrower than "the protocol". A clean report on the contracts says nothing about the website that builds the transaction a user signs, the multisig interface an operations team uses, or the off-chain bots that call the contract, unless the report says they were in scope. Our piece on DeFi's wider threat model sets out why bridges, key custody and governance need mapping separately from the code review.
Code that changes after the audit
A report is a snapshot. A protocol that is upgradeable, through a proxy, a governance vote or an admin key, can change the logic behind the audited interface after the report is dated, and the audit has no view of that change. We cover the governance side, including upgrade delays and signer independence, in who actually controls a protocol.
Bugs beneath the audited code
Some failures sit below the source code an audit reads. On 30 July 2023, four Curve Finance pools were drained for losses LlamaRisk's analysis of the same day put at around $60 million. The cause was a bug in versions 0.2.15, 0.2.16 and 0.3.0 of the Vyper compiler, which broke the reentrancy protection those pools relied on. According to the Vyper team's post-mortem, the bug entered with the 0.2.15 release in July 2021 and was absent from 0.3.1 onwards, but every contract compiled with the affected versions stayed vulnerable, and the flaw went unrecognised until the exploit. A review of the source as written does not, in general, re-verify the compiler that turns it into deployed bytecode.
Errors an audit can miss
Audits also miss flaws squarely in scope. KyberSwap's post-mortem, published 7 February 2024, describes a 22 November 2023 attack on its Elastic pools affecting roughly $56.2 million in assets. It traces the cause to a discrepancy in the tick-based swap mechanism, made worse by a rounding error, and states that the vulnerability "was not identified despite prior code audit efforts." A reviewer can read past an edge case, and a fuzzer can fail to find the exact sequence of inputs that triggers it.
Economic design and oracle risk
A code-level audit checks that functions behave as specified. It does not necessarily test whether the design is economically sound, for instance whether a price source can be manipulated more cheaply than the value it protects. On 27 October 2021, Cream Finance lost about $130 million in available liquidity when an attacker, using flash loans, inflated the value that Cream's hybrid oracle assigned to the yUSD vault token held as collateral, then borrowed against it, according to Immunefi's analysis.
Where the losses concentrate
A preprint submitted to arXiv on 13 June 2026 measures the gap. It compares 23,818 public findings from 22 security firms with 218 exploit incidents between 1 January 2022 and 27 March 2026, representing about $7.76 billion in losses. Private-key compromise, phishing and social engineering accounted for about 49.6% of cumulative losses, yet made up a negligible share of published audit findings. Losses were also highly concentrated: the eight largest incidents accounted for 50.6% of the total, and the twenty largest for 71.4%. Chainalysis reported a similar pattern for 2025 on 18 December 2025: more than $3.4 billion stolen between January and early December, $1.5 billion of it in the Bybit compromise, with the top three hacks accounting for 69% of all service losses. An audit measures what reviewers were asked to examine; a loss table measures what actually failed.
A checklist for reading an audit report
- Does the report state a commit hash, and does that code match what is deployed today?
- When was the review carried out, relative to deployment and to any upgrade since?
- Which methods were used: manual review, static analysis, fuzzing, formal verification? A claim of "audited" with no method named cannot be checked.
- Are any Critical, High or Medium findings acknowledged rather than fixed, and is the reason given?
- Was there a fix review, and does the report show the status of each finding after it?
- What is outside scope: front end, bridge, oracle, admin keys, off-chain infrastructure?
- Is the protocol upgradeable, and if so, who can change the audited logic, and how quickly?
- Is this a full audit, or a diff audit of changes since an earlier review? They are not equivalent assurance.
On the Paris 2026 programme
The Paris 2026 programme took up the subject on 3 June 2026 in "DeFi Under Attack: Securing Onchain Finance and the Machine Economy", a panel on the Hecto Main Stage from 16:30 to 17:10, moderated by Nikola Stojanow, with Kostas Chalkias, Charles Guillemet, Rodrigo Coelho and Jason Jiang. The full record is on the agenda. None of this is legal, tax or investment advice, and it does not replace a counterparty's own security and legal review.