A significant new trust problem has emerged alongside Ethereum's shortcut to smart wallet behavior, with researchers linking 63% of the feature's early authorization transactions to contracts controlled by attackers and identifying $2.36 million in resulting losses. This new capability allows a standard wallet address to become programmable without moving the user's assets, but it concurrently gives the delegated code the full authority to act on the account's behalf.

A peer-reviewed study slated for USENIX Security '26 discovered that out of 3,664,166 EIP-7702 authorization transactions observed through July 15, 2025, a total of 2,322,548 were connected to attacker-linked contracts. This figure represents 63% of the historical transaction volume analyzed in the researchers' dataset across seven different blockchain networks.

The authors noted that a relatively limited number of malicious contracts were responsible for these repeated authorizations. They also characterized some of the attacker-controlled activity as probable practice runs or proof-of-concept tests conducted during the feature's initial, exploratory period. It is important to note that the study's figures measure transaction counts, while the prevalence of distinct wallets affected and the current attack rate in 2026 fall outside its scope.

How the Programmable Wallet Feature Works

On May 7, 2025, Ethereum implemented the Pectra upgrade, which included EIP-7702. The final specification for this enhancement introduced a new type-4 transaction. This transaction type enables an externally owned account (EOA) to establish a pointer to deployed contract code.

Under this model, the user's address remains unchanged and the original private key maintains control. However, calls made to the account can now trigger the execution of the delegated code within that account's context. This design grants a conventional wallet access to features typically associated with smart accounts, such as batched calls and sponsored transactions, all without requiring the user to migrate to a new address. The trade-off is that the delegation target effectively becomes a piece of the wallet's core infrastructure. Consequently, any buggy or hostile code may gain the ability to execute approvals, transfers, and application calls as if it were the account itself.

The study states that applications should not expect users to sign arbitrary authorization signatures, as no universally safe interface exists for users to evaluate code that receives unrestricted account access. The responsibility for vetting the implementation is expected to fall on the wallets. Attackers can exploit this by preparing authorization fields off-chain and then prompting a victim to sign them. A wallet might simplify this decision into a high-level "account upgrade" prompt, potentially obscuring the contract address or the code that is gaining authority. While the protocol verifies the account owner's signature, the wallet is still tasked with determining if the chosen code is trustworthy enough to be granted control.

Scope of the Analysis

To arrive at their conclusions, the researchers analyzed an enormous dataset of over 22.8 billion historical transactions on Ethereum, Binance Smart Chain, Polygon, Optimism, Arbitrum, Base, and Gnosis. Within this data, they focused on the 3,664,166 EIP-7702 authorizations that occurred before their cutoff date. Through a combination of transaction filters, bytecode analysis, and manual review, they successfully identified 924 malicious contracts. These were further classified into 793 targeting EOAs, 124 targeting contract accounts, and seven engaging in composite attacks.

The disproportionate reuse of malicious contracts meant that transaction counts could escalate far more rapidly than the number of unique contracts or affected users. In the nascent market for this authorization feature, this repetitive attacker activity had a magnified impact on the overall statistics.

Financial Impact and Hidden Risks

The study calculated $2,362,848.76 in realized losses spread across its three designated attack categories. Attackers found a repeatable method to gain account-level authority before wallets had developed ways to make the trust decision as clear and controlled as the power it granted.

A separate estimate highlighted a vulnerability in older contracts, whose security measures were built on the assumption that programmable EOAs were not possible. EIP-7702 invalidates the long-held belief that msg.sender == tx.origin is a reliable way to identify a standard EOA or to prevent behavior mediated by a contract. In a subset of contracts, the researchers found 967 active Ethereum contracts using this specific check as a defense against flash loans. They estimated that approximately $10.1 million in assets within these contracts were at a potential high risk.

To clarify, the detected theft amounted to about $2.36 million, while the $10.14 million figure represents assets that became exposed because a fundamental defensive assumption was no longer valid.

Sophisticated Attack Vectors

Researchers observed attackers engaging in sophisticated tactics, such as rebinding accounts to harmless code after an attack, a method that makes monitoring systems that only check the current state unreliable. They also discovered 500 special nonzero delegation targets that had no code deployed to them. A precomputed CREATE2 address could be used to deploy code to such a target later, altering what the account executes even while the recorded target address remains unchanged.

These patterns underscore that authorization history is now an integral part of the security boundary. Wallets and monitoring tools must now remember where an account has pointed in the past, assess changes in delegated code, and treat any undeployed target as unresolved and potentially dangerous, not harmless. The authors acknowledge that their detection rules might miss malicious contracts before preparatory transactions are visible or fail to catch attacks using novel interfaces. The 924 contracts represent the set that was detected and manually confirmed, leaving the total scope of abuse unknown.

Guidance for the Ecosystem

Safe default behavior begins with treating delegation as a wallet-controlled installation decision. Following the study, official ethereum.org guidance now calls for whitelisting delegation contracts, prominently displaying the target address, advising against arbitrary delegation on hardware wallets, and mandating the use of audited implementations.

An account-abstraction wallet capability proposal advocates for a similar approach, pushing for a strict shortlist of well-known and publicly audited smart account implementations. However, these documents do not provide data on how consistently production wallets have implemented these safety measures.

For applications, the recommendation is to request the specific feature needed and entrust the account implementation details to the wallet. For a common flow like an approval and a swap, current Ethereum Foundation guidance directs developers to a wallet interface like ERC-5792. This allows the wallet to choose the best underlying system—be it EIP-7702, ERC-4337, or another—without forcing the user to approve low-level delegation code selected by the application. Current guidance also advises signing initialization parameters or confining setup to the ERC-4337 EntryPoint to close a front-running vulnerability where an attacker could substitute their own values.

The study also pointed out a related flaw in legacy wallet code: constructors are not executed again when an account delegates to an already existing contract. This can result in ownership being left unassigned and thus externally claimable.

Ultimately, a benign current pointer cannot undo a malicious history, and a target with no code might gain functionality later. Wallets must maintain durable authorization records, provide clear alerts when delegation changes, and offer a removal path that is easily understood by users. To make the wallet programmability of EIP-7702 safe by default, wallets must treat delegation as the installation of the account's entire control plane: they need to restrict who can request it, clearly expose what will gain control of the account, verify its initialization, and continue monitoring even after the pointer is changed.