Ethereum’s shortcut to smart wallet behavior arrived with a new trust problem: a wallet can make a regular address programmable without moving the user’s assets, while the delegated code gains power to act with that account’s authority.
A peer-reviewed study released for USENIX Security ’26 found that attacker-linked contracts were associated with 2,322,548 of the 3,664,166 EIP-7702 authorization transactions it observed across seven chains through July 15, 2025. That is 63% of the historical transaction volume in the researchers’ dataset.
The authors tied a relatively small set of malicious contracts to repeated authorizations and described some attacker-controlled activity as likely practice or proof-of-concept testing during an early, exploratory phase.
The figure measures transactions, while distinct-wallet prevalence and the current 2026 attack rate sit outside the study’s scope.
Why attackers dominated the early authorization count
Ethereum activated Pectra, including EIP-7702, on May 7, 2025. The final specification introduced a type-4 transaction that lets an externally owned account set a pointer to deployed contract code.
The address stays the same, the original private key retains control, and calls to the account can execute the delegated code in the account’s context.
That design can give a conventional wallet features associated with smart accounts, including batched calls and sponsored transactions, without forcing the user to migrate to a new address. It also turns the delegation target into wallet infrastructure.
Buggy or hostile code may be able to make approvals, transfers and application calls as the account.
It says applications should not expect to ask users for arbitrary authorization signatures because there is no safe generic interface for users to assess code with unrestricted account access. Wallets are expected to vet the implementation.
Attackers could prepare authorization fields off-chain and ask a victim to sign, and a wallet might reduce the decision to a high-level account-upgrade prompt while obscuring the contract address or code receiving authority.
The protocol verifies the account owner’s signature, while the wallet still has to establish whether the selected code deserves control.
The researchers analyzed more than 22.8 billion historical transactions on Ethereum, Binance Smart Chain, Polygon, Optimism, Arbitrum, Base, and Gnosis.
Within that data, they examined 3,664,166 EIP-7702 authorizations through the cutoff and used transaction filters, bytecode analysis and manual review to identify 924 malicious contracts. They classified 793 as EOA-targeted, 124 as contract-account-targeted and seven as composite attacks.
| Study measure | What it captures |
|---|---|
| 3,664,166 authorizations | Historical EIP-7702 transactions across seven chains through July 15, 2025 |
| 2,322,548 authorizations, or 63% | Historical transactions associated with malicious EOA-targeted contracts |
| 924 malicious contracts | The detected and manually reviewed set under the researchers’ method |
| $2.36 million | Detected realized loss across three attack categories |
| About $10.14 million | Potential exposure in a separate legacy-contract subset |
The paper says malicious contracts were reused disproportionately, so transaction counts can rise much faster than the number of distinct contracts or affected users. In a young authorization market, that repeated attacker activity had an outsized effect on the denominator.
Attackers found a repeatable route to account-level authority before wallets had made the trust decision as legible and constrained as the power it conveyed.
The risk reaches beyond hijacked wallets
The study measured $2,362,848.76 in realized losses across its three attack categories. A separate estimate covered older contracts whose defenses assumed that programmable EOAs could not exist.
EIP-7702 breaks the old assumption that msg.sender == tx.origin reliably identifies a plain EOA or blocks contract-mediated behavior.
The researchers identified 967 active Ethereum contracts in a subset using that check as a flash-loan defense and estimated that about $10.1 million in assets were at potential high risk.
Detected theft totaled about $2.36 million, so the $10.14 million represents assets exposed by a defensive assumption that no longer held.
The researchers observed attackers rebinding accounts to benign code after an attack, making current-state-only monitoring unreliable. They also found 500 special nonzero delegation targets with no deployed code.
A precomputed CREATE2 address could receive code later, changing what the account executes while the recorded target stays the same.
Those patterns make authorization history part of the security boundary. Wallets and monitoring tools need to remember where an account previously pointed, evaluate changes in delegated code, and treat an undeployed target as unresolved rather than harmless.
The authors’ rules may miss malicious contracts before preparation transactions become visible or attacks using novel interfaces outside the method’s coverage. The 924 contracts are the detected and manually verified set, while the total universe of abuse remains unknown.
Safe default behavior starts with making delegation a wallet-controlled installation decision. 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.
An account-abstraction wallet capability proposal takes the same direction, calling for a strict shortlist of well-known, publicly audited smart account implementations. These documents do not measure how consistently production wallets have adopted it.
Applications should request the feature they need and leave the account implementation to the wallet. For an approval and swap in one flow, current Ethereum Foundation guidance points developers to a wallet interface such as ERC-5792.
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.
Current guidance recommends signing initialization parameters or restricting setup to the ERC-4337 EntryPoint, closing a front-running path in which an attacker substitutes their own values.
The study identified a related failure mode in legacy wallet code: constructors do not run again when an account delegates to an existing contract, which can leave ownership unset and externally claimable.
A benign current pointer cannot erase a malicious history, and a target with no code may acquire behavior later. Wallets need durable authorization records, clear alerts when the delegation changes, and a removal path that users can understand.
Making the EIP-7702 wallet programmability safe by default requires wallets to treat delegation as installation of the account’s control plane: restrict who can request it, expose exactly what will control the account, verify how it initializes, and keep watching after the pointer changes.
