Key Takeaways:
A peer-reviewed study found attackers behind 63% of early EIP-7702 wallet authorizations, exposing $2.36 million in confirmed losses.
Attacker-linked contracts drove 63% of the 3.66 million EIP-7702 authorization transactions observed across seven chains through July 15, 2025, a peer-reviewed study found.
The research, presented at USENIX Security '26, analyzed more than 22.8 billion historical transactions on Ethereum, Binance Smart Chain, Polygon, Optimism, Arbitrum, Base and Gnosis to identify 924 malicious contracts, the authors said. The study measured $2,362,848.76 in confirmed losses across three attack categories, while a separate estimate flagged about $10.14 million in assets exposed because older contracts assumed a wallet address could never behave like a contract.
Ethereum activated Pectra, including EIP-7702, on May 7, 2025. The upgrade introduced a type-4 transaction that lets an externally owned account point to deployed contract code, giving a conventional wallet smart-account features such as batched calls and sponsored transactions without forcing a migration to a new address. The delegated code gains the power to act with the account's full authority, turning the delegation target into wallet infrastructure.
Attackers reused malicious contracts to inflate transaction counts
The 924 malicious contracts were reused disproportionately, so transaction counts rose faster than the number of distinct contracts or affected users, the authors said. They classified 793 as EOA-targeted, 124 as contract-account-targeted and seven as composite attacks. Attackers prepared authorization fields off-chain and asked victims to sign, sometimes through a wallet prompt that obscured the contract address receiving authority.
The study also found attackers rebinding accounts to normal-looking code after an attack, making current-state-only monitoring unreliable. Researchers identified 500 special nonzero delegation targets with no deployed code, where a precomputed CREATE2 address could receive code later and change what the account executes while the recorded target stays the same.
Wallets face pressure to vet delegated code
The findings push the trust decision onto wallets, which must establish whether selected code deserves control over an account. Post-study ethereum.org guidance calls for whitelisting delegation contracts, prominently displaying the target, avoiding arbitrary delegation on hardware wallets and relying on audited implementations. A related ERC-7902 proposal would restrict wallets to a strict shortlist of well-known, publicly audited smart-account implementations.
Applications should request the feature they need and leave the account implementation to the wallet, current Ethereum Foundation guidance says, pointing developers to a wallet interface such as ERC-5792 for flows like an approval and swap in one transaction. The wallet can then choose EIP-7702, ERC-4337 or another account system without asking the user to approve low-level delegation code selected by the application.
The study's authors acknowledged their method may miss malicious contracts before preparation transactions become visible or attacks using novel interfaces. The 924 contracts represent the detected and manually verified set, while the total universe of abuse remains unknown. A benign current pointer cannot erase a malicious history, and a target with no code may acquire behavior later, so wallets need durable authorization records and a removal path users can understand.
This article is for informational purposes only and does not constitute investment advice.
