Audits only examine parts of the code and cannot endorse the security of the entire DeFi project.

Written by: Liam 'Akiba' Wright

Translated by: Chopper, Foresight News

In the decentralized finance sector, "audited" is often viewed as an endorsement of the entire project's security. However, audits usually only cover specific points in time, designated code, components, and versions. Any additions, deletions, or modifications made outside this scope may yield completely different audit results.

A new preprint paper provides concrete numbers highlighting this gap. Security company ack3, along with relevant researchers from the Czech Technical University in Prague, analyzed 135 reported security incidents from the first half of 2026, resulting in losses of up to $939.86 million. They found that 68 of these incidents had identifiable public pre-audit records.

In the sample of these 68 incidents, researchers classified 46 attack paths as completely outside any traceable audit scope; 20 incidents were covered by at least one audit; and the remaining 2 could not be determined. Incidents outside the audit scope accounted for 67.6% of the total incidents, while the corresponding loss amount represented 94.4% of the reported total losses.

This astonishing ratio is not an evaluation of audit effectiveness, nor is it evidence that limited audit scopes directly lead to losses. It merely represents the loss distribution within the selected sample of public security incidents. Two major incidents greatly influenced the data: after excluding Kelp DAO's $292 million loss and Drift Protocol's $285 million loss, the proportion of losses from attacks outside the audit scope within the same audited sample dropped to 72.1%.

Even with the aforementioned limitations, this study reveals a fundamental security trust issue: a project claims to have been audited, yet users cannot ascertain whether the operating system, fund flows, and related control measures have actually undergone review.

The True Meaning of the Data

ack3's study covers from January 1 to June 29, 2026, a total of 122 confirmed attack incidents and 13 suspected incidents. In the entire sample, 35 incidents were found without any audit records, and 32 had unknown audit histories; these two categories are excluded from the aforementioned count of 68 incidents.

In the sample of 68 incidents, events outside the audit scope corresponded to losses of $680.97 million, with total losses amounting to $721.24 million, thus establishing the figure of 94.4%. After excluding Kelp DAO and Drift Protocol, the losses outside the audit scope amount to $103.97 million, with total losses of $144.24 million, resulting in a proportion of 72.1%. The dataset json file can reproduce the incident classification count and loss amounts.

The "in audit scope / out of audit scope" labels are judgments made by researchers based on public evidence. The research team reviewed project and audit firm archives to find the audit reports prior to the attacks, comparing the final attack paths with the audited code, versions, and excluded items. This study is a 6-page preprint paper created in collaboration with the dataset publisher, and the two authors are affiliated with the security auditing company ack3.

The research lacks a control group of systems that were not attacked, and it does not track the duration of each system's exposure to risk. Therefore, it cannot prove that audited protocols are overall more secure, cannot estimate the probability of incidents occurring, and cannot confirm that being "outside the audit scope" is the direct cause of each loss. Some undisclosed audits and private incidents may be missing, and the reported loss data may not be fully comparable.

Thus, the study can only draw limited conclusions: audit records and audit coverage are two independent indicators. An audited smart contract does not imply that contract upgrades, privileged keys, front ends, relays, oracles, cloud services, or emergency response processes receive the same level of security guarantees.

Two incidents in August corroborated this distinction from different angles. The ICON Network case intuitively demonstrated that two segments of reviewed code failed at the boundaries of two validation steps; while the August aelf security incident presented a different scenario where existing audit evidence could not correlate the attack execution path to the pre-audit scope.

ICON Network: A Case of Failure at Audit Boundaries

In the replay attack on ICON Network on August 27, the two modules in the withdrawal link interpreted the same message differently.

According to the post-mortem report by the ICON Foundation: the migration contract relied on the high-order bits of the withdrawal message sequence number to determine whether the message was unique; but the cryptographic signature only covered the lower 256 bits of the sequence number. The attacker modified the high-order bits that were not included in the signature check, successfully resubmitting two legally signed withdrawal messages 1492 times over approximately 20 minutes, with 1490 of those calls executing successfully.

This replay attack released 119.866 million ICX and 531,600 bnUSD. At the time of the post-mortem release, ICON confirmed a net loss of approximately 150.2 ETH plus 31,204 USDC. The foundation stated that the 531,600 bnUSD and 1.366 million SODA assets had been recovered, and user deposits, account balances, and positions were unaffected.

ICON stated that this migration contract had undergone external audits and implemented audit recommendations, including relevant modifications in the same module area; the corresponding relay logic had also undergone a separate review. The Sodax development documentation audit list contains 8 reports covering different components, including the Sodax relay audit report from November 2025.

However, the post-mortem report clearly stated that the uniqueness check logic and the signature verification value mismatch was not within the findings of the aforementioned audits. A simple "audited" project label cannot inform users whether both ends of the withdrawal link maintain consistent standards for determining "message uniqueness."

The response timeline also revealed another type of boundary issue. The first automated alarm at ICON triggered at 02:08 UTC, approximately 7 minutes after the attack began. Staff initiated an investigation around 03:40 and suspended the affected contract at 03:53, then suspended the entire network at 06:18:54.

There was approximately a 90-minute interval from the first alarm to complete emergency response. ICON attributed this to adjustments in the alarm mechanism, as this alarm rule had generated a large number of false positives in past network connectivity failures, so it wasn't prioritized for immediate notification of on-duty personnel. The foundation plans to deploy an automatic shutdown trigger mechanism, lower the circuit-breaker threshold, and conduct a special review on message uniqueness and replay protection.

These risk control mechanisms cannot replace audits, but they do answer another critical question: when preventive measures fail, can the system quickly detect and isolate risks?

Security questions users still need clear answers to

aelf: Security Assurance Needs Ongoing Updates

The security incident at aelf in August further corroborates the aforementioned viewpoint from another perspective. Public information describes the occurrence of runtime infiltration and controllable recovery, but existing evidence is insufficient to determine whether the attack path fell within the pre-specified audit scope.

The project's official announcement explains: there was an unauthorized smart contract that could inject encoded .NET assemblies and instructions into the node execution chain using transaction parameters.

The preliminary investigation report attributed the incident to flaws in runtime reflection and dynamic loading verification, as well as insufficient isolation between the contract execution environment and sensitive nodes, as well as infrastructure resources. aelf identified a total of 155 relevant transactions, 5 independent payload assemblies, with capabilities to execute host commands, attempt external communication, access node keys, and conduct infrastructure reconnaissance.

Having such capabilities does not confirm the successful execution of all payloads, nor does it imply that the attacker obtained all target credentials or that sensitive data was leaked. aelf stated that they have rotated signature keys and infrastructure credentials according to potential leak standards.

As of September 11, this conclusion remains a provisional judgment. aelf's official blog has not published any specific updates regarding this incident since August 26. The August 26 announcement promised subsequent updates and a final post-mortem.

aelf's technical security documentation states that its blockchain and ELF token contracts have undergone multiple rounds of audits and found no security issues. However, the existing public page cannot correlate the runtime path of the August attack with any specific audit report prior to the incident. Therefore, characterizing the incident as an audit oversight or an out-of-scope failure lacks sufficient evidence to support.

This uncertainty itself is of reference significance. An audit report that is timestamped will gradually become disconnected from the current system code, dependency libraries, and actual operational status. Users need a versioned security record to reflect this difference.

This security record should clearly state: the reviewed repository and code submission version, deployed contract address, excluded components, privileged roles, and dependency libraries; while also documenting post-audit contract upgrades, key management and rotation mechanisms, runtime isolation strategies, alarm and circuit breaker mechanisms, as well as timestamped asset recovery statuses, distinguishing confirmed losses, frozen assets, and unresolved risk exposures.

This does not negate the value of audits; rather, it aligns audit communication with actual work content and relates it to the currently operating system.

A single audit badge cannot answer: whether the audited components, deployed systems, and mechanisms for handling failures still fall within the same security boundary.