The headline is neat: 65,340 risky crypto addresses, $574.8 million in losses. But neat numbers hide messy truths. I didn't need to read the USENIX Security '26 paper to know that the bulk of that figure is noise—the cumulative effect of a decade of developer sloppiness, not active exploitation. The researchers found two attack vectors that actually work today. They account for only $15.7 million of that total. The rest is a graveyard of forgotten keys and misdirected transactions.
That gap matters. In a bull market, projects love to cite aggregate risk figures to justify centralized controls. The real question is: which of these risks are active, and which are just historical artifacts? The study gives us a precise answer.
Context: The Dataset and the Disconnect
The paper, presented at USENIX Security '26, mined 63,004 GitHub repositories created between January 2015 and May 2025. It extracted 16.3 million deduplicated private keys from code commits, issue trackers, and documentation. Using transaction-pattern rules and lightweight symbolic execution on Ethereum and BNB Smart Chain, the researchers flagged 65,340 addresses that had been misused—either because they received unintended function calls or because their private keys were public.
The total native-token losses: 126,982.94 ETH and 17,726.7 BNB. At May 2025 reference prices of $4,408 per ETH and $847 per BNB, that's $574.8 million. But the two active attack vectors—the ones that an attacker can execute right now, without waiting for a user mistake—account for only 3,472.23 ETH and 465.24 BNB, or roughly $15.7 million.
That discrepancy is the bottleneck. The bottleneck wasn't the number of exposed keys—it was the attacker's ability to exploit them at scale. The study shows that most risky addresses are passive: funds sit in them because no one has bothered to deploy malicious code or the keys aren't being swept. The two active vectors change that calculus.
Core: The Two Active Vectors, Broken Down
Vector 1: Deterministic Deployment Ambush
Contract-account misuse happens when a user sends a function call—usually with ETH or BNB attached—to an address that has no contract code on the target chain. The transaction succeeds as a simple transfer; the intended function never executes. The funds sit at that address, locked until someone deploys code there.
An attacker can game this by deploying a contract on a testnet at a specific address, then waiting for users to mistakenly send funds to the corresponding address on mainnet. Because Ethereum's deterministic contract addressing means the same deployer address and nonce produce the same contract address across networks, the attacker can later deploy malicious withdrawal code at that exact location on mainnet. The paper identified 469 such malicious contracts, responsible for 3,446.37 ETH and 431.79 BNB in losses.
You don't need a PhD to see the pattern: it's a classic cross-chain collision attack, but lazy developers still use the same deployer key for testnet and mainnet. In my own audit work, I've flagged this exact vulnerability in at least three bridge projects. The fix is trivial—use separate deployer accounts—but the industry ignores it.
Vector 2: EIP-7702 Delegation Drain
Externally owned account misuse starts with a public or exposed private key. Anyone who has the key can control the account. Automated sweepers race to remove incoming funds. But EIP-7702 makes that drain more direct. An attacker can use the exposed key to delegate the account to malicious code that forwards a deposit to the attacker in the same transaction. The study found more than 17,200 delegated addresses, with losses of 25.86 ETH and 33.45 BNB.
This is the more insidious vector. EIP-7702 was designed to improve account abstraction, but it also introduces a new attack surface: once a key is exposed, the attacker can permanently delegate the account to a contract that automatically drains any incoming funds. The user doesn't have to make a mistake twice—the first leak is enough.
I've traced this behavior in the wild. A few months ago, I analyzed a wallet that had been drained three times in a week. The owner had reused a private key that was scraped from a GitHub gist. The first drain was manual; the subsequent ones were automated by a contract that had been set up via EIP-7702 delegation. The victim didn't even know they were still losing money.
Why the $574M Figure Is Misleading
Both vectors together account for only 2.7% of the total dollar amount. The rest is a collection of older, unrecoverable losses—funds sent to addresses that never had code deployed, or keys that were exposed years ago but never swept. The researchers used May 2025 reference prices, not the value at the time of loss. For a 2020 transaction, $4,408 ETH is a fiction. The actual loss at the time might have been $200 per ETH.
This is a classic error in crypto security research: inflating historical losses by applying current prices. It makes the problem look worse than it is. The bulls will argue that the study is alarmist, that the 65,340 addresses are mostly dormant, and that the two active vectors are small potatoes.
They're right, but only partly. The $15.7 million in active-vector losses is real, and it's growing. The study's precision of 99.11% for detecting misuse is impressive, but it measures detection accuracy, not causation. Not every flagged address was actively exploited—some were just sitting there, waiting for a trigger.
The real risk is that the two active vectors will scale. As more developers deploy on testnets with the same keys, and as EIP-7702 adoption grows, the number of exploitable addresses will increase. The study is a snapshot of a moving target.
Takeaway: The Industry's Accountability Gap
The researchers disclosed their findings to wallet developers and exchanges. But the paper doesn't provide a remediation rate. How many of those 65,340 addresses have been secured? How many wallet providers have added warnings for transactions to no-code or exposed-key destinations? The answer, based on my experience, is: not enough.
I've seen the same mistakes repeated across projects. Hardcoded keys in open-source repos. Testnet wallets funded with mainnet ETH. EIP-7702 delegation contracts left unchecked. The data is in. The question is: who will act?