EIP-7702 (Set EOA Account Code)

What Is EIP-7702?

EIP-7702, formally titled "Set EOA Account Code," is an Ethereum protocol upgrade that allows externally owned accounts to temporarily adopt the code of a smart contract. Before EIP-7702, Ethereum had two rigid account types: EOAs controlled by a private key (capable of signing transactions but unable to run code) and contract accounts (capable of running code but unable to initiate transactions). EIP-7702 bridges this gap by letting an EOA point to a smart contract wallet implementation and execute its logic as if the EOA itself were that contract.

Proposed by Vitalik Buterin in May 2024, EIP-7702 was designed as a pragmatic replacement for EIP-3074, which had introduced AUTH and AUTHCALL opcodes but raised compatibility concerns with the existing ERC-4337 smart account ecosystem. EIP-7702 achieves similar goals through a cleaner mechanism: a new transaction type that writes a delegation pointer into the EOA's code field, rather than adding new opcodes to the EVM.

The proposal was included in the Pectra network upgrade, which activated on Ethereum mainnet on May 7, 2025. Pectra (a portmanteau of Prague and Electra, the execution and consensus layer names) was one of Ethereum's largest upgrades, and EIP-7702 was its headline feature for wallet user experience.

How It Works

EIP-7702 introduces a new transaction type (type 0x04, called a "set code transaction") that carries an authorization list alongside the standard transaction fields. Each entry in the authorization list is a signed tuple that grants delegation from a specific EOA to a specific contract address.

The Authorization Tuple

Each authorization in the list follows the format: [chain_id, address, nonce, y_parity, r, s]. The fields serve distinct purposes:

• chain_id: the network where the authorization is valid. Setting this to 0 makes the authorization valid on any EVM chain, though this carries additional security risk.
• address: the delegate contract whose code the EOA will adopt.
• nonce: the current nonce of the authorizing EOA, preventing replay of old authorizations.
• y_parity, r, s: the ECDSA signature components proving the EOA holder authorized this delegation.

The signature covers keccak256(0x05 || rlp([chain_id, address, nonce])), where 0x05 is a magic byte distinct from the transaction type byte to prevent cross-context signature reuse.

The Delegation Designator

When the EVM processes a valid authorization, it writes a 23-byte delegation designator into the EOA's code field: 0xef0100 || <20-byte contract address>. The 0xef prefix was reserved by EIP-3541 as an invalid leading opcode, so the EVM can reliably distinguish a delegation pointer from regular bytecode.

When any subsequent operation calls the EOA, the EVM detects this prefix, loads the bytecode from the referenced contract, and executes it in the context of the EOA. This means the delegate code operates on the EOA's balance, storage, and address: from the perspective of other contracts, the EOA is behaving like a smart contract.

Execution Flow

1. The EOA holder signs one or more authorization tuples designating a delegate contract
2. A type-0x04 transaction is submitted containing these authorizations (the EOA can submit it themselves, or a third party can submit it on their behalf)
3. The EVM validates each authorization signature and writes the delegation designator to each EOA's code field
4. The transaction's data field is then executed against the EOA, which now runs the delegate contract's logic
5. The delegation persists until the EOA submits a new authorization pointing to a different contract, or revokes delegation by setting the address to itself

// Simplified authorization structure
authorization_list = [
  {
    chain_id: 1,          // Ethereum mainnet
    address: "0xAbC...",  // Delegate contract (e.g., a smart wallet)
    nonce: 42,            // EOA's current nonce
    // ECDSA signature (y_parity, r, s)
  }
]

// Resulting code written to the EOA:
// 0xef0100 || 0xAbC...  (23 bytes total)

EIP-7702 vs. ERC-4337 vs. EIP-3074

EIP-7702 exists alongside two other account abstraction approaches, each with different tradeoffs:

ERC-4337 deploys a dedicated smart contract wallet at a new address, processing UserOperations through a separate mempool and EntryPoint contract. It requires no protocol changes but means users must migrate to a new address. EIP-7702 takes the opposite approach: the user keeps their existing EOA address and gains smart wallet features through delegation.

The two are complementary, not competing. Users who already have an ERC-4337 smart wallet continue using it. Users who want to keep their existing EOA address and add smart wallet capabilities use EIP-7702. Most production wallet stacks now support both paths.

Use Cases

Transaction Batching

Without EIP-7702, an EOA must submit separate transactions for each on-chain action: one to approve a token, another to swap it, and a third to stake the result. With EIP-7702, the EOA delegates to a smart wallet contract that can execute all three operations atomically in a single transaction. If any step fails, the entire batch reverts.

Gas Sponsorship

Because the authorization tuple can be submitted by a third party, a relayer or paymaster can pay the gas fee on behalf of the EOA holder. The EOA signs the authorization offline, the sponsor submits the type-0x04 transaction and pays gas, and the EOA's delegation is set without the user needing ETH in their account. This enables gasless onboarding flows where new users interact with dApps before acquiring ETH.

Session Keys

By delegating to a contract that implements session key logic, an EOA can grant temporary, scoped permissions to a sub-key. For example, a gaming dApp could receive a session key that is authorized to spend up to 0.01 ETH per transaction for the next 24 hours, without the user approving every action. The delegate contract enforces these constraints on-chain.

Social Recovery and Key Rotation

EOAs have historically been irrecoverable: lose the private key, lose the account. With EIP-7702, an EOA can delegate to a contract that implements social recovery logic, allowing a set of guardians to rotate the controlling key if the original is lost. This was previously only possible with dedicated smart contract wallets.

Programmable Spending Policies

Delegate contracts can enforce arbitrary spending rules: daily transfer limits, whitelisted destination addresses, time-locked withdrawals, or multi-party approval for large transfers. These policies apply at the protocol level, not just in the wallet UI, making them resistant to compromised front-ends.

Risks and Considerations

Phishing and Malicious Delegation

The most significant risk introduced by EIP-7702 is delegation phishing. If an attacker tricks a user into signing an authorization tuple pointing to a malicious contract, the attacker gains persistent execution control over the EOA. Unlike a token approval (which only exposes one asset), a malicious delegation can drain the entire account: ETH, all ERC-20 tokens, and NFTs.

Research has documented real-world exploitation of this vector. A single signed authorization can convert an EOA into a permanent proxy resolving to attacker-controlled logic. Wallets must clearly communicate what an authorization tuple does before prompting the user to sign, and users should only delegate to audited, well-known contracts.

Cross-Chain Replay

Authorization tuples with chain_id set to 0 are valid on any EVM-compatible chain. An attacker who obtains such a signature can deploy a malicious contract at the same address on a different chain and use the replayed authorization to take control of the EOA there. Users and wallets should avoid chain-agnostic authorizations unless explicitly required.

Persistent Delegation

Unlike the original description suggesting "temporary" delegation, the code designation written by EIP-7702 persists across transactions until explicitly revoked. If a user delegates to a contract and forgets about it, all future interactions with that EOA will route through the delegate code. Users must actively manage their delegation state.

Smart Contract Risk

The security of a delegated EOA depends entirely on the delegate contract. A bug in the delegate code, an upgrade to a malicious implementation (if the delegate is a proxy contract), or an exploit in its access control logic can compromise all EOAs that have delegated to it. This concentrates risk in the delegate contract in a way that traditional EOAs do not face.

Why It Matters

EIP-7702 represents Ethereum's pragmatic bridge between the simplicity of EOAs and the power of smart accounts. Rather than forcing a binary choice between keeping your existing address or gaining programmable wallet features, EIP-7702 lets every EOA opt into smart contract functionality on demand. This lowers the barrier to account abstraction adoption by removing the migration cost that has slowed ERC-4337 uptake.

For the broader ecosystem, EIP-7702 makes user-friendly features like gas sponsorship and session keys available to every existing Ethereum account. This is particularly relevant for payment applications and embedded wallets where onboarding friction must be minimal. For a deeper technical analysis, see the EIP-7702 code delegation research article and the Pectra upgrade wallet impact analysis.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.