If code audits have gotten so good, why haven't hack losses gone down?
Audits have genuinely made "finding code bugs" harder, which is part of why code vulnerabilities now account for only about a tenth of losses. But attackers haven't given up — they've simply redirected resources toward higher-return targets: people and processes. An audit can check whether a piece of code logic is correct, but it can't check whether a developer's laptop might get a malicious script planted on it, or whether a multisig signer can be talked into approving a transaction that looks routine. As the code-level defense gets stronger, attackers naturally move to wherever the defense is weaker.
That's also why total losses ($1.31 billion) haven't meaningfully dropped as auditing has become standard — defense improved in one area, so attackers simply shifted to another.
Why is an attack like Drift Protocol's — six months in the making — so hard to defend against?
Because this kind of attack doesn't exploit a technical flaw; it exploits trust-building, a normal and necessary part of doing business. The attackers posed as a quantitative trading firm, built genuine-seeming professional relationships with contributors at conferences, and even deposited over $1 million to earn the team's confidence — all of which is, on its face, entirely legitimate and nearly indistinguishable from a real business partner. Only once trust was established and contributors' guard was down did the actual attack actions appear: cloning a malicious code repository, or testing a disguised app.
For defenders, this means technical detection alone (scanning for malicious code) isn't enough. Teams also need some level of verification and risk diversification around newly formed business relationships — for instance, not letting a single external contact gain both code repository access and governance signing privileges.
What practical value does this data have for an ordinary retail investor?
The most direct value is recalibrating what "safe" actually means. In the past, an investor might ask whether a project has an audit report. Now the more useful questions are operational: what's the team's multisig threshold, is there a mandatory timelock, is development access concentrated in a few hands or properly distributed, and has the team ever publicly explained how it manages internal access credentials.
These questions rarely appear in most audit reports, yet they're exactly where the real breach points in incidents like Drift Protocol and Kelp DAO turned out to be.
Will this trend continue? Can defenders turn it around?
In the near term, this trend will likely continue, because the underlying economic incentive hasn't changed — as long as attacking people is more cost-effective than attacking code, rational attackers will keep allocating resources that way. But that doesn't mean defenders are powerless. Reports like CertiK's and TRM Labs' are themselves part of the defensive response: quantifying and publicizing attack patterns helps teams reallocate resources from pure code audits toward governance process review, Key Ceremony discipline, and ongoing monitoring of contributor devices and external contacts.
For the industry to genuinely reverse this trend, the key isn't running one more audit — it's elevating operational security to the same priority level as code security.
If you assumed that hackers targeting crypto projects mostly work by finding bugs in Smart Contract code, the numbers from H1 2026 will make you rethink that. According to CertiK's Hack3d H1 2026 report, the industry lost more than $1.31 billion to security incidents in the first half of the year — but attacks from traditional code vulnerabilities accounted for only about $151.6 million of that, spread across 204 incidents. That's the highest incident count of any category, yet it represents just over a tenth of total losses. The real money went to wallet and privileged-access compromise: just 33 incidents, but $444.5 million stolen — an average of $13 million per event, the highest average loss of any attack category. Close behind was phishing and social engineering, with 63 incidents causing $366.3 million in losses.
There's a clear economic logic behind this shift. Smart contract auditing has matured rapidly over the past few years — mainstream protocols now routinely go through one or more rounds of smart contract audits before launch, making obvious code vulnerabilities harder to find. CertiK CEO Ronghui Gu put it bluntly: why spend months hunting for an obscure reentrancy bug when you can instead target a developer with elevated cloud access — something that might take only weeks of social engineering to set up, but can net hundreds of millions in a single strike. TRM Labs' report covering the same period showed a similar pattern: 76% of all crypto stolen in 2025 (roughly $2.2 billion) came from infrastructure attacks rather than traditional smart contract exploits. Incident counts were cut roughly in half, from 410 in 2024 to about 200 in 2025, while average losses per incident more than doubled — from around $5 million to nearly $15 million. Hackers are doing less, but each strike is more precise and more devastating.
The two largest incidents of H1 2026 were not, in the traditional sense, cases of "a bug being found in the code." Kelp DAO's $292 million Cross-Chain Bridge incident in April stemmed from failures in the bridge's operational and verification processes, not a single flawed function in a smart contract. Even more illustrative is the $285 million Drift Protocol incident that happened around the same time. Attackers spent nearly six months on the operation, starting in fall 2025 by approaching Drift contributors at crypto conferences while posing as a quantitative trading firm — building trust, opening a vault, and holding what looked like ordinary integration discussions. The operation culminated in convincing one contributor to clone a code repository weaponized with a malicious VS Code task file, and persuading another to beta-test a disguised wallet app via Apple TestFlight. The actual withdrawal — 31 transactions — took roughly 12 minutes to execute. The social engineering that made it possible took nearly six months. Combined, these two incidents alone total more than $570 million, and neither involved a single line of "vulnerable smart contract code" to point to.
Notably, phishing attacks dropped from 132 incidents to 63 — nearly cut in half — yet losses fell only about 10.8%. CertiK's report found that just four social-engineering operations accounted for $310 million, about 85% of all phishing losses. In other words, attackers have stopped casting wide nets for small-dollar scams against ordinary users, and instead concentrate resources on a handful of high-value targets, where a single successful strike can net tens of millions. That's a departure from the old stereotype of a "phishing website": today's adversaries are often organized, patient operations willing to spend months cultivating a single target — and a significant share have been traced to North Korean state-sponsored groups.
If your security posture still runs on the assumption that "audited means safe," these numbers are a wake-up call. The signers behind a multi-signature wallet, developers holding deployment privileges, and cloud infrastructure access credentials have overtaken smart contract code as attackers' highest-return targets. That means defensive priorities need to shift too: an audit report alone isn't enough. Teams need rigorous key ceremony discipline, vigilance around timelocks and multi-party approval in governance processes, healthy suspicion toward any signing request involving privilege changes that "looks routine," and continuous monitoring of contributor devices and development environments.
If you hold assets in a DeFi protocol or exchange, "has this project been audited" is no longer the only question worth asking. Just as important: how high is this team's multisig threshold set? Are governance proposals subject to a mandatory timelock? Has the team ever disclosed how it manages internal privileged access? These operational details often predict whether a project becomes the next Drift Protocol far better than the technical details in an audit report ever could.