I still remember the first time I watched a friend send a sizable amount of ethereum to what looked like a perfectly normal contract address, only to realize later that nothing was actually deployed there. The funds just sat, unreachable, until someone else claimed them. That sinking feeling has stayed with me. Now a large-scale study has put hard numbers behind experiences like that, and the scale is hard to ignore.
What The Numbers Actually Reveal About Address Misuse
Recent research examining activity across Ethereum and BNB Smart Chain identified 65,340 high-risk address instances. These were not random or theoretical. They were linked to measurable losses totaling 126,982.94 ETH and 17,726.7 BNB. Using the study’s chosen reference prices of roughly $4,408 per ETH and $847 per BNB, the combined value sits above $574.8 million. That figure is presented as a conservative lower bound. It only counts native tokens and deliberately leaves out many less obvious cases involving tokens or other networks.
The researchers divided the problem into two broad types of address misuse. Understanding the difference matters because the risks and the fixes look quite different depending on which category you fall into.
Contract Account Misuse And Why It Happens So Often
Contract account misuse occurs when people treat an address that has no deployed code as if it were a functioning smart contract. This usually happens because the same address exists in a different network context. Someone might have interacted with a contract on a testnet or another chain, then later paste the identical address on mainnet without checking. The study found 49,344 such instances. They were tied to losses of 22,738.41 ETH and 8,681.41 BNB.
In my experience, this is one of the easiest mistakes to make when you are moving quickly between environments. The address looks familiar. The checksum might even match. Yet on the network where you just sent funds, the address is empty. Once the transaction confirms, the only person who can claim those funds is whoever later deploys code to that exact address. That is not a theoretical risk. Attackers have been known to watch for these situations and act on them.
The sheer volume of these cases suggests that many users still treat addresses as interchangeable across chains. They are not. A contract address is derived deterministically from the creator’s address and the nonce at the time of deployment. That same combination can produce an identical address on a completely different chain, yet the code only exists where it was actually deployed. The gap between those two realities is where the money disappears.
Externally Owned Account Misuse And The Private Key Problem
The second category covers externally owned accounts whose private keys have been exposed or that show clear on-chain signs of compromised control. Researchers identified 15,996 such instances. These accounted for the larger share of losses: 104,244.53 ETH and 9,045.29 BNB. More than 95 percent of the EOA misuse losses came from keys that had been found in public GitHub repositories.
That last detail is worth sitting with for a moment. Developers have been leaking private keys into public code for years. The study mined 63,004 GitHub repositories created between early 2015 and mid-2025. After cleaning the data they extracted 16.3 million private keys and 10.3 million unique candidate addresses. Many of those keys had already been used on-chain. Once a key is public, anyone can import it into a wallet and drain whatever arrives.
I have seen this pattern enough times to recognize the warning signs. A developer tests a script, leaves a real private key in the code by accident, pushes the repository, and never thinks about it again. Months or years later funds still flow into that address. The person who finds the key first simply waits or sweeps automatically. There is no need for sophisticated exploits when the private key itself is sitting in plain sight.
Two Newly Described Attack Paths That Add Up To Millions
Beyond the familiar categories, the research highlighted two attack methods that had not been widely documented before. Together they account for roughly $15.7 million of the measured losses when valued at the study’s reference prices.
The first method exploits the deterministic nature of contract address creation. An attacker can deploy a contract on a testnet or less monitored environment, then promote that address publicly. Users who interact with it on the wrong network send funds to an address that still has no code. Later the attacker deploys a simple withdrawal contract to the same address on the target network and takes the accumulated balance. The study linked 469 malicious contracts of this type to 3,446.37 ETH and 431.79 BNB in losses.
The second method leans on EIP-7702. This Ethereum feature allows an externally owned account to temporarily delegate control to a smart contract. When the private key of that EOA is already known, an attacker can set a malicious delegation that automatically sweeps any incoming funds. Researchers found 17,270 such cases, producing smaller but still real losses of 25.86 ETH and 33.45 BNB. The absolute numbers look modest next to the larger categories, yet the mechanism is new and still spreading.
Both techniques share a common thread. They turn ordinary user behavior or already-compromised keys into reliable collection mechanisms. No phishing email is required once the address or key is in the right hands. That is what makes them particularly hard to defend against with traditional user education alone.
How Reliable Are These Findings
The detection framework achieved 99.11 percent precision when researchers manually sampled the results. That is a strong number, yet it does not mean every single one of the 65,340 instances was individually verified by hand. The authors are clear that some heuristic false positives remain possible and that the data is incomplete by design. ERC-20 tokens, NFTs, and activity on other chains were left out of the headline loss calculation. Expanding the scope would almost certainly increase the totals.
I find the precision figure reassuring but not definitive. In security research a high precision rate on a sampled set is useful. It tells you the method is not inventing problems out of thin air. At the same time, the real-world impact can still be higher or lower depending on factors the study could not measure. The responsible reading is that the problem is large, well-documented, and still growing.
Why EIP-7702 Security Concerns Keep Expanding
Ethereum’s own guidance has already warned that malicious EIP-7702 delegations can hand hostile contract code effective control over an account’s assets. Separate analysis presented in the same research wave found that more than 63 percent of examined EIP-7702 authorization transactions were linked to malicious targeting of externally owned accounts. Across seven supported chains the researchers identified 924 malicious contract accounts involved in these patterns.
After the Pectra upgrade, reports of automated wallet-draining activity connected to these delegations began to surface. In one related case, attackers managed to drain a significant sum from users of a popular prediction market through a combination of phishing and malicious delegated execution. The details differ, but the underlying issue is the same: once an EOA has delegated control, the window for sweeping funds becomes very wide.
Perhaps the most interesting aspect is how quickly new protocol features can be turned into attack surfaces. EIP-7702 was designed to improve user experience by letting EOAs behave more like smart accounts for limited periods. That flexibility is valuable. It also creates new ways for already-compromised keys to become highly efficient collection tools. Security and convenience continue to trade places in real time.
Practical Steps That Actually Reduce Exposure
The researchers offered several concrete recommendations. Wallet software should warn users when an address is known to have had its private key exposed. Cross-chain contract mismatches should also trigger clear alerts before a transaction is signed. Developers need stronger habits around secret management. Leaving real private keys in public repositories is still far too common. Clearer documentation that distinguishes addresses by network would help ordinary users avoid the most frequent mistakes.
One longer-term idea is worth considering. Future contract address derivation schemes could incorporate a chain identifier so that the same creator and nonce produce different addresses on different networks. That change would eliminate an entire class of confusion at the protocol level. It is not a simple upgrade, and it is not currently planned, yet the data makes a strong case for exploring it.
In the meantime, individual users can take steps that cost almost nothing. Before sending any meaningful amount to a contract address, verify that code is actually present on the network you are using. Treat every address that has ever appeared in a public repository as permanently compromised. Prefer hardware wallets or multi-signature setups for anything beyond everyday spending money. And when a new protocol feature arrives that expands what an EOA can do, assume attackers will explore it faster than most users will.
The Quiet Scale Of Everyday Losses
What strikes me most about this research is how ordinary many of the losses feel. They do not require zero-day exploits or nation-state resources. They require only that people reuse addresses carelessly, that developers leave keys in public places, and that attackers remain patient. The cumulative result is hundreds of millions of dollars that will never be recovered.
I have spoken with people who lost funds this way and then spent months trying to understand what happened. The common thread is surprise. They thought they were being careful. The address looked right. The transaction confirmed. Only later did the absence of code or the presence of an unexpected controller become obvious. By then the funds were gone.
This pattern is not limited to newcomers. Experienced users make the same mistakes when they move quickly between testnets, sidechains, and mainnet. The mental model that an address is simply an address does not survive contact with how blockchain addressing actually works. Updating that mental model is harder than it sounds because the interface rarely forces the distinction.
Looking Ahead Without Waiting For Perfect Fixes
The authors plan to expand future work to additional chains and token types. That expansion will almost certainly raise the measured totals. Until those results appear, the current figures of 126,982.94 ETH and 17,726.7 BNB remain the best available lower bound for native-token losses on the two networks studied. The $574.8 million valuation is a standardized estimate rather than a market snapshot at the moment of each loss.
Protocol-level changes take time. Wallet improvements and better developer tooling can move faster. In the end, the most reliable protection still sits with the person holding the keys or signing the transactions. Awareness of these specific failure modes reduces the chance of becoming another entry in the next large-scale study.
I keep coming back to that early experience of watching funds disappear into an empty address. The technology has advanced in many ways since then. The basic human tendency to treat familiar-looking strings as interchangeable has not changed nearly as much. The gap between those two realities is where the largest and quietest losses continue to accumulate. Closing that gap, one careful check at a time, remains the most practical defense available right now.
The research makes one final point that is easy to overlook. Many of these high-risk addresses continue to receive funds long after they have been publicly flagged. Habit and incomplete information keep the pipeline open. Breaking that pipeline requires both better tools and a willingness to treat every address as potentially compromised until proven otherwise. That mindset feels extreme until you look at the numbers. Then it starts to look like simple realism.
Security in open networks has always been a moving target. New features create new edges. Old habits create persistent ones. The study of 65,340 high-risk instances simply makes the current edges more visible. What happens next depends on whether the people building wallets, writing documentation, and managing their own keys treat that visibility as a call to adjust behavior. The alternative is watching the same categories of loss appear again in the next round of research, only larger.
For anyone who has ever pasted an address without double-checking the network or left a test key in a public file, the findings offer a clear if uncomfortable mirror. The good news is that most of the described risks are preventable with existing practices. The harder news is that prevention still depends on consistent attention in a space that rewards speed. Balancing those two pressures is the real work ahead.
I have found that treating every address interaction as a potential cross-chain or key-exposure risk slows things down just enough to avoid the most expensive mistakes. It is not glamorous. It does not require new technology. It simply refuses to assume that familiar-looking strings are safe by default. In a landscape where 65,340 instances have already been catalogued and more than half a billion dollars have moved in measurable ways, that refusal feels less like caution and more like basic hygiene.
The conversation around blockchain security often focuses on dramatic hacks and sophisticated exploits. Those matter. Yet the quieter, more numerous losses from address misuse and exposed keys add up to something equally significant. They also happen to be the losses that individuals and teams can most directly reduce. That is the part of the research I keep returning to. The numbers are large. The mechanisms are often simple. The room for improvement sits closer than most of us admit on a busy day.
As more chains and more account abstraction features come online, the surface area for similar mistakes will expand. The patterns identified here are unlikely to remain confined to Ethereum and BNB Smart Chain. The same deterministic address logic and the same human tendency to reuse strings appear wherever smart contracts and externally owned accounts coexist. Preparing for that expansion starts with taking the current evidence seriously rather than waiting for the next set of headlines.
Ultimately the study does not claim to have found every risky address or every lost token. It claims to have measured a substantial, carefully bounded slice of the problem with high precision. That is enough to change how careful users approach everyday transactions. It is also enough to push wallet teams and protocol designers to close the most obvious gaps. Whether the next measurement shows progress or further growth will depend on how many of those changes actually ship and how many users actually adopt them.
For now the clearest takeaway remains practical. Check the network. Assume public keys are compromised. Verify code is present before sending. Treat new account features with the same skepticism you would apply to any powerful tool. None of these steps guarantee safety. Together they sharply reduce the chance of becoming another data point in research that keeps finding the same expensive patterns.
The half-billion-dollar lower bound is not an abstract industry problem. It is the sum of individual decisions made under imperfect information. Improving the information and slowing the decisions remains the most direct path to shrinking that number the next time someone runs the analysis. That work is available to anyone who interacts with these networks. The research simply made the cost of skipping it impossible to ignore.
