When “Audited” Isn’t Enough: How DeFi Lost Hundreds of Millions Outside Audit Scopes
Audits aren’t a “done” sticker
Here’s the short, uncomfortable version: a new analysis of the first half of 2026 looked at 135 reported DeFi incidents totaling about $939.86 million in losses and found that having an audit doesn’t mean every part of a project was actually checked. The researchers were able to find public pre-incident audits for 68 of those incidents. Of that subset, 46 attack paths fell completely outside the scopes of the available audits, 20 were inside at least one scope, and two couldn’t be classified. In plain English: most incidents happened in places audits didn’t cover, and those outside-scope cases accounted for a huge share of the money lost.
Numbers to make you blink: the outside-scope incidents were 67.6% of the audited-incident count but represented 94.4% of the reported losses in that group. Two monster cases skewed things a lot — removing a $292 million and a $285 million event brings the outside-scope share down to about 72.1% of losses for the audited subset. The dataset spans incidents from January 1 through June 29, 2026; other parts of the full incident list either had no identified audit or an unknown audit history and weren’t included in the 68-incident scope calculation.
Important caveats: the study’s labels are based on public evidence and researcher judgment — they hunted archives, audit reports and code diffs and then compared those to how the attacks actually happened. The work doesn’t prove that audits cause or fail to prevent hacks, nor does it say audited projects are necessarily less safe overall. What it does show, pretty loudly, is that “we were audited” and “the live system handling your funds was audited” are not the same statement.
Two messy case studies (because examples stick)
Example 1 — a replay trick: In one incident, two pieces of the same withdrawal flow disagreed about what made a message unique. One contract used some high-order bits of a serial number to decide if a message was fresh, while the cryptographic signature only covered the low 256 bits. An attacker fiddled with the unsigned high bits and replayed legitimately signed withdrawals many times in about 20 minutes. Almost all of those calls succeeded, releasing a bunch of tokens and creating a visible mess. The project had run audits on relevant parts and even had relay reviews on record, but the particular mismatch that allowed the replay sat outside the documented findings. The timeline also showed another problem: alerts existed, but tuning and false-positive fatigue meant the on-call team wasn’t paged fast enough, lengthening the time between first alert and containment.
Example 2 — runtime surprise: In another incident, an unauthorized contract appeared able to smuggle encoded .NET assemblies and instructions into the node execution path. The public updates described gaps in runtime reflection checks, dynamic loading defenses, and weak isolation between contract execution and sensitive node resources. The investigators found a cluster of related transactions and multiple payloads with capabilities like command execution and node reconnaissance. That said, capability ≠ confirmed complete execution: the company couldn’t prove every payload ran or every credential was grabbed, and follow-up reporting remained provisional. Their security docs showed prior audits of contracts, but the available audit records didn’t clearly tie to the exact runtime path that was implicated in the incident.
Both stories underline the same point: audits can examine code artifacts, but they rarely answer the question users actually want answered — is the live deployment, the upgrade path, the keys, the relayer, and the infrastructure that actually moves my money covered by the review?
Make audit claims useful: what projects should publish
Audits still matter. They’re valuable and should be done. But to make the badge meaningful, projects should stop treating audits like magic stamps and start treating them like dated, versioned records. A useful audit record would include: the reviewed repository and commit, exact deployed addresses, a clear list of excluded components, privileged roles and their custody, dependency versions, any upgrades since review, key rotation history, runtime isolation details, alerting and circuit-breaker behavior, and a dated recovery status separating confirmed losses from frozen or unresolved exposures.
That way, when someone says “we were audited,” users can check whether the audit actually covered the thing holding their funds, or whether it was limited to an old snapshot of code. In short: keep the audit, keep doing the hard security work, but also publish the versioned map that connects the audit to the system running right now.
Bottom line: audits are necessary but not sufficient. If you want safety in DeFi, you need prevention, detection, and a public, precise trail that proves what was reviewed — and when.
