Skip to content

EIP-7702: Set EOA Account Code

Overview

EIP-7702 (Set EOA account code) is an Ethereum improvement proposal put forward by Vitalik Buterin and others, allowing Externally Owned Accounts (EOAs) to set their own contract code during transaction execution. Afterwards, the EOA can function as a smart contract account.

This proposal is considered one of the core features of Ethereum's Pectra upgrade (Prague-Electra, completed in early 2025), aiming to endow EOAs with smart contract capabilities, providing a highly compatible and flexible path toward account abstraction.

Core Features

The core mechanism of EIP-7702 is: - Set Code: Transactions include an authorization list. Once the user signs the authorization, the EOA's code is set to a special "Delegation Designator" (format: 0xef0100... + contract address). - Persistent Effect: Once set, the EOA behaves like that smart contract in every subsequent transaction until the user sends another instruction to modify it. This means users can "upgrade" their wallets, gaining long-term features like multisig and social recovery. - Revocability: Users can sign a new authorization instruction at any time to reset the code to empty (or point to the zero address), thereby "downgrading" the account back to a regular EOA. - Cross-Transaction State: Since the code is persistent, EOAs can have more stable contract state and logic, rather than just temporary script execution.

Batch Transactions and Automation

Through persistent or temporary code delegation, EOAs can achieve: - Batch Operations: Atomically execute a series of transactions (e.g., Approve + Swap). - Automation: Authorize contracts to automatically execute operations based on preset conditions.

Gas Sponsorship (Paymaster)

Supports third-party Gas payment: - Token Payment: Users can pay Gas using tokens like USDC, converted by a Relayer. - Application Subsidies: Project teams can subsidize Gas fees for users, lowering the barrier to entry.

Security Enhancements

  • Permission Control: By delegating to specific smart contracts, EOAs can limit spending allowances for specific DApps.
  • Social Recovery: If the private key is lost, account control can be reset through preset Guardians (i.e., modifying the delegated code).
  • Quantum Resistance Preparation: In the future, quantum-resistant signature algorithms can be supported by upgrading the delegated contract code without migrating assets.

Mechanism Principles

EIP-7702 introduces a new transaction type (Transaction Type 4), which contains an authorization_list. - Each authorization entry includes: [chain_id, address, nonce, y_parity, r, s]. - The address here is the target contract address the user wishes the EOA to delegate to. - When the transaction is included, if signature verification passes, the EOA's code field is updated to special bytecode pointing to that address. - During EVM execution, any operation that loads the EOA's code will automatically load and execute the target contract's code.

Relationship with Other Proposals

EIP-7702 vs EIP-3074: - Persistence: EIP-3074 is based on AUTH/AUTHCALL opcodes, where authorization is only valid within a single transaction (or maintained through more complex mechanisms), primarily focusing on temporary "caller" permissions. EIP-7702 directly modifies account state, supporting persistent upgrades. - Future Compatibility: EIP-7702's design is closer to the final account abstraction goal and is considered the better solution for the evolution of Ethereum's account system, thus replacing EIP-3074 in the Pectra upgrade.

EIP-7702 vs ERC-4337: - Infrastructure: ERC-4337 requires an independent UserOps mempool and Bundler network. EIP-7702 directly uses the existing Ethereum transaction mempool. - Interoperability: EIP-7702 can be designed to be compatible with ERC-4337. For example, an EOA can delegate to a contract that implements the ERC-4337 interface, allowing EOAs to be recognized and operated by Bundlers.

Use Cases

  1. Wallet Upgrades: Existing MetaMask users can upgrade their accounts to multisig wallets or wallets supporting social recovery with one click, without changing addresses.
  2. Long-term Authorization: Users can authorize an automated investment contract to manage their funds long-term without signing for each operation.
  3. Seamless Interactions: Through session keys and persistent code, achieve high-frequency seamless interactions for blockchain games.

Security Considerations

  • Malicious Contract Risk: If a user is tricked into signing an authorization pointing to a malicious contract, that contract can fully control the user's EOA, including transferring all assets. Therefore, wallets must implement strict whitelisting or risk warnings for target authorization addresses.
  • Revocation Mechanism: It must be ensured that users always retain the highest authority to reset code, preventing being "locked out" by a malicious contract.