Login
Sign Up
Woofun AI reports that the introduction of Ethereum's EIP-7702 smart wallet feature has been severely compromised by attacker-linked contracts, as revealed by a peer-reviewed study presented at USENIX Security '26. The research highlights a fundamental trust dilemma inherent in the protocol's design, where the ability to make regular addresses programmable without asset migration has been exploited at an alarming scale during its early adoption phase.
The statistical prevalence of malicious activity is starkly evident in the transaction data analyzed by the researchers. Across seven distinct blockchain networks, the study observed a total of 3,664,166 EIP-7702 authorization transactions up to the cutoff date of July 15, 2025. Within this dataset, attacker-linked contracts were associated with 2,322,548 of these transactions, representing a staggering 63% of the historical transaction volume recorded in the researchers' scope. This figure specifically measures transaction count rather than distinct wallet prevalence, and the current attack rate for 2026 remains outside the study's defined parameters.
Structurally, EIP-7702 allows a user's regular address to execute delegated code while retaining control via the original private key. This mechanism enables conventional wallets to adopt smart account features, such as batched calls and sponsored transactions, without forcing users to migrate to new addresses.
However, this design effectively transforms the delegation target into critical wallet infrastructure, granting the delegated code the authority to act within the account's context. The address remains unchanged, but the execution environment shifts to accommodate the delegated logic.
The security risks associated with this architecture are significant, as buggy or hostile code can execute approvals, transfers, and application calls on behalf of the account. Applications are advised against requesting arbitrary authorization signatures from users, given the absence of a safe generic interface for assessing code with unrestricted account access. Consequently, the burden of vetting the implementation falls squarely on wallets, which must ensure that the selected code is trustworthy before granting it control over the account's assets and permissions.
Attackers have exploited these vulnerabilities by preparing authorization fields off-chain and tricking victims into signing them. Wallets often obscure the complexity of these actions by reducing the decision to a high-level account-upgrade prompt, hiding the specific contract address or code receiving authority. While the protocol verifies the account owner's signature, the wallet remains responsible for establishing whether the selected code deserves control, creating a critical gap between cryptographic verification and semantic trust.
Woofun AI data shows that within the analyzed dataset, researchers employed transaction filters, bytecode analysis, and manual review to identify 924 malicious contracts. These were classified into three distinct categories: 793 were EOA-targeted, 124 were contract-account-targeted, and seven were composite attacks. This classification underscores the diverse and sophisticated nature of the threats, with attackers finding repeatable routes to account-level authority before wallets could make the trust decision as legible and constrained as the power it conveyed.
The financial impact of these attacks is substantial, with realized losses totaling $2,362,848.76 across the three identified attack categories.
Additionally, the study highlighted a separate risk involving older contracts that relied on legacy defenses assuming programmable EOAs could not exist. Researchers identified 967 active Ethereum contracts using this flawed check as a flash-loan defense, estimating that approximately $10.1 million in assets were at potential high risk. The detected theft of about $2.36 million represents only a fraction of the $10.14 million in assets exposed by defensive assumptions that no longer hold true in the post-EIP-7702 landscape.
Notably, attackers employed evasion tactics such as rebinding accounts to benign code after an attack, rendering current-state-only monitoring unreliable. The study also uncovered 500 special nonzero delegation targets with no deployed code, where a precomputed CREATE2 address could receive code later. This allows the account's execution behavior to change while the recorded target remains the same, demonstrating that authorization history is now an integral part of the security boundary. Monitoring tools must therefore treat undeployed targets as unresolved rather than harmless.
Wallet mitigation strategies must evolve to address these legacy code flaws and new attack vectors. Current guidance recommends signing initialization parameters or restricting setup to the ERC-4337 EntryPoint to close front-running paths where attackers substitute their own values. The study identified a related failure mode in legacy wallet code where constructors do not run again when an account delegates to an existing contract, potentially leaving ownership unset and externally claimable. Wallets must choose between EIP-7702, ERC-4337, or other systems without exposing users to low-level delegation code selected by applications.
Making EIP-7702 wallet programmability safe by default requires wallets to treat delegation as the installation of the account's control plane. This involves restricting who can request delegation, exposing exactly what will control the account, verifying initialization parameters, and maintaining durable authorization records. A benign current pointer cannot erase a malicious history, and targets with no code may acquire behavior later. Therefore, wallets must provide clear alerts when delegation changes and offer a removal path that users can understand, ensuring continuous monitoring even after the pointer changes.