In decentralized finance, “audited” is often presented as a verdict on an entire project. In practice, an audit usually covers named code, components and versions at a particular point in time. Anything added, excluded or operated around that boundary may carry a different level of assurance.
A new preprint puts a number on that gap. Researchers affiliated with security company ack3 and the Czech Technical University in Prague examined 135 reported incidents from the first half of 2026, with $939.86 million in attributed losses. They found identifiable public pre-incident audits for 68 incidents.
Within that 68-incident subset, the authors classified 46 attack paths as outside every audit scope they could identify, 20 as inside at least one scope and two as unresolved. The outside-scope group represented 67.6% of the incidents but 94.4% of their reported losses.
That striking percentage is not an estimate of audit effectiveness or proof that an audit’s boundaries caused a loss. It describes the distribution of losses in a selected set of reported incidents. Two large cases also dominate it: after excluding $292 million at Kelp DAO and $285 million at Drift Protocol, the outside-scope share falls to 72.1% of losses in the same audited-incident subset.
Even with those limits, the study exposes a basic assurance problem. A project may truthfully say it was audited while leaving users unable to tell whether the live system, the path holding their funds and the controls around it were reviewed.
What the data actually shows
The ack3 dataset covers incidents from Jan. 1 through June 29. Its 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 neither group appears in the 68-incident scope calculation.
For that 68-incident group, outside-scope incidents accounted for $680.97 million of $721.24 million in reported losses, producing the 94.4% figure. Removing Kelp DAO and Drift Protocol left $103.97 million of $144.24 million outside scope, or 72.1%. The machine-readable ledger reproduces the bucket counts and loss sums.
The inside-or-outside labels remain the researchers’ judgments about public evidence. They searched project and auditor archives, located pre-incident reports and compared the eventual attack paths with reviewed code, versions and exclusions. The work is a six-page preprint produced with the dataset publisher, and two authors are affiliated with ack3, which sells security reviews.
The study also lacks an unexploited comparison group and a measure of how long each system was exposed. It cannot establish whether audited protocols are safer overall, estimate incident probability or show that falling outside scope caused each loss. Undisclosed audits and private incidents may be missing, while reported loss figures are not perfectly comparable.
The study therefore supports a limited conclusion: audit history and audit scope are different variables. A reviewed smart contract does not automatically confer the same assurance on an upgrade, privileged key, front end, relayer, oracle, cloud service or incident-response process.
Two incidents from August illustrate that distinction in different ways. ICON Network provides a direct example of reviewed code failing at the boundary between two checks. The August aelf incident provides a contrasting case because the available audit evidence cannot yet be tied to its reported runtime path.
In ICON Network’s Aug. 27 replay exploit, two parts of a withdrawal path interpreted the same message differently.
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 whether it was unique. The cryptographic signature covered only the low 256 bits. By changing the unsigned high bits, an attacker resubmitted two legitimately signed withdrawal messages 1,492 times over about 20 minutes. ICON said 1,490 calls succeeded.
The audited boundary ICON missed
The replays released 119.866 million ICX and 531,600 bnUSD. At the time of the postmortem, ICON put the confirmed net loss at about 150.2 ETH plus 31,204 USDC. It said 531,600 bnUSD and 1.366 million SODA had been recovered and that 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 also said the relevant relay logic received a dedicated review. The SODAX audit archive lists eight reports across different components, including a November 2025 relay audit.
Yet the postmortem said the precise mismatch between the uniqueness check and the signed value fell outside those findings. A project-level badge could not tell a user whether both ends of the withdrawal path agreed on what made a message unique.
The response timeline adds a second kind of boundary. ICON’s first automated alert fired at 02:08 UTC, about seven minutes after the exploit began. Staff opened an investigation around 03:40, paused the affected contract at 03:53 and halted the network at 06:18:54.
ICON attributed the roughly 90-minute gap between the first alert and a full incident response to alert tuning. The alert class had produced false positives during unrelated connectivity incidents and did not page the on-call team at the needed severity. The foundation said it planned an automatic shutdown trigger, lower circuit-breaker thresholds and a follow-up review focused on message uniqueness and replay guards.
Those controls do not replace an audit. They provide evidence for a different question: when prevention fails, how quickly can detection become containment?
| Public assurance | The question users still need answered |
|---|---|
| “Audited” | Which repository, commit, deployed address and component were reviewed? |
| “Findings fixed” | Were the fixes deployed, and what changed afterward? |
| “Monitored” | Which alerts page a human or stop the affected path automatically? |
| “Funds recovered” | Which assets are confirmed recovered, frozen, exposed or still under investigation? |
aelf shows why assurance must stay current
aelf’s August incident tests the argument from another direction. Its public record describes a runtime compromise and a controlled recovery, but it does not provide enough evidence to place the path inside or outside a specific pre-incident audit.
The company announced a network pause on Aug. 18. In its Aug. 26 progress update, aelf said an unauthorized smart contract could use transaction parameters to deliver encoded .NET assemblies and instructions into the node execution path.
The provisional account linked the incident to gaps in checks for runtime reflection and dynamic loading, together with weak isolation between contract execution and sensitive node or infrastructure resources. aelf identified 155 associated transactions and five unique payload assemblies with capabilities including host command execution, attempted outbound communication, node-key access and infrastructure reconnaissance.
Capability is not the same as confirmed execution. aelf said the payloads did not prove that every assembly ran, that every targeted credential was obtained or that sensitive data left its systems. The company said it was rotating signing keys and infrastructure credentials under a potential-exposure standard.
The public status remained provisional on Sept. 11: aelf’s blog index contained no incident-specific item published after Aug. 26. The Aug. 26 statement committed to another update and an eventual final review.
aelf’s standing security documentation says its blockchain and ELF token contracts underwent multiple audits with no security issues identified. But the available pages do not connect a specific pre-incident report to the runtime path described in August. Calling the incident either an audit miss or an outside-scope failure would therefore outrun the evidence.
That uncertainty is itself useful. A dated audit history can become detached from a system’s current code, dependencies and operational state. Users need an assurance record that is versioned and specific enough to reveal that drift.
Such a record should name the reviewed repository and commit, deployed addresses, excluded components, privileged roles and dependencies. It should also record upgrades since review, key custody and rotation, runtime isolation, alert and circuit-breaker behavior, and dated recovery status that separates confirmed loss from frozen or unresolved exposure.
This does not reduce the value of an audit. It makes the claim proportional to the work performed and connects that work to the system operating now.
An audit badge cannot answer whether the reviewed artifact, the deployed system and the machinery that responds to failure still share the same security boundary.
Be the first to comment