A preprint paper released by researchers affiliated with security firm ack3 and the Czech Technical University in Prague argues that an “audited” label in DeFi should not be read as a blanket security endorsement for an entire project. Audits usually examine specific code, components, versions, and a fixed point in time. Anything added, removed, or operated outside that scope can fall beyond what was actually reviewed.
The researchers analyzed 135 security incidents reported in the first half of 2026, with total losses of $939.86 million. Of those, 68 had identifiable public records of pre-incident audits.
Most attack paths in the audited sample were classified as outside audit scope
Within the 68 incidents that had public audit records, the paper classified 46 attack paths as completely outside any verifiable audit scope. Twenty incidents were covered by at least one audit, and two could not be determined.
That means out-of-scope incidents made up 67.6% of the audited sample by count. By losses, they represented $680.97 million out of $721.24 million, or 94.4%.
The paper is careful about what that number does and does not show. It is not presented as a scorecard for whether audits work. It is also not evidence that audit scope limits directly caused those losses. The figure only describes how losses were distributed across the selected sample of public incidents.
Two very large cases had an outsized effect on the totals. Excluding Kelp DAO’s $292 million loss and Drift Protocol’s $285 million loss, out-of-scope attacks in the same audited group accounted for $103.97 million out of $144.24 million, bringing the share down to 72.1%.
How the dataset was built
According to the paper, the dataset covers the period from Jan. 1 to June 29, 2026. It includes 122 confirmed attacks and 13 suspected incidents. Across the full sample, 35 incidents had no audit record and 32 had unknown audit history. Neither group was included in the 68-case audited subset used for the scope analysis.
The researchers said the dataset’s JSON file can reproduce both the number of classified incidents and the loss totals. To decide whether an incident was “in scope” or “out of scope,” the team reviewed public archives from projects and audit firms, found audit reports published before the attack, and compared the eventual attack path with the reviewed code, version, and any stated exclusions.
The study is a six-page preprint produced jointly with the dataset publisher. Two of its authors are affiliated with ack3.
What the study does not prove
The paper also lays out several limits. It does not include a control group of protocols that were not attacked, and it does not measure how long each system was exposed to risk. Because of that, it cannot show that audited protocols are safer overall, estimate incident probabilities, or confirm that being outside audit scope was the direct cause of each loss.
The researchers also noted that some private incidents or unpublished audits may be missing, and that reported loss figures are not perfectly comparable across cases.
Its narrower conclusion is that having an audit record and having the relevant attack path covered by an audit are two different things. A reviewed smart contract does not automatically mean contract upgrades, privileged keys, front ends, relayers, oracles, cloud services, or emergency response procedures received the same level of scrutiny.
ICON Network: a failure at the boundary between reviewed components
The paper points to two incidents from August to illustrate the difference. One is the Aug. 27 replay attack on ICON Network.
According to ICON Foundation’s post-incident review, two modules in the withdrawal flow interpreted the same message differently. The migration contract used the high-order bits of a withdrawal message sequence number to determine uniqueness, while the cryptographic signature only covered the low 256 bits. By changing the high-order bits that were not included in signature validation, the attacker resubmitted two legitimately signed withdrawal messages 1,492 times in about 20 minutes. A total of 1,490 calls succeeded.
The replay attack released 119.866 million ICX and 531,600 bnUSD. When the review was published, ICON said the net loss was about 150.2 ETH plus 31,204 USDC. The foundation added that 531,600 bnUSD and 1.366 million SODA had been recovered, and that user deposits, account balances, and positions were unaffected.
ICON said the migration contract had undergone an external audit and that audit recommendations had been implemented, including changes in the same module area. The corresponding relayer logic had also received a dedicated review. Sodax development documents list eight reports covering different components, including a Sodax relayer audit from November 2025.
Even so, the postmortem said the exact mismatch between the uniqueness check and the signed value was not captured by those audit findings. In practical terms, that means a project can carry an “audited” label while users still have no clear way to know whether both ends of a withdrawal path apply the same rule for message uniqueness.
Response timing exposed a separate boundary issue
The incident also showed the limits of monitoring and response design. ICON’s first automated alert triggered at 02:08 UTC, around seven minutes after the attack started. Staff began investigating at about 03:40, paused the affected contracts at 03:53, and halted the full network at 06:18:54.
That left roughly a 90-minute gap between the first alert and full incident response. ICON attributed that to alerting changes. The rule had generated many false positives during past network connectivity failures, so it was not treated as a high-priority notification for on-call staff. The foundation said it plans to deploy an automatic shutdown trigger, lower circuit-breaker thresholds, and conduct a dedicated review of message uniqueness and replay protection.
The paper’s point is not that these controls replace audits. It is that they answer a different question: when preventive measures fail, can the system detect and isolate risk quickly?
aelf: security claims age as systems change
The August security incident involving aelf supports the same argument from another angle. Public material describes a runtime compromise and controlled recovery, but the available evidence is still not enough to map the attack path to the scope of a specific pre-incident audit.
According to the project’s public statement, an unauthorized smart contract was able to inject encoded .NET assemblies and instructions into the node execution path through transaction parameters.
An initial investigation attributed the incident to flaws in runtime reflection and dynamic loading validation, along with insufficient isolation between the contract execution environment and sensitive nodes and infrastructure resources. aelf said it identified 155 related transactions and five separate payload assemblies. Those payloads were capable of executing host commands, attempting outbound communication, accessing node keys, and conducting infrastructure reconnaissance.
The project also said that capability does not mean every payload executed successfully, nor does it mean the attacker obtained all target credentials or that sensitive data was necessarily exfiltrated. aelf said it rotated signing keys and infrastructure credentials under a potential-exposure standard.
As of Sept. 11, those findings were still provisional. The aelf website’s blog had not published a dedicated follow-up update on the incident after Aug. 26, even though the Aug. 26 notice said more updates and a final postmortem would follow.
aelf’s technical security documentation says its blockchain and ELF token contracts went through multiple audits and that no security issues were found. But based on current public pages, there is still no clear way to connect the August attack’s runtime path to a specific audit report published before the incident. For that reason, the paper says there is not enough evidence to classify the case as either an audit failure or an out-of-scope failure.
The paper’s practical takeaway
The study does not argue that audits are useless. Its argument is narrower and more operational. Audit claims need to match the actual work performed, and they need to stay tied to the system that is running now rather than the one that existed when a report was issued.
The researchers argue that users need versioned security records showing what repository and code commit were reviewed, which contract addresses were deployed, which components were excluded, what privileged roles and dependencies existed, and what changed after the audit. That record should also cover contract upgrades, key custody and rotation, runtime isolation strategy, alerting and circuit-breaker mechanisms, and time-stamped recovery status that separates confirmed losses, frozen assets, and unresolved exposure.
The broader message is simple. An audit badge cannot answer whether the reviewed component, the deployed system, and the project’s failure-response mechanisms still sit inside the same security boundary.
