Most losses in audited DeFi hacks happened outside audit scope, preprint finds
Audited projects still suffered most of the losses
Decentralized finance (DeFi) apps let people lend, borrow and trade crypto without traditional middlemen. A new preprint reports that in hacks of audited DeFi projects, most of the lost money moved through parts of those projects that auditors had not covered.
The study, by researchers linked to security firm ack3 and the Czech Technical University in Prague, looked at 135 reported incidents from Jan. 1 through June 29, 2026, with $939.86 million in attributed losses. For 68 of those incidents, the researchers found identifiable public audits from before the attack.
Key numbers from the audited incidents
- Of the 68 incidents with identifiable pre-attack audits, 46 were classified as outside every audit scope the researchers could identify, 20 as inside at least one scope, and two as unresolved.
- Outside-scope incidents made up 67.6% of the audited incidents but 94.4% of reported losses in that group, or $680.97 million of $721.24 million.
- After excluding $292 million at Kelp DAO and $285 million at Drift Protocol, outside-scope losses were still 72.1% of the remaining reported losses, or $103.97 million of $144.24 million.
What the study can and cannot prove
The dataset covers incidents from Jan. 1 through June 29. The authors graded 122 as confirmed and 13 as likely. Of the full set, 35 had no identified audit and 32 had an unknown audit history, so those were not part of the 68-incident scope calculation.
The authors say the result is not an estimate of audit effectiveness and does not prove that an audit’s boundaries caused any loss. The inside/outside labels are the researchers’ judgments based on public evidence. The study is a six-page preprint, and two of its authors work for ack3, which sells security reviews.
The study also lacks a comparison group of unaudited or unexploited systems and a measure of how long each system was exposed. It cannot establish whether audited protocols are safer overall, estimate the chance of an incident, or show that falling outside an audit scope caused a loss. Undisclosed audits and private incidents may be missing from the data.
ICON exploit shows the audit boundary problem
ICON Network’s Aug. 27 replay exploit is a direct example of reviewed code failing at the boundary between two checks. According to the ICON Foundation’s Aug. 30 postmortem, a migration contract used the high bits of a withdrawal message’s serial number to decide if the message was unique. The cryptographic signature covered only the low 256 bits.
An attacker changed the unsigned high bits and resubmitted two legitimately signed withdrawal messages 1,492 times in about 20 minutes. ICON said 1,490 of those calls succeeded. The replays released 119.866 million ICX and 531,600 bnUSD. ICON put the confirmed net loss at about 150.2 ETH plus 31,204 USDC at the time of the postmortem, and said 531,600 bnUSD and 1.366 million SODA had been recovered. User deposits, balances, and positions were not affected.
ICON said the migration contract had undergone an external audit and that recommendations had been implemented, including changes in the same area. It said the relevant relay logic also received a dedicated review. The SODAX audit archive lists eight reports across different components, including a November 2025 relay audit.
What is still unclear
The August aelf incident remains unresolved in the study. The available audit evidence cannot yet be tied to its reported runtime path. The researchers also note that undisclosed audits or private incidents may be missing, and reported loss figures are not perfectly comparable.
Why the audit gap matters
An audit usually covers named code, components, and versions at one point in time. Anything added, excluded, or operated around that boundary can have a different level of assurance. The study exposes a basic assurance problem: a project can truthfully say it was audited while users cannot tell whether the live system, the path holding their funds, and the controls around it were reviewed.
A reviewed smart contract does not automatically give the same assurance to upgrades, privileged keys, front ends, relayers, oracles, cloud services, or incident-response processes.