Infrastructure attacks and code exploits are two distinct categories of security risk: the former targets Private Key management, multisig signing workflows, and frontend domains — the support systems outside the contract itself — while the latter is a flaw in the Smart Contract logic. Their attack surfaces, defense tools, and traceable signals are entirely different.
This distinction matters because the industry has spent the past decade pouring security resources heavily into code audits, yet TRM Labs' data shows the true source of massive losses is the infrastructure layer — revealing a clear mismatch between where resources go and where the real risk actually comes from, one that needs to be named before it can be corrected.
Breaking down the actual numbers: in 2025, infrastructure attacks totaled 45 incidents and $2.2 billion in losses (76% of the total, averaging $48.5 million per incident); code exploits totaled 52 incidents and $350 million (12.1%, averaging $6.7 million per incident); protocol attacks totaled 25 incidents and $277 million (9.6%, averaging $11.1 million per incident). The most frequent category is not the most costly category — that inversion is the point.
The practical takeaway is this: when assessing a protocol or exchange's security, don't stop at "has it been audited" — also ask how private keys are managed, what the multisig threshold is, who the signers are, and whether the frontend has ever been hijacked. None of these appear in an audit report, but they're exactly where the massive 2025 losses actually came from, and they deserve equal attention.
Ask anyone familiar with crypto what the biggest security risk is, and most answers will circle around smart contracts: reentrancy attacks, Flash Loan manipulation, edge cases that audits missed. That instinct isn't baseless — there have been plenty of high-profile contract exploits over the years. But TRM Labs' 2026 Crypto Crime Report lays out a different ranking once you look at the actual numbers.
Across all of 2025, infrastructure attacks caused $2.2 billion in losses — 76% of total losses for the year — across 45 incidents, averaging $48.5 million per incident. Code exploits, by contrast, were the most frequent category at 52 incidents, but caused only $350 million in losses, just 12.1% of the total, averaging $6.7 million per incident. Protocol attacks accounted for 25 incidents and $277 million, or 9.6%, averaging $11.1 million per incident. In other words: code exploits happen most often, but infrastructure attacks are what's actually moving the bulk of the money out — with more than seven times the damage per incident compared to code exploits.
A code exploit is a flaw in the Smart Contract logic itself — exactly what audits, Formal Verification, and bug bounties are built to catch, and what the industry has spent the most resources defending over the past decade. An infrastructure attack is something else entirely: it doesn't target contract logic, it targets the layer outside the contract that keeps the whole system running — Private Key management, multisig signing workflows, frontend domains and DNS, cloud service accounts, employee devices and permissions, signing servers. These pieces are rarely written into smart contract code, audit reports almost never cover them, yet they're the entry point attackers have most frequently and most successfully targeted in recent years.
This gap persists partly because "audited" has become shorthand for "safe." A protocol announcing it passed three separate audit firms sounds reassuring, but audit scope almost never extends to how private keys are stored, how secure employee devices are, or who has access to frontend servers. That creates a resource-allocation mismatch: protocols pour most of their security budget into audits and code review, while relatively little goes into signing-process hygiene and internal access management — precisely the area attackers have actually been exploiting.
For anyone using onchain data to assess risk, this means "is this protocol safe" can't be answered by checking whether it has an audit report alone. A few infrastructure-layer signals matter too: whether multisig signers are overly concentrated among a small group, whether the multisig threshold is reasonably set, whether the team has publicly documented its internal security processes (how signing servers are isolated, for example), and whether the frontend domain has any history of hijacking or phishing incidents. None of these show up in a code audit report, but onchain multisig transaction history, domain registration records, and historical incident disclosures can offer indirect clues. Treating "passed audit" as synonymous with "secure" is precisely the misconception this data set out to correct.