A peer-reviewed study presented for USENIX Security '26 has found that attacker-linked contracts were tied to 63% of Ethereum's EIP-7702 authorization transactions during the wallet delegation feature's early months of operation. The researchers tracked 3.66 million authorization transactions across seven chains through July 2025, measured $2.36 million in confirmed losses, and identified a further $10.14 million in assets exposed through outdated contract defenses.

The feature in question, EIP-7702, lets a regular Ethereum wallet temporarily act like a smart contract. It went live as part of the Pectra upgrade on May 7, 2025. The proposal, co-authored by Ethereum co-founder Vitalik Buterin, was introduced during Pectra planning as a replacement for the earlier EIP-3074 design and is part of Ethereum's broader account abstraction effort to give ordinary wallets capabilities that previously required a separate contract.

The research team studied more than 22.8 billion transactions across seven blockchains: Ethereum, Binance Smart Chain, Polygon, Optimism, Arbitrum, Base, and Gnosis. Within that dataset, they found 3,664,166 EIP-7702 authorization transactions through July 15, 2025. Of those, 2,322,548 transactions, or 63%, were linked to contracts the researchers identified as malicious. The team used transaction filters, code analysis, and manual review to confirm 924 malicious contracts overall.

How the delegation feature works

EIP-7702 allows a wallet address to point to separate contract code without changing the address itself. The original owner keeps their private key, but the linked code can act with the full authority of that account. Because the address stays the same, funds, history, and identity carry over; what changes is that the account's behavior is defined by whichever code it currently points to. A delegation can also be changed or cleared by signing a new authorization, so the code visible on-chain reflects only the most recent one.

This setup lets wallets add features such as batching multiple actions into one transaction or letting someone else pay the gas fee. It also means the linked code becomes part of the wallet's security. If that code is faulty or written by an attacker, it can approve transfers, move funds, or interact with applications as if it were the account owner.

The researchers say attackers prepared these authorizations ahead of time and got victims to sign them, in some cases through a wallet prompt that did not clearly show which code was being approved.

Confirmed losses and exposed assets

The study measured $2,362,848.76 in confirmed losses across three attack types.

A separate part of the research examined older contracts that assumed a wallet address could never behave like a contract. That assumption had held since Ethereum's launch and was used as a common safety check, but it broke once EIP-7702 went live. The researchers found 967 active Ethereum contracts still relying on it as a security check, exposing about $10.14 million in assets to potential risk.

The researchers also documented attackers switching an account back to normal-looking code after an attack, which makes it hard for anyone checking a wallet's current state to spot that it was compromised earlier. They additionally found 500 delegation targets pointing to addresses with no code yet deployed. Code could be added to those addresses later, changing what the wallet actually does while its recorded target stays the same.

The study's authors note that their method may not catch every malicious contract, especially newer ones or those using different attack methods. The 924 confirmed contracts represent what the researchers were able to verify, not the full scope of abuse.

Wallet guidance and proposals

In response, Ethereum.org has released guidance recommending that wallets whitelist delegation contracts, clearly show users which code they are approving, and rely only on audited smart account implementations. A related proposal calls for wallets to stick to a short list of publicly reviewed account systems rather than letting any application request custom delegation code. Because delegation requests reach users inside wallet interfaces rather than at the protocol level, adoption of these interface-level safeguards is where the practical defense currently sits.

Researchers and Ethereum developers are now pushing wallets to vet and clearly display any code an account delegates to.

Source: Blockonomi