The firm's data is brutal in its specifics: 94.4% of exploits in the quarter originated outside of audited smart contract code. I've been watching this pattern stack up across years of post-mortems, and the figure isn't a surprise; it's a confession from the industry.
The Certificate Is Not the System
An audit reviews Solidity, Move, or whatever dialect the protocol speaks. It does not, by design, cover the off-chain key management that ultimately moves funds. It does not review the oracle configuration that prices liquidations. It does not examine the frontend pipeline that serves the interface, or the DNS records that resolve it, or the cloud console where the deployer key lives.
I've watched this gap claim protocols that published gleaming audit reports six weeks before collapse. The attacker walks through the operational door every time—the compromised admin multisig, the upgrade function called outside the timelock, the oracle feed that was "temporarily" swapped at 3 a.m. The audit certificate becomes a marketing artifact while the actual attack surface sits untouched.
This week's MOKE token incident on BNB Chain, where TenArmor reports an estimated $907,700 loss to a suspected smart contract exploit draining token liquidity, fits the template. I don't have the full transaction trace yet, but liquidity drains almost always route through one of two doors: flawed permission checks on the pair contract, or an oracle returning a manipulated price in a thin-liquidity window. Neither path would surface as a critical finding in a code review.
Where the Real Attack Surface Lives
So what does this mean for someone actually allocating capital, or for a developer shipping the next protocol? The uncomfortable answer is that "audited" has degraded into a marketing term. The work that determines whether a protocol survives the next quarter happens at a different layer entirely.
Take oracle configuration. How many data feeds back the price? What's the deviation threshold, and can it be adjusted by governance? Can the operator unilaterally change the feed address? Every "yes" here is an attack vector dressed as a configuration option. I've seen liquidation engines where a single signer could point the protocol at a vanity feed for fifteen minutes—plenty of time for a flash loan manipulation to print money.
Key management tells the same story. A 2-of-3 multisig with pseudonymous signers isn't security, it's a prayer. A timelock without a mandatory delay window is theater. An upgrade path that's been exercised three times in twelve months without clean governance proposals means the protocol is still in experimental mode—with your funds as the test subjects.
And then there's the frontend, which most audits never touch. The same operational paranoia that goes into hardening a WordPress installation against subdomain takeover—from registrar-level two-factor to locked-down hosting credentials—applies directly to the dApp surface. Attackers don't break the vault; they break the sign pointing at it.
The ACK3 report is useful precisely because it quantifies what auditors have quietly known for years: the threat model lives outside the codebase. Static review catches reentrancy, access control bugs, and arithmetic errors. It does not catch a compromised CI/CD pipeline, a social-engineered signer, or an oracle feed that was never properly diversified. When I evaluate a protocol now, the audit report is roughly 10% of my diligence. The rest is operational, and most of it isn't on the auditor's checklist at all.