Stop Budgeting Web3 Security From a Single 2024 Headline Number

If one report says 2024 Web3 losses were $2.2 billion and another says more than $2.9 billion, the fix is not choosing a favorite number.

The fix is asking what each number counted and what spending decision it quietly pushes you toward. Founders and investors need that discipline because security budgets get set from these summaries. CTOs and smart contract engineers need it because vague ecosystem stats are a bad substitute for an actual threat model. If you let one annual headline tell you where risk lives, you usually end up financing someone else's taxonomy instead of your own defenses.

Establish the problem with technical depth

Start with the incidents, not the leaderboard.

First, Chainalysis cites DMM Bitcoin's May 2024 loss at 4,502.9 BTC, about $305 million at the time. From one angle, that is a centralized-custody incident and belongs in a CEX risk bucket. From another, it is a key-management and transaction-authorization problem, which means it belongs in the same family of failures as many onchain admin compromises.

Second, PlayDapp's April 1, 2024 post-mortem says attackers stole an administrator's private key through a spoofed exchange email, changed mint and ownership permissions, and minted 200 million PLA on February 9 plus another 1.59 billion PLA on February 12. Hacken's report spotlights the incident as a roughly $290 million gaming and access-control event. That is directionally right, but it still hides the deeper budgeting question: was this mostly a wallet-security problem, an email-security problem, a role-design problem, or a smart-contract permission model problem? The honest answer is yes.

That is why denominators matter. DMM and PlayDapp do not live in the same product category, but they both involve permission to move or mint high-value assets being hijacked through a path above normal user logic. If your internal security budget splits teams and controls by vendor leaderboard instead of by failure surface, those incidents land too far apart from each other.

Now step back to the annual reports. Chainalysis wrote on December 19, 2024 that $2.2 billion was stolen from crypto platforms in 2024 across 303 incidents, up 21.07% year over year. Hacken's 2024 security report says losses exceeded $2.9 billion across DeFi, CeFi, gaming, and metaverse platforms, with access control accounting for 75% of all crypto hacks and phishing adding another $600 million in damage. Those are not two versions of the same table. They are two different views of what counts as the relevant security year, and therefore two different prompts for how a team should spend money.

The mechanism, the mistake, the misunderstanding

The mechanism behind these report disagreements is mostly methodological.

Some reports focus on hacked platforms and stolen funds. Others include a wider universe of losses across DeFi, CeFi, gaming, metaverse, phishing, and rug-pull-adjacent activity. Some classify by victim type. Some classify by exploit technique. Some emphasize compromise vector. Others emphasize where the loss appeared.

That makes category comparisons dangerous when performed like cocktail-party trivia. A board member reads that "private key compromises were 43.8% of stolen crypto." Another reads that "access control caused 75% of hacks." A product lead hears that phishing alone caused $600 million in damage. All three statements can be true. None is safe to treat as a direct budget formula.

The mistake is not using the data. The mistake is pretending that one ecosystem report has already normalized the data well enough for your company-specific decisions. It has not. Annual reports are useful compression. They are not your security architecture.

The misunderstanding underneath that mistake is subtler. Teams think the right question is "which category was biggest?" The better question is "which controllable failure surface is being described, even when different researchers use different words?" Private key theft, compromised admin permissions, signer UI mismatch, privileged mint authority abuse, and phishing-enabled operational compromise are not independent universes. They are connected trust paths. If your taxonomy does not join them up, your controls will not either.

This is also why first-party incident reports matter more than annual charts when you are translating trends into action. PlayDapp's post-mortem tells you the attacker got in through a spoofed email, remote access tooling, and a stolen administrator key. That is a cleaner control-design input than "gaming lost $290 million." DMM's outflow tells you one compromised authorization path can erase hundreds of millions from a centralized service. That is a cleaner budget input than "centralized services were primary targets in Q2 and Q3."

What good looks like

Good looks like doing your own normalization before you do your own spending.

• Ask what the report counts. Is it theft from hacked services only, or does it include scams, phishing, and other fraud categories? Does it cover only DeFi, or CeFi and gaming as well? If you cannot answer that, you do not know what the total actually means.
• Ask how the same incident would look under your own taxonomy. Would PlayDapp sit under wallet security, role design, phishing resilience, or privileged onchain operations? The right answer can be more than one, but you should know which control owner gets the first escalation.
• Pair aggregate reports with original incident writeups before setting priorities. Read the first-party disclosure, not just the yearly summary. Annual reports tell you that a pattern is common. The post-mortem tells you what actually failed under production conditions.
• Budget by blast radius and controllability together. A category with fewer incidents but larger single-event losses may deserve more spend than a noisier category with smaller downside. That is why DMM-scale custody failures and PlayDapp-scale permission failures belong in executive review, even if they do not dominate the same leaderboard.
• Maintain one internal failure-surface map that every incoming report must be translated into. For most teams that means some version of: custody and signer integrity, privileged onchain roles and upgrades, contract logic and invariants, and external-input integrity such as oracle or market data. If a vendor category cannot map cleanly into one of those, keep refining until it can.

Founders and boards should then ask a much better question than "what was the biggest category in 2024?" Ask: "which exact class of mistake would produce our own DMM or PlayDapp?" CTOs should ask the engineering version of the same question: "which roles, keys, interfaces, and workflows in our stack can still mint, drain, or reconfigure value faster than we can detect and stop them?"

That is when industry reporting stops being content and starts being control design.

ChainShield's angle

ChainShield's view is that yearly Web3 security reports are intake material, not policy.

We care about what the report forces the team to normalize. If one source says "centralized services" and another says "access control," we do not stop at the label. We ask which human approvals, machine boundaries, or onchain permissions actually moved the money. If one incident sits in "gaming" and another in "exchange," but both start with stolen authority over a critical asset path, they should influence the same control conversations.

That is the practical shift we want teams to make. Stop budgeting from the most convenient annual headline. Start translating every external report into the small set of failure surfaces your org can actually own. That is how a report becomes useful to engineering, useful to finance, and useful to governance at the same time.

The better question after any annual security report is not "which number was correct?" It is "what did different measurement frames keep rediscovering anyway?" That is the question more teams should bring into the next board meeting, the next budget cycle, and the next release review.