What a Smart Contract Audit Does and Doesn't Cover
An audit reviews code at one commit. Roughly 75% of capital drained from Web3 fell outside any audit scope.
A smart contract audit is a scoped review of specific code at a specific moment — not a safety certificate for a protocol. That distinction is where most of the money goes. In Q2 2026, operational and key compromises accounted for 88.3% of the $763.9 million extracted from Web3, according to Hacken's quarterly report as covered by Bitcoin.com News, while smart contract bugs — the thing audits are built to find — drove roughly 11% of the value lost. This guide covers what falls inside the audit boundary, what falls outside it, and how to read a report so the badge stops doing your thinking for you.
What an audit actually is
An audit is a manual and tool-assisted review of a defined set of contract files, at a defined commit, against a defined threat model. Every clause in that sentence is a limit.
The process runs in four stages, per TokenToolHub's audit guide: scoping, where the team hands over repository access and architecture documentation; review, where auditors map trust boundaries and hunt for vulnerabilities; findings, where issues are classified by severity; and remediation, where fixes are made and retested.
Findings are usually graded from informational to critical. The more useful distinction, as the same guide notes, separates local issues that can be fixed in place from systemic ones that need architectural change. A report with three mediums fixed in a week is a different signal from a report with one critical that required a redesign.
Cysic founder Leo Fan put the boundary plainly in Hacken's Q2 coverage: an audit is "a scoped assessment of a particular codebase at a particular point in time." It does not follow the code into production, and it does not extend to the people operating it.
What is in scope, and what is not
Scope typically spans five layers — and stops well short of the systems that surround them.
| Usually in scope | Usually out of scope |
|---|---|
| Contract code at a named commit | The front end, DNS and domain registrar |
| Architecture: proxies, modules, factories | Team key management and signer devices |
| Permissions: who can upgrade, pause, mint | Governance and multisig procedures in practice |
| Named integrations: oracles, bridges, tokens | The full trust surface of those external dependencies |
| Deployment scripts, timelocks, multisig setup | Tokenomics and economic sustainability |
TokenToolHub's guidance to project teams is worth reading as a user: "Scope also needs honest out-of-scope boundaries." A report that names what it did not look at is more informative than one that implies it looked at everything.
CORE3's analysis puts it more bluntly — "a smart contract audit was never designed to cover most of the ways a protocol actually fails." Our explainer on what a smart contract is covers what the auditor is reading; the point here is how much of a protocol is not that.
What the numbers say about the gap
Most drained capital never touched audited code. That is the finding worth internalising.
CORE3 analysed roughly $10 billion extracted from Web3 across 2023–2025 using Rekt data and concluded that "around 75% of that capital was drained in a way, no audit was scoped to check." The industry spent an estimated $500 million on roughly 10,000 DeFi audits since 2020 — money that bought coverage of a real risk category, just not the largest one by value.
April 2026 supplies three clean examples, each failing outside the contract layer:
| Incident | Loss | Failure point |
|---|---|---|
| Kelp DAO | $292M | Bridge dependency and verification configuration |
| Drift Protocol | $285M | Governance — social engineering of multisig signers |
| CoW Swap | ~$1.2M | DNS and registrar, serving a counterfeit interface |
We covered the Kelp DAO case in detail in our piece on why cross-chain bridges keep getting hacked — the contracts executed exactly as written, using data from a verifier that had been fed a lie.
There is a counterweight worth stating. SigIntZero's 2026 Software Security Report, published in February 2026, examined the 100 largest breaches from 2014 to 2024 — $10.77 billion in total losses — and found that audited applications accounted for only 10.8% of exploit losses, while just 20% of exploited applications had ever been professionally audited. Read together, the two datasets are not contradictory: audits meaningfully reduce one class of risk, and say almost nothing about the others.
Why "audited" gets misread
The badge collapses four separate variables into one word: which code, how much of it, when, and how deeply.
- Which code. Reports name a commit hash. If the deployed contract does not match it, the audit describes a different program. In the Nomad Bridge exploit, SigIntZero found only 18.6% of the critical contract code matched what auditors had reviewed.
- How much. CORE3 reviewed 293 audited projects and found comprehensive scope in only 21%. Another 43% were partial and 35% minimal. "Audited" is true of all three.
- When. Code ships. An audit from before a feature release does not cover the feature.
- How deeply. Scope is a budget conversation. A cheaper engagement covers fewer functions, and the report will say so if you read the scope section.
The same CORE3 sample found 67% of those projects had no active bug bounty, 42% had stalled GitHub activity, 53% published no risk disclaimers, and 100% had at least one weak off-chain domain. The audit was the visible part of a much thinner security posture.
How to read an audit report in five minutes
Read the scope section first. Most of what you need is there, and most people skip it.
- Find the report itself, not a badge image. A badge is a picture; a report is a document with a date, a firm, and a commit hash.
- Check the scope and the exclusions. What files were reviewed, and what does the firm say it did not look at?
- Match the commit hash to the deployed address. If you cannot verify that the contract you are about to use is the contract that was audited, the report is background reading.
- Read the date against the changelog. An audit from before the last three upgrades covers the protocol as it was, not as it is.
- Look at unresolved findings. "Acknowledged" means the team read it and chose to live with it. Sometimes that is reasonable; it is always worth knowing.
- Check severity distribution and how fixes were verified. Retested fixes are stronger evidence than a claim of remediation.
- Look for what surrounds the audit — an active bug bounty, monitoring, published incident procedures.
That last point is where most projects fall short. Hacken's Q2 2026 data found that only 9% of tracked projects maintain continuous monitoring, and only 4% combine audits, bug bounties and live monitoring.
What sits beside an audit
An audit is a snapshot. A bug bounty is an open invitation, and monitoring is a live alarm — the three cover different time windows.
We run bug bounty programs on HackenProof and Bugrap, and publish audit reports for our core products in the audits section of our documentation. The reason both exist is the one this article is about: a report describes code at a moment, and a bounty keeps paying for findings after that moment has passed.
For you as a user, the layer you control is your own exposure. Neither an audit nor a bounty prevents a protocol failing underneath you, but the approvals you leave open determine how much of your wallet is reachable when it does. Wallet Health scans across eight categories including Approval, Connections and Interacted URL, and surfaces the permissions worth closing.
What this means before you deposit
An audit is best treated as one input among several, weighted by what it actually examined.
- An audited protocol can still fail — through governance, keys, a dependency, or its front end.
- An unaudited protocol is not automatically a scam, but it is carrying a risk category nobody has checked, and we would size positions accordingly.
- Multiple audits help most when they cover different components, rather than repeating the same scope. Applying the same lens twice mainly buys redundancy.
- An audit says nothing about intent. It cannot tell you whether the team will still be operating the protocol next quarter — our guide on what to do when a DeFi protocol shuts down covers that scenario.
- The economic design is separate. Liquidation parameters, collateral quality and yield sustainability are not audit findings — our DeFi lending explainer covers what to look at there.
The habit that generalises: evaluate the thing rather than the badge on it, which is the same approach we take to judging a wallet's security claims.
FAQ
Does a smart contract audit mean a project is safe? No. It means a named set of contracts was reviewed at a named commit against a defined threat model. Hacken's Q2 2026 data recorded 14 audited protocols breached in a single quarter, with 88.3% of losses coming from operational and key compromises rather than contract bugs.
Can an audited protocol still be hacked? Yes, and it happens through the parts an audit does not cover. The three largest April 2026 incidents failed at a bridge dependency, at multisig governance, and at DNS — none of them at the audited contract logic.
What is usually out of scope in a smart contract audit? Front end and domain infrastructure, team key management, governance procedures as practised, the full trust surface of external dependencies, and tokenomics. Reputable reports state their exclusions explicitly.
How old is too old for an audit? Age matters less than change. An audit from twelve months ago on code that has not shipped since is more informative than one from last month on a protocol that has upgraded twice. Compare the report's commit hash and date against the deployment history.
Are multiple audits better than one? Usually, though the benefit comes from coverage rather than repetition. Euler Finance is the cautionary case: after its $197 million exploit in March 2023, audit firm Sherlock publicly took responsibility for missing the vulnerability in its review and paid a $4.5 million claim. Reviews can be thorough and still miss the thing that matters.
What should I check besides the audit? An active bug bounty, continuous monitoring, published incident procedures, upgrade and admin key arrangements, and how the protocol has behaved during past stress. Only 4% of projects Hacken tracked in Q2 2026 combined audits, bug bounties and live monitoring.
The takeaway
A smart contract audit answers one question well: does this code, at this commit, do what it claims without a known class of bug? It does not answer whether the keys are safe, whether governance can be socially engineered, whether the domain can be hijacked, or whether the deployed contract is even the one that was reviewed. The numbers make the case — roughly 75% of capital drained across 2023–2025 fell outside any audit's scope, and 88.3% of Q2 2026 losses came from operational failure. Read the scope section, match the commit hash, and check what surrounds the audit. Then manage the part you control: Wallet Health will show you which approvals are still open when a protocol you used turns out to have a gap.
Last updated: August 2026
