EIP-7702

Summary

EIP-7702 ("Set EOA Account Code") is a core Ethereum protocol upgrade, authored by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and lightclient, that lets a regular externally owned account (EOA) point at smart-contract code for the duration of a transaction. It introduces a new transaction type, 0x04 (SET_CODE_TX_TYPE), carrying an authorization_list of signed tuples (chain_id, address, nonce, y_parity, r, s). Each authorized EOA gets a 23-byte "delegation designator" (0xef0100 || address) written to its code slot, causing calls into that account to execute the delegated contract's logic while CODESIZE/CODECOPY still read the designator locally. The proposal shipped as part of Ethereum's Pectra network upgrade, which activated on mainnet on May 7, 2025. It is the successor to a lineage of failed or stalled account-abstraction proposals (EIP-3074, ERC-4337) and is explicitly framed as the minimal, EOA-native path to smart-account features — batching, sponsored gas, and session keys — without forcing wallet migration.

Design (Mechanism)

The mechanism has three moving parts. First, the authorization signature: an EOA owner signs a tuple committing to delegate their account's execution to a specific contract address, optionally with chain_id = 0 for cross-chain reuse and a nonce that must match the account's current nonce (incremented on each authorization to prevent replay). Second, the delegation designator: once a SET_CODE transaction includes a valid authorization, the protocol writes the fixed-format code 0xef0100 || address into the authorizing EOA's code field — a "pointer," not the contract's actual bytecode — so any CALL, CALLCODE, DELEGATECALL, or STATICCALL targeting that EOA now executes the pointed-to contract's logic in the context of the EOA (its own storage, its own address, msg.sender semantics preserved for the smart-account contract). Third, atomicity and sponsorship: because the SET_CODE transaction can bundle the authorization together with an arbitrary call, a single transaction can install a smart-account implementation and immediately execute logic through it — e.g., a "batcher" contract that does approve then swap in one atomic step, or lets a relayer/paymaster submit and pay for the transaction while the authorization signature proves the EOA's consent. Gas costs are set at 12,500 per authorization tuple plus 25,000 for authorizing an empty (not-yet-existing) account, reflecting the state growth of writing a new delegation. Delegations persist until the EOA authorizes a new target (including the zero address to revert to a plain EOA), meaning a wallet can effectively "become" a smart contract permanently, not just per-transaction, unless the authorizing transaction itself scopes the delegation.

Outcome

EIP-7702 activated with Pectra on May 7, 2025 and was adopted quickly by wallet and infrastructure providers — MetaMask, Coinbase Wallet, and various smart-account/session-key SDKs began shipping 7702-based batching, gas sponsorship, and passkey-style authentication flows within weeks. But the same mechanism was immediately weaponized: because a compromised private key can also sign a valid authorization, attackers found they could point a victim's EOA at a "sweeper" contract that auto-drains any incoming funds. Wintermute's research identified that a majority of early 7702 delegations traced to a single script nicknamed "CrimeEnjoyor," and reporting through mid-to-late 2025 documented phishing groups (Inferno Drainer, Pink Drainer among them) industrializing 7702-based drains, with cumulative losses reported in the low tens of millions of dollars across tens of thousands of wallets by late 2025. Wintermute's own analysis, however, found that most of these automated drainer deployments made little or no profit, since they mostly targeted already-compromised or empty accounts rather than creating new compromise. Ethereum core devs and wallet teams responded with UX-level mitigations (delegation warnings, allowlisted implementation contracts, revocation tooling). Status: ongoing — 7702 is now a permanent part of Ethereum's transaction-type surface, with adoption and abuse both still evolving.

Why it worked

• Minimal, EOA-preserving design. Unlike ERC-4337 (which requires a separate, non-native "UserOperation" mempool and bundlers) or EIP-3074 (which was abandoned partly over security concerns about AUTH/AUTHCALL), 7702 upgrades existing addresses in place, so users keep their address, history, and ENS/social identity while gaining smart-account features.
• Core protocol backing. Because it shipped as a Core EIP inside Pectra rather than an opt-in ERC standard, every EOA on Ethereum gained the capability simultaneously, giving wallets and dapps a single, predictable target to build against rather than a fragmented ecosystem of competing account-abstraction standards.
• Immediate composability wins. Atomic approve-and-swap, sponsored onboarding (no ETH needed to pay gas), and passkey/session-key signing solved concrete UX pain points that had blocked mainstream wallet adoption for years.

Limitations and criticisms

• Signature reuse as an attack surface. The same authorization signature that lets a user delegate to a legitimate smart-account contract can be extracted via phishing or malware and redirected to a drainer contract, and because delegation persists until explicitly revoked, a single bad signature can leave a wallet compromised indefinitely rather than for one transaction.
• No built-in implementation allowlisting. The base EIP does not restrict which contracts an EOA may delegate to, so wallets had to bolt on their own trust/allowlist layers after the fact rather than having safety designed into the standard.
• User mental model gap. Most users still do not understand that "signing an authorization" can permanently change what their wallet address does, making 7702 authorization prompts an unusually high-value, low-comprehension phishing target compared to a typical token approval.

Lessons

• Making a powerful capability (account code delegation) available to every existing address by default trades a fragmented, opt-in rollout problem for a uniform, protocol-wide attack surface — the security burden shifts from "will people adopt this" to "will every wallet correctly sandbox it."
• Persistent delegation (rather than transaction-scoped delegation) is a double-edged design choice: it enables durable smart-account UX but also means a single compromised signature has open-ended blast radius until revoked.
• Ecosystem-level telemetry (Wintermute's public analysis of delegation patterns) proved to be as important as the protocol spec itself in distinguishing real abuse from noise, suggesting that major account-abstraction upgrades need monitoring infrastructure shipped alongside them, not after.

Redesign (EDITORIAL — hypothesis, not fact)

This section is editorial hypothesis, not established fact. A safer 7702 could have made delegation transaction-scoped by default (auto-reverting to a plain EOA after the calling transaction completes) with a separate, more heavily warned opt-in path for "permanent" delegation, so that most batching/sponsorship use cases never leave a durable, exploitable pointer sitting in an EOA's code slot. A protocol-level registry of audited, canonical smart-account implementations (analogous to how well-known token lists reduce fake-token phishing) could let wallets render authorization prompts with meaningfully different risk badges for "delegating to Coinbase Smart Wallet's audited implementation" versus "delegating to an unverified address," rather than leaving every wallet vendor to build this from scratch. Finally, a time-locked or spend-limited variant of the delegation designator — where the pointed-to contract's authority is capped (e.g., max value moved per epoch) unless a second confirmation is given — would blunt the sweeper-contract attack pattern even when a signature is fully compromised.