One Signature Can Rewrite Your Wallet: Ethereum's EIP-7702 Paradox

1. The upgrade that taught old wallets new tricks

On May 7, 2025 at epoch 364032 (10:05:11 UTC), Ethereum's Pectra upgrade activated on mainnet, bringing EIP-7702 into production. Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and lightclient had created the Standards Track: Core proposal on May 7, 2024. Its summary stated the design bluntly: add a transaction type that permanently sets code for an EOA. Standard key-controlled accounts could now gain smart-contract capabilities without moving to a new address.^[1][2][6]

The underlying mechanism is deterministic. A set-code transaction uses transaction type 0x04 and carries an authorization list containing individual authorization tuples, formatted as [chain_id, address, nonce, y_parity, r, s]. For each valid tuple processed, a delegation indicator consisting of the magic prefix 0xef0100 concatenated with the target 20-byte contract address is written directly into the authorizing account's code slot. Every subsequent EVM code-executing operation targeting that EOA must load and execute the bytecode deployed at the referenced address. While the account's private key retains underlying sovereignty, the account behaves dynamically during execution as the designated smart contract.^[1]

This architecture delivers account-abstraction capabilities: atomic batching, third-party gas sponsorship, alternative authentication including passkeys, spending limits, and account recovery. The Ethereum Foundation's Pectra announcement also describes safety rails: authorizations are chain-specific by default, nonce-bound, and replaceable or revocable by the owner. These controls reduce replay and lock-in risk without making an unsafe delegate harmless.^[2]

2. Persistent by design, not by accident

The most critical architectural nuance of EIP-7702 lies in its execution order and lifecycle semantics. The authorization list is processed before the transaction's execution payload begins, immediately after the sender's nonce is incremented. Crucially, if the subsequent transaction execution encounters an error, runs out of gas, or reverts, the processed delegation indicators are not rolled back. The delegation remains persistently installed in the account's code slot until the owner deliberately authorizes a replacement or clears the delegation by pointing to the zero address. It is permanent account-level code delegation, not a temporary session authorization that expires when an interaction concludes.^[1][3]

Because the installed delegation stands indefinitely, the specification pairs this persistence with explicit security warnings. The code designated by an authorization gains unrestricted access to the account's entire state and token balances, making comprehensive wallet auditing essential. The EIP authors noted candidly that very few end users possess the technical sophistication required to inspect and verify arbitrary contract bytecode before signing. Although the account owner retains private-key sovereignty and can submit a new transaction to reset the account to a standard EOA, that revocation mechanism cannot undo malicious transactions executed while an untrusted contract held execution authority.^[1][3]

A poorly implemented delegate can allow a malicious actor to take near complete control over a signer's EOA.^[1]

— EIP-7702 specification, Security Considerations

3. The authorization-phishing surface

Security Alliance identifies the primary threat in its guidance on verifying EIP-7702 authorizations: phishing sites and scams that trick users into signing a SetCode delegation to a malicious contract under the guise of a wallet upgrade. If a victim signs an authorization that points the account at attacker-controlled code, the guidance warns that the attacker can gain control and drain assets. The weapon is not necessarily a stolen seed phrase; it can be a valid consent signature obtained through a deceptive interface.^[5]

This dynamic changes the shape of authorization phishing. Many conventional approval or transaction scams focus on a harmful action the victim is being asked to sign. Under EIP-7702, one valid authorization tuple, once processed in a type 0x04 transaction, establishes a persistent code pointer on-chain, and the pointer survives failure of the transaction's execution phase. The December 2025 preprint characterizes that standing change as a qualitatively new class of phishing; the protocol mechanics confirm the persistence, while the attack classification remains the authors' preprint claim.^[1][4]

The potential attack radius can also transcend individual blockchains. While EIP-7702 authorizations bind to a specific chain identifier by default, setting the chain_id parameter to 0 creates an authorization that is valid across every EVM-compatible network. Security Alliance cautions that a chain-ID-0 signature can be replayed by an adversary on secondary chains where the attacker deploys a corresponding malicious contract at the same address. To mitigate these cross-chain and delegation phishing risks, official integration guidelines urge wallets to prominently and unambiguously display the target contract address to users prior to signing.^[3][5]

4. A preprint, not a verdict

On December 13, 2025, researchers Minfeng Qi and Tianqing Zhu from the City University of Macau, Qin Wang and Shiping Chen from CSIRO Data61, and Ruiqiang Li from the University of Wollongong published an academic preprint titled EIP-7702 Phishing Attack on the arXiv repository under identifier 2512.12174v1 [cs.CR]. The authors set out to investigate how the standing execution capabilities introduced by EIP-7702 alter threat modeling for everyday crypto users, summarizing their core finding in the abstract.^[4]

We show that this design enables a qualitatively new class of phishing attacks^[4]

— Minfeng Qi et al., EIP-7702 Phishing Attack (arXiv preprint 2512.12174v1)

All empirical measurements in the paper remain preliminary author claims tied to its preprint status. Its controlled security experiments, on-chain adoption metrics, and calculations of potential malicious delegation impact have not completed peer review, and this account intentionally omits the paper's specific adoption metrics and loss totals as unverified. Furthermore, the underlying security risks were recognized long before the preprint's publication. When Vitalik Buterin and his co-authors drafted EIP-7702 in May 2024, they explicitly anticipated delegation risks, warning that raw authorization signing should never become an unmediated user-facing capability in decentralized applications.^[1][4]

5. The defense boundary

The ecosystem's defense is a division of labor. Ethereum.org guidance expects wallets to whitelist specific delegation contracts and tells dApps not to request EIP-7702 authorizations directly, instead using standardized wallet interfaces such as ERC-5792 wallet_sendCalls. Its hardware-wallet guidance likewise says devices should not expose arbitrary delegation and describes a trusted list of delegator contracts as the emerging consensus. These are interface constraints and recommendations, not protocol-enforced guarantees.^[3]

Security guidance for end users reinforces this structural boundary. Security Alliance advises users to rely exclusively on native wallet delegation features, approve authorizations only for contracts thoroughly vetted and integrated by reputable wallet providers, and remember that an account can be reset at any time to a standard EOA by delegating to the zero address (0x0000000000000000000000000000000000000000). Ultimately, system security cannot rely on user-level bytecode inspection. As the EIP-7702 specification bluntly concludes regarding client interfaces: "There is no safe way to provide this interface."^[1][5]

This defensive architecture defines the true legacy of EIP-7702. The upgrade successfully delivered the long-sought benefits of account abstraction—transaction batching, sponsored gas fees, hardware key authentication, and social recovery—to standard Ethereum accounts without requiring painful migrations. Yet by enabling a single signature to install persistent bytecode, it shifted the security paradigm from continuous transaction validation to strict interface access control. Ethereum's core developers recognized this tradeoff from day one, embedding the imperative for wallet-level enforcement directly into the proposal over a year before academic researchers formalized the attack vector.^[1][2][4]

Applications must not expect that they can suggest the user sign an authorization, and therefore it is the duty of the wallet to not provide an interface to do so.^[1]

— EIP-7702 specification, Interaction with applications and wallets