Security · Developing
The Cause Is Still Unknown. The Label Went Up Anyway
Aquifer lost roughly $2.5 million on Sunday, and no one has established how. The incident database that feeds the industry's loss statistics had already filed a mechanism against it — and it had an "Unknown" bucket available that it chose not to use.
Aquifer, an automated market maker on Solana, lost about $2.5 million over the weekend. That much is agreed. Almost nothing else about the incident is.
The attack was flagged on Aug. 31 by Defimon, a blockchain security monitoring service, which identified addresses on both Solana and Ethereum holding the moved assets. Aquifer has since posted an on-chain whitehat offer: return at least 80% of the assets by Sept. 3 at 14:00 UTC, keep 20%, and the protocol will not pursue civil claims. As crypto.news noted in its report, that promise binds Aquifer and nobody else — it has no effect on law enforcement or government agencies, who were not party to the offer and are not bound by it.
What is missing is the part that usually arrives first in a story like this: an explanation. Aquifer has not published a technical post-mortem. No security firm has published a transaction-level teardown. crypto.news, reporting on Monday, put it plainly: available information has not established that Aquifer's smart contracts were exploited, and compromised wallet access remains the main focus of the incident so far. Whether that compromise came through private keys, administrator credentials, or some piece of operational infrastructure is unconfirmed.
The label that arrived before the answer
DefiLlama's hacks database — the closest thing the sector has to a public system of record, and the source that a great many "$X billion lost this year" charts are built on — does not record Aquifer as unexplained. This desk queried its API directly on Monday. The entry reads: Aquifer, Aug. 31, 2026, $2,469,729, chain Solana, classification Access Control, technique Arbitrary External Call.
"Arbitrary external call" is not a vague description. It is a specific smart-contract flaw: a contract that lets a caller specify a destination and payload, and then makes that call with the contract's own authority. It is a bug in code. It is the kind of finding that comes out of reading a diff, not out of watching funds move.
So the database asserts a contract-level mechanism for an incident where, according to the only substantive reporting available, no one has established that the contracts were involved at all.
The obvious defence is that these are working labels — provisional, revised later, not meant to be read as findings. That defence would be stronger if the database lacked a way to say so. It doesn't.
Eight incidents, four days — as filed
| Protocol | Date | Amount | Technique as filed |
|---|---|---|---|
| MORE Markets | Aug 31 | $9,300,000 | Borrow Logic Flaw |
| Aquifer | Aug 31 | $2,469,729 | Arbitrary External Call |
| Float Protocol | Aug 31 | $28,000 | Spot Price Manipulation |
| Balancer V1 | Aug 30 | $234,000 | Rounding Error |
| Tectonic | Aug 30 | $75,000,000 | Spot Price Manipulation |
| Full Sail | Aug 29 | not recorded | Oracle Misconfiguration |
| Permapod | Aug 29 | not recorded | Unknown |
| Ajna V2 | Aug 28 | $775,400 | Liquidation Logic Flaw |
That is the point. Two days before the Aquifer entry, the same database filed Permapod's incident with a technique of "Unknown." The vocabulary for uncertainty exists and is in active use. Aquifer got a mechanism instead.
Why a working label stops being provisional
Incident databases are not neutral archives. They are the substrate for nearly every aggregate claim the sector makes about itself — the quarterly loss totals, the pie charts splitting "oracle manipulation" from "access control," the arguments about whether audits are working. Those aggregates are assembled by counting labels. Nobody re-reads the underlying incidents when building the annual chart; they read the column.
Which means a provisional label has a way of hardening. It gets counted once, and then the count gets cited, and the citation outlives whatever caveat sat next to the original entry. If Aquifer's loss turns out to have started with a stolen key on a laptop, the industry's 2026 tally may still carry $2.47 million in the smart-contract column — and the conclusions drawn from that column will be off by exactly that much, in a direction that flatters key management and blames code.
We flagged the same dynamic last week from the other direction. August's losses, as counted by CertiK, put only $20.6 million against code vulnerabilities out of roughly $215 million total — the overwhelming majority came from oracle manipulation and governance capture, not from bugs an audit would catch. That finding is only as good as the classifications underneath it. Every misfiled row moves the conclusion.
What is actually known
Very little, and it is worth being precise about the boundary. Confirmed: roughly $2.5 million moved out of Aquifer around Aug. 31; Defimon identified the receiving addresses on Solana and Ethereum; Aquifer has made a public whitehat offer with a Sept. 3 deadline and a 20% retention. crypto.news reported Aquifer's total value locked at about $2.8 million per DefiLlama, though the snapshot date for that figure is not stated, and TVL measured after an incident is not the same number as TVL measured before one.
Not confirmed: how the attacker got in. Whether the contracts were touched. Whether a key was stolen, a credential phished, or a deployment pipeline compromised. Whether the funds are recoverable. Whether anyone will take the bounty.
Those are seven open questions and one mechanism label, and the label is currently winning.
The Take
None of this makes DefiLlama the villain — it is a free public good, maintained fast, under no obligation to wait for a post-mortem that may never come, and it deserves credit for having an "Unknown" category at all. The failure is downstream, in how the rest of us read it. A technique column is a hypothesis with the hedging stripped out, and the sector treats it as a finding because a finding is easier to chart. If you are building a statistic on that column, the honest version has an error bar wide enough to include "we do not know," and for a meaningful share of rows it should. Until Aquifer publishes a post-mortem, the correct entry for this incident is the one the database already knows how to write.