EIP-7702: How Code Delegation Turns Every Ethereum EOA into a Smart Wallet

Every Ethereum wallet address that people have used for years is an externally owned account, or EOA. EOAs are controlled by a single private key with no programmable logic: one key signs every transaction, there are no spending limits, no batch operations, and no recovery options if the key is lost. EIP-7702 changes this by letting any EOA delegate its code execution to a deployed smart contract, gaining smart wallet capabilities without migrating to a new address.

Authored by Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett, EIP-7702 shipped as part of the Pectra upgrade on May 7, 2025. By September 2026, over 27 million Ethereum accounts have used it, making code delegation one of the most rapidly adopted protocol changes in Ethereum's history.

What Is EIP-7702?

EIP-7702 introduces a new transaction type (0x04, called SET_CODE_TX_TYPE) that allows an EOA to point to an existing smart contract's bytecode. The protocol writes a 23-byte delegation designator into the EOA's code field: 0xef0100 || contract_address. When any call hits the EOA, the EVM loads and executes the referenced contract's code using the EOA's own storage and balance.

The 0xef prefix comes from EIP-3541, which banned this byte as a leading opcode. That ban now serves as a reliable signal to the EVM: this is not regular bytecode, it is a delegation pointer. The account does not become a contract in the traditional sense. It retains its private key, can still sign normal transactions, and can change or clear the delegation at any time.

The Authorization Tuple

To set a delegation, the EOA owner signs an authorization tuple containing the target chain ID, the delegate contract address, and a nonce. The signature uses a dedicated domain separator (MAGIC = 0x05) to prevent cross-protocol replay. Multiple authorization tuples can be included in a single transaction, allowing one relayer to set delegations for many accounts at once.

Revocation is simple: An EOA can clear its delegation at any time by signing a new authorization pointing to the zero address (0x0000...0). This resets the code field entirely, returning the account to a standard EOA.

Processing Flow

When a Type 4 transaction arrives, the protocol processes each authorization tuple in sequence:

1. Verify the chain ID matches (or is 0 for cross-chain validity)
2. Recover the signer address via ecrecover
3. Confirm the account has no existing code or already has a delegation designator
4. Validate the nonce matches the account's current nonce
5. Write the delegation designator to the account's code field and increment the nonce

Invalid tuples are skipped without halting the transaction. This permissive design means a batch of authorizations succeeds partially rather than reverting entirely if one entry fails.

Why EIP-7702 Replaced EIP-3074

EIP-7702 was not the first attempt at giving EOAs smart contract powers. EIP-3074, proposed in October 2020, introduced two new opcodes (AUTH and AUTHCALL) that let an EOA authorize an “invoker” contract to act on its behalf. EIP-3074 was initially accepted for inclusion in Pectra, but the ERC-4337 community raised concerns about fundamental incompatibilities with the account abstraction roadmap.

The core issues with EIP-3074 were threefold: its persistent invoker contracts maintained authorization state between transactions, creating ongoing trust assumptions; a vulnerability in a popular invoker could compromise many users simultaneously; and the new opcodes added permanent protocol complexity that would likely become technical debt once account abstraction matured.

Vitalik proposed EIP-7702 as an alternative that achieved the same goals without new opcodes, with better forward compatibility with ERC-4337, and with per-transaction delegation instead of persistent authorization. The core developers accepted the replacement within days.

EIP-7702 vs ERC-4337: Complementary, Not Competing

A common misconception is that EIP-7702 replaces ERC-4337. In practice, they work together. ERC-4337 provides a complete infrastructure layer for smart accounts: bundlers that aggregate UserOperations, paymasters that sponsor gas, and the EntryPoint contract that validates and executes operations. EIP-7702 extends this infrastructure to the billions of existing EOAs.

Most production wallets now use EIP-7702 delegations pointing to ERC-4337-compatible implementations, letting EOAs plug into the existing bundler and paymaster ecosystem without migrating addresses.

The practical pattern: Wallets use EIP-7702 to delegate an EOA to an ERC-4337-compatible smart account implementation, then use ERC-4337 bundlers and paymasters for relaying and gas sponsorship. The two standards form a complete stack, not a choice between alternatives.

What EIP-7702 Unlocks for Users

Code delegation transforms what an Ethereum wallet can do. These capabilities were previously available only to users who abandoned their EOA and migrated to a dedicated smart contract wallet address. EIP-7702 brings them to every existing account.

Batch Transactions

Multiple operations execute atomically in a single transaction. A token swap that previously required separate approve and swap transactions now happens in one step, reverting entirely if any operation fails. This eliminates the dangling approval problem where users leave unlimited token allowances on decentralized exchanges.

Gas Sponsorship

Through integration with ERC-4337 paymasters, applications can cover gas fees on behalf of users. A new user can interact with a dApp without holding any ETH, paying fees in stablecoins or having the application absorb the cost entirely. This enables true gasless onboarding experiences.

Session Keys

Session keys are temporary secondary signing keys scoped by time, target contract, and spending limit. A gaming application can request a session key valid for two hours, limited to calling the game contract with a maximum spend of 0.05 ETH. The user approves once and plays without further wallet popups, while the master key remains secure.

Spending Limits and Security Rules

Delegated smart contract logic can enforce transfer ceilings, destination allowlists, rate limits, and time-delayed withdrawals. These programmable guardrails let users define security policies at the account level rather than relying entirely on a single private key.

Social Recovery

Social recovery schemes let designated guardian addresses collectively rotate a wallet's signing key. With EIP-7702, an EOA can delegate to a recovery-enabled implementation, gaining this protection without abandoning its address. One important caveat: the original EOA private key always retains the ability to change or clear the delegation, so recovery designs must account for this.

Adoption and Wallet Ecosystem

Adoption since Pectra has been substantial. Within the first week, over 11,000 authorizations were processed across approximately 100 unique delegate contracts. By September 2026, the numbers reflect mainstream integration: over 27 million delegated accounts, more than 7 million set-code transactions, and nearly 7,000 unique delegate contracts deployed.

The pattern is clear: rather than asking users to migrate to new smart contract wallet addresses, the industry is upgrading existing EOAs in place. This preserves token balances, NFT ownership, ENS names, and onchain identity tied to the original address.

Security Risks and Tradeoffs

EIP-7702 introduces a qualitatively new attack surface. Understanding these risks is essential for both users and developers building on code delegation.

Cross-Chain Replay

Authorization tuples signed with chain_id = 0 are valid on every EVM-compatible chain. A phishing attack that tricks a user into signing a single authorization can propagate across Ethereum, Arbitrum, Optimism, Base, and any other chain where the same delegate contract exists. Users and wallets should default to chain-specific authorizations and treat chain_id = 0 signatures with extreme caution.

Delegation Phishing

An authorization tuple is just a signature. Attackers can trick users into signing delegations that point to malicious contracts, granting persistent execution control over the account. Research published in late 2025 found that a significant portion of early delegations pointed to malicious contracts, resulting in confirmed losses. Wallet UIs must clearly communicate what a delegation authorization means and to which contract the user is delegating.

Initialization Frontrunning

If delegation and initialization happen in separate transactions, an attacker can frontrun the initialization call and take control of the delegated logic before the legitimate owner configures it. The mitigation is straightforward: combine delegation and initialization atomically in the same transaction, or use initialization patterns that require the owner's signature.

Storage Collisions

Storage persists across re-delegations. If a user switches from one delegate contract to another with a different storage layout, leftover data can cause undefined behavior. Delegate contracts should use ERC-7201 namespaced storage to isolate their state and avoid collisions.

Broken Assumptions

The common Solidity pattern tx.origin == msg.sender can no longer reliably distinguish EOAs from contracts. Delegated EOAs can execute arbitrary code, so protocols that relied on this check for reentrancy protection or bot prevention need to update their logic. Explicit reentrancy guards must replace origin-based checks.

What This Means for the Broader Wallet Landscape

EIP-7702 collapses the distinction between EOAs and smart accounts on Ethereum. The implications extend beyond a single chain.

For EVM-compatible chains, code delegation is already spreading. Any L2 or sidechain that tracks Ethereum's EVM specification inherits EIP-7702 support, meaning the same wallet UX improvements become available across the EVM ecosystem without per-chain development effort.

For non-EVM ecosystems, the competitive pressure is real. Bitcoin's Layer 2 networks, Solana, and other chains face user expectations shaped by batch transactions, gas sponsorship, and session keys. The bar for what constitutes acceptable wallet UX rises across the industry.

This dynamic works in favor of self-custodial solutions everywhere. As Ethereum wallets become more capable without sacrificing self-custody, users grow accustomed to managing their own keys with smart guardrails. That learned behavior translates directly when those same users interact with Bitcoin L2s like Spark, where self-custody is the default and the goal is making it feel effortless. Cross-chain settlement layers benefit when every ecosystem raises the floor for wallet UX.

Looking Ahead

EIP-7702 is a transitional mechanism. The long-term Ethereum roadmap envisions EIP-7560, which would enshrine account abstraction at the protocol level, making the EOA-versus-contract distinction irrelevant entirely. Until then, EIP-7702 serves as the bridge: it lets existing infrastructure treat every account as programmable while the ecosystem converges on a unified account model.

For developers building wallet experiences, the path is practical. The combination of EIP-7702 delegation and ERC-4337 infrastructure provides a production-ready stack today. For users, the transition is invisible: their existing address gains new powers without any action beyond a wallet update.

Improvements in wallet UX on Ethereum and across EVM chains lower the barrier for self-custodial payments everywhere. For those building on Bitcoin L2 infrastructure, the Spark SDK and documentation offer a starting point for integrating similar self-custodial payment experiences on Bitcoin. Readers interested in how embedded wallets are evolving across chains can explore the embedded wallets research for a Bitcoin-focused perspective.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.