EIP-7702's dirty secret: attackers drove 63% of early smart wallet transactions

I remember the day Pectra went live. May 7, 2025. The trenches were buzzing about EIP-7702 and how it would finally give regular wallets superpowers without forcing everyone to migrate to new addresses. No seed phrase roulette. No new UI to learn. Just a clean upgrade path to smart wallet behavior.

Then the data started rolling in. And anon, let me save you some gas fees: the early adopters weren't degens trying out batched transactions. They were attackers.

A peer-reviewed study headed to USENIX Security '26 just dropped a number that should make every Ethereum user pause. Of the 3,664,166 EIP-7702 authorization transactions observed across seven chains through July 15, 2025, a staggering 2,322,548 were associated with attacker-linked contracts. That's 63% of all historical authorization volume. Nearly two-thirds of early usage was malicious.

I aped into the EIP-7702 narrative hard. This study is the reality check I needed.

The: what the numbers actually say

Let's break down what the researchers found. They analyzed more than 22.8 billion historical transactions across Ethereum, BSC, Polygon, Optimism, Arbitrum, Base, and Gnosis. Within that massive dataset, they identified 924 malicious contracts. Of those, 793 targeted EOAs directly, 124 targeted contract accounts, and seven were composite attacks.

The losses are real but not catastrophic. Detected realized losses came in at $2,362,848.76 across the three attack categories. That's $2.36 million stolen through this new attack surface.

But here's the scarier number. The researchers identified 967 active Ethereum contracts using the oldmsg.sender == tx.origincheck as a flash-loan defense. EIP-7702 breaks that assumption completely. Those contracts guard roughly $10.14 million in assets that are now exposed to a vulnerability their developers never anticipated.

Think about that for a second. Your contract assumed a programmable EOA couldn't exist. Now it can. And the funds sitting in those contracts are at high risk because the security model they were built on is gone.

The attackers weren't sophisticated geniuses either. The study found a relatively small set of malicious contracts used repeatedly. Some of the activity looked like practice runs. Proof-of-concept testing during an exploratory phase. They were learning, iterating, and getting better.

Here's the part that keeps me up at night. Attackers found a repeatable route to account-level authority before wallets made the trust decision legible. They could prepare authorization fields off-chain, trick a victim into signing, and the wallet might just show a high-level upgrade prompt while obscuring the contract address receiving authority.

That's not a protocol bug. That's a UX failure.

The broader implications: your wallet is now infrastructure

EIP-7702 fundamentally changes what a wallet is. Your address stays the same. Your private key still controls everything. But the code executing in your account's context can now make approvals, transfers, and application calls as if it were you.

That delegated code is wallet infrastructure now. And most wallets treated it like a casual feature toggle.

The attackers rebinding accounts to benign code after an attack is a particularly nasty detail. Current-state-only monitoring won't catch these threats. You need to know where an account pointed before, not just where it points now. And those 500 special nonzero delegation targets with no deployed code? They could receive code later via CREATE2, changing what executes while the recorded target stays the same. The history is part of the security boundary now.

So who wins and who loses here?

Winners: wallets that treat delegation as a security-critical installation decision. The ones that whitelist known-good contracts, display delegation targets prominently, and refuse arbitrary delegation on hardware wallets. The ethereum.org guidance is already moving this direction. So is the ERC-7902 wallet capability proposal. They're calling for strict shortlists of well-known, publicly audited smart account implementations.

Losers: every legacy contract that assumed EOAs were simple accounts. Every wallet that shows a generic confirmation without explaining what code is about to control your account. Every user who signs first and asks questions later.

And let's be real about something. The measured $2.36 million in losses probably understates the problem. The study's method can miss malicious contracts before preparation transactions become visible. Novel interfaces outside the coverage could slip through. The 924 contracts are what they detected and manually verified. The total universe of abuse is unknown.

This is a market efficiency problem too. When the dominant early use case for a new primitive is theft, the cost of capital rises for everyone using it legitimately. It's like the early days of DeFi all over again. Unaudited code, rushed integrations, and users paying the price for infrastructure that moved faster than its safety rails.

I've been in this space long enough to see the pattern repeat. New primitive drops. Attackers move first. Defenders scramble to catch up. The trenches don't sleep, and neither do the bad actors.

What you should actually do with this information

First, update your wallet. If you're using a wallet that doesn't clearly show what code you're delegating to, you're the product. Not financial advice but I'm market-buying into wallets that take this seriously.

Second, be skeptical of any prompt asking you to upgrade your account. If it doesn't show the contract address, explain what the code does, and where it was audited, don't sign. A wallet that obfuscates the delegation target is a liability.

Third, if you've assets in contracts that usemsg.sender == tx.originas a security check, move them. That assumption is dead. The $10.14 million exposure estimate is the canary in the coal mine. The researchers flagged 967 contracts with this vulnerability. You don't know if you're holding assets in one of them.

And developers, stop asking users to approve low-level delegation code selected by your application. Use the wallet interface. Let the wallet choose between EIP-7702, ERC-4337, or whatever account system makes sense. The application should request the feature it needs and leave the account implementation to the wallet. That's the architecture that keeps users safe.

Here's the thing though. I'm not bearish on EIP-7702. The design is genuinely useful. Smart wallets without migration friction could be the onboarding boon Ethereum needed. But the early data shows we skipped the security hardening phase and went straight to production.

That's not a failure of the EIP. It's a failure of the surrounding infrastructure to mature at the same speed.

The fix is straightforward. Wallets need durable authorization records. They need clear alerts when delegation changes. They need a removal path users can understand. Delegation should be treated as installation of the account's control plane, not a checkbox in a settings menu.

Until that happens, every EIP-7702 user is trusting their wallet to make a decision most wallets haven't proven they can handle. 63% of early transactions were malicious. The feature works as designed. The safety net doesn't exist yet.

I'll keep using smart wallets. But I'm reading every prompt like it's trying to rug me.

Because in these trenches, it probably is.