A peer-reviewed study released for USENIX Security '26 has revealed that attacker-linked contracts drove 63% of early transaction volume for Ethereum's new smart wallet feature, EIP-7702. Out of 3,664,166 observed authorization transactions across seven blockchains through July 15, 2025, malicious contracts were associated with 2,322,548 transactions.
Ethereum activated the Pectra upgrade, which included EIP-7702, on May 7, 2025. The specification introduced a transaction type allowing an externally owned account (EOA) to set a pointer to deployed contract code. This design enables conventional wallets to gain smart account features—such as batched calls and sponsored transactions—without requiring users to migrate to a new address. However, it also grants delegated code the authority to act on behalf of the account.
Using transaction filters, bytecode analysis, and manual review, the researchers identified 924 malicious contracts within their dataset, categorizing 793 as EOA-targeted, 124 as contract-account-targeted, and seven as composite attacks. The study recorded $2,362,848.76 in realized losses across three attack categories. A relatively small set of malicious contracts was tied to repeated authorizations, reflecting exploratory practice or proof-of-concept testing during the feature's early phase.
Beyond direct wallet compromise, EIP-7702 affected legacy smart contracts by breaking the assumption that msg.sender == tx.origin reliably identifies a plain EOA or prevents contract-mediated behavior. The researchers identified 967 active Ethereum contracts using that check as a flash-loan defense, estimating that approximately $10.1 million in assets faced potential high risk due to the invalidated defensive assumption.
The study also highlighted tracking complications, noting that attackers occasionally rebound accounts to benign code following an attack and utilize precomputed CREATE2 addresses with no deployed code initially. Consequently, the authors emphasize that authorization history forms a crucial security boundary, requiring wallets and monitoring tools to track where accounts previously pointed and to treat undeployed targets as unresolved.
Guidance from ethereum.org and account abstraction proposals recommend that wallets treat delegation as a controlled installation decision. Recommendations include whitelisting delegation contracts, prominently displaying targets, relying on audited implementations, and avoiding arbitrary delegation on hardware wallets.
