Security researchers at Blockaid found that hackers stole more than $1 billion from crypto projects in the first half of 2026. That is the highest total the firm has recorded for that period since it started tracking the data. Ethereum and Solana projects took the biggest hits, and a separate CoinDesk analysis shows most of that money left through channels that have nothing to do with buggy code.
How much did hackers steal from crypto in H1 2026?
According to Blockaid's report, total losses from hacks, exploits and scams across the crypto industry between January and June 2026 topped $1 billion. That is the highest figure for a first half of the year since the firm began tracking this data.
The record does not rest on a single headline-grabbing breach. The total is made up of dozens of separate incidents spread across all six months, rather than one or two nine-figure hacks the way past records were often set. That spread is exactly what makes the problem harder to fix, since there is no single point of failure to patch. Attacks are hitting different parts of the industry at the same time.
Separately, CoinDesk's Crypto Long & Short column cites a slightly different figure, around $972 million for the year to date at the time of publication. The gap comes down to different counting methods and cutoff dates. But the scale matches. Losses run into hundreds of millions of dollars every month, and neither estimate shows any sign of slowing down in the second half of the year. For context, that much money could fund a dozen mid-sized crypto startups for years.
Why did Ethereum and Solana lose the most?
Ethereum projects lost $332 million, and Solana projects lost $326 million, the two biggest totals in Blockaid's report. Together the two networks accounted for more than half of everything the firm tracked for the half-year.
The reason is straightforward. Both networks host the largest number of DeFi protocols, cross-chain bridges and NFT platforms, and that is where the most assets sit. The more complex a protocol's infrastructure gets, with more admin wallets, oracles and outside integrations, the more entry points an attacker has to work with.
Bridges deserve a separate mention. By design they hold large token reserves on both sides of a connection, and any flaw in how a bridge verifies signatures opens the door to millions of dollars at once. Bridge protocols have stayed among the most targeted in the industry for years.
Other networks show up in the report too, just with much smaller totals. That does not mean they are safer by design. It more likely means they hold less money and run fewer active DeFi protocols worth attacking in the first place.
How are attackers getting past audits that already passed?
This is where the report's main point comes in. Mitchell Amador, founder of the bug bounty platform Immunefi, wrote in a CoinDesk column that most of this year's stolen funds left not because of errors in contract code, but through keys, multisig signers and DAO governance votes. Immunefi has run bug bounty programs for major protocols for years, so the conclusion is grounded in practice rather than guesswork. A project can pass a full smart contract audit and still lose funds if an attacker gets hold of an administrator's private key or convinces a signer to approve a malicious transaction.
In plain terms, an audit checks the logic of the code, not the people and processes around it. That is why "we got audited" stopped meaning "we are safe" a while ago. An auditor sees the code as developers wrote it, but not who actually holds access to a protocol's admin panel a year after launch, or whether that list changed without proper oversight.
One detail rarely makes it into public reports. Many multisig wallets formally list several signers, but in practice only two or three people from the same team actually control them. If an attacker compromises their devices at the same time, a "3 of 5" threshold stops meaning much.
Keys, signers and votes are the new main target
Blockaid and Immunefi point to roughly the same set of weak spots outside the code itself:
- Private keys: stolen through phishing, malware or leaks from cloud services
- social engineering against multisig signers, where an attacker poses as a colleague or partner
- manipulating DAO votes, which only requires temporarily gathering a controlling share of governance tokens
- compromising the frontend or wallet interface a signer uses to approve a transaction without seeing its real contents
- leaked infrastructure access, including cloud accounts, CI/CD systems and private repositories holding deployment keys
None of these vectors shows up in a standard smart contract audit report. Teams that rely on code audits alone leave exactly the part of the system attackers are now targeting unprotected. Immunefi's analysts note that attacks on access-control processes are growing faster than attacks exploiting bugs in the code itself.
What does this mean for crypto holders?
For an everyday user, the takeaway is practical. A major protocol's security no longer guarantees the safety of any single wallet or account. Hardware wallets such as Ledger reduce the risk of a leaked private key because the transaction signature happens on a separate device rather than in a browser or on a computer connected to the internet.
For protocols and teams, the advice is similar. Signers should be split up geographically and organizationally, signing requests should be verified outside the main communication channel, and admin wallet permissions should be time-limited. Transaction simulation tools help too, showing a signer exactly what a transaction will do before they approve it, not after. None of these steps replace a code audit, but they close the gap an audit was never built to see.
Blockaid's first-half data makes a simple point. The industry spends millions on code audits while losing hundreds of millions to human error and weak access controls. Until key and signer security catches up with the quality of smart contract audits, the numbers are unlikely to improve.
Comments
Your email address will not be published. Required fields are marked *