Coverage and blind spots of smart contract audits

What a smart contract audit covers and what it can never cover

A smart contract audit is a one-time review of a set of contract documents under a specific submission version for a specific threat model. It tells readers that at that moment, the named code has been checked against known vulnerability types. But it doesn't tell readers whether the protocol is currently safe to use, because everything other than deployment, governance, key escrow, and named code is by design outside the scope of review.

What is the actual content of the review?

TokenToolHub's process guide divides the review into five levels: contract code, architecture (how agents, modules, and factories are put together), permissions (who can upgrade, suspend, cast, or bail out funds), specified integrations (oracles, cross-chain bridges, external tokens), and sometimes deployment operations such as time locks and multi-signature settings. Coin98's guidelines apply the same hierarchical approach, listing in tabular form what is usually on the other side of the boundary-that is, what audit reports claim to have not inspected.

usually falls within the scope: Contract code reviewed under a specific commit hash; Architecture: How agents, modules, and factories interact; Rights structure: Who has upgrade, pause, and cast permissions; Specified integrations: Specific oracles, cross-chain bridges, and external tokens; Deployment mechanisms: scripts, timelocks, multi-signature configurations.

is usually out of range: Sites and their DNS records and domain name registrars; how administrators and signer keys are actually held and used; whether governance and multi-signature approvals work as expected in practice; the complete surface of trust behind these external dependencies; and whether token economics and reward models are sustainable.

TokenToolHub pointedly points out the underlying problem: A report that clearly states what was not checked is more useful than a report that implies that everything has been checked. "Scope also requires honest scope boundaries," it wrote.

Review how it actually works

In its July 2026 process guide, the Blockchain Committee broke down a serious audit into several stages: Scope definition and document review, code freezing, automated analysis using tools such as Slither, Mythril, and Echidna, manual line-by-line review, fuzz and immutability testing, building proof-of-concept for each discovery, and severity classification-usually divided into severe, high, medium, low, and informational levels. Coin98 's guidelines cite TokenToolHub's audit guidelines and divide the same work into four phases: scoping, review, discovery and repair, with repairs followed by retesting. The Blockchain Committee stipulates that the final report should mark each issue as fixed, confirmed, partially fixed, or unresolved. Regarding the limitations of the automation layer, the blockchain committee wrote: "They often cannot determine whether reward formulas can be utilized, whether oracles can be manipulated in a single block, or whether governance can be captured through a strange voting sequence." This judgment is left to manual reviewers.

Practical case: The gap between Euler and code and design

According to AnChain.AI, before the lightning attack on March 13, 2023, Euler Finance suffered ten audits from six audit firms (Halborn, Solidified, ZK Labs, Certora, Sherlock and Omnisica), which claimed losses were US$196 million. Olympix gave a figure of $197 million when describing the same incident. Both numbers come from evidence reviewed for this article and cannot be reconciled here; when data from individual events is repeated as fact, this difference is itself noteworthy. According to AnChain.AI, Euler CEO Michael Bentley described the incident as one of the "most difficult days" of his life. The technical points raised by both media outlets were the same: the attack was carried out through donation, clearing and collateral accounting logic, and the behavior of these logic was fully consistent with the way the code was written. The vulnerability lies in economic design, not in a wrong line of syntax-the type of failure audits are least good at catching, according to Olympix's analysis.

What does the loss data actually say and why they are inconsistent

Asked how much stolen cryptocurrency an audit could have captured, the source here gives four different answers, from four different data sets:

In an article published on June 15, 2023, AnChain.AI analyzed security incidents in 2022 and found that $2.81 billion was lost due to smart contract vulnerabilities, of which 91.96% of the attacked contracts had been audited at least once. Hacken's second quarter 2026 report (cited by Coin98) attributed 88.3% of the $763.9 million loss in the second quarter of 2026 to operations and key breaches, while smart contract vulnerabilities-the category targeted by the audit-accounted for approximately 11%. SigIntZero's Software Security Report (released in February 2026) reviewed the 100 largest security incidents between 2014 and 2024, with a total loss of US$10.77 billion, and found that audited applications accounted for 10.8% of vulnerability losses, while only 20% of the attacked applications had been professionally audited. CORE3's analysis of approximately $10 billion in funds stolen from Web3 between 2023 and 2025 (cited by Coin98) concluded that no audit had the scope of covering the way in which approximately 75% of the funds were stolen-because the funds were lost through aspects that were not covered by the audit scope statement (such as cross-chain bridge dependencies or the leaked key of the signer).

These numbers use different years, different loss data sets, and different definitions of "audited". They are not four measurements of the same thing, and no individual number in the list should be quoted as an industry ratio. The consistent thread running through all four data items, as well as CORE3 's individual findings, is that audits are required to prove a larger claim than a limited scope of code review can support-a limit that CORE3 directly points out, saying audits were never designed to cover most ways in which agreements actually fail.

Three specific incidents in April 2026 cited by Coin98 illustrate where the funds actually went: Kelp DAO lost $292 million due to cross-chain bridge dependencies and verification configurations;Drift protocol lost $285 million due to social engineering attacks by multiple signers;CoW Swap lost approximately $1.2 million due to breaches of DNS and domain name registrars that provided fake interfaces. These are not within the above scope level.

The depth of scope is also more different than the word "audited" suggests. According to Coin98's description of the results of the CORE3 survey, CORE3 reviewed 293 audited projects and found that only 21% of the projects had comprehensive scope;43% were partial scope, and 35% were minimum scope. In the same sample, 67% of projects did not have an active vulnerability bounty program running, 42% showed stagnant activity on GitHub, 53% did not publish risk statements, and each project in the sample had at least one weak off-chain area. In addition, based on Hacken's report for the second quarter of 2026 (relayed by Coin98), Cysic founder Leo Fan described the scope of the report as covering code at "specific points in time"-it does not extend to how the code works after it.

Common vulnerability types that audits aim to discover

The advantage of audits lies in the known vulnerability categories. SpaceDev cited OWASP's top ten risks for smart contracts in 2026 and listed access control issues, business logic vulnerabilities, price oracle manipulation, lightning loan attacks, missing input verification, unchecked external calls, arithmetic and Rounding errors, reentry attacks, integer overflows, and proxy or upgradeability defects as common categories based on 2025 security incident data. According to the blockchain committee's description of the process, manual review-tracking state changes, checking role permissions, testing the initialization of scalable agents-is the way to discover these vulnerabilities.

How to read an audit report

Coin98 's guidelines refine it into practical checking steps: first read the scope section; find the actual report instead of the badge picture; match the commit hash named in the report with the actual deployed address; check the date against the protocol's change log because audits older than the most recent upgrade describe the past state of the protocol, not the current state; and see how unresolved issues are flagged-confirmed, fixed or unresolved.

What this page does not tell you

Each source on this page is a security provider's blog, marketing-related guide or secondary aggregation platform. None of them are audit firms 'own methodological documents, court records or regulatory documents, so this page describes how the security industry talks about audit scope, rather than verified external standards. Several data-the data cited above from Hacken, CORE3, and SigIntZero-arrived here only through Coin98's citations to these reports, not from the reports themselves, which adds a second jump in attribution, which this page points out here rather than treating them as independent confirmations. The loss attribution range given here (from approximately 11% to 91.96%) cannot be reconciled based on the evidence collected; it spans different years, different loss data sets, and different "audited" definitions, and no single number within this range should be considered an industry number. AnChain.AI's 2022 dataset was described in its own post as being provided "on request" rather than released in its entirety, and therefore has not been independently verified. This page also cannot tell readers whether the audit of any particular agreement itself is comprehensive or superficial-this requires reading the actual report of the agreement and its scope section, which goes beyond the information provided for a particular project by any source reviewed herein.