Go to Home
Web3 security pattern.
Pectra Competition
Web3 security pattern.
EIP-7702
EIP-7702 lets EOAs set account code, enabling delegation, batching, sponsorship, and privilege management without smart contractsEIP-7702 allows EOAs to set account code, enabling delegation, batching, sponsorship, and enhanced privilege management.

EIP-7702

Table of Contents

Heading 2
Heading 3
Heading 4

What is this EIP about?

EIP-7702 introduces a new transaction type that enables Ethereum externally owned accounts (EOAs) to permanently set their account code, creating a mechanism for delegation. This proposal aims to solve limitations in EOA functionality by allowing features like batching transactions, sponsorship, and privilege management, which previously required smart contracts.

Why EIP-7702 is Needed

EOAs lack programmability compared to smart contracts, limiting their efficiency and flexibility. Existing workflows, such as multi-step ERC-20 approvals or enabling transactions from sub-keys, are cumbersome or insecure. By providing a mechanism to extend EOAs' behavior, this EIP bridges the gap between EOAs and contract accounts, enhancing usability in areas like gas optimization, security, and interoperability.

What does this EIP propose, and how does it function?

Key Mechanism:

  1. New Transaction Type: Introduces a "set code transaction" (SET_CODE_TX_TYPE 0x04) where EOAs set delegation designations.
  2. Delegation Designations: An opcode (0xef) serves as a pointer for the EOA’s executable code. This allows specific code to execute transactions on behalf of the EOA.
  3. Authorization Tuples: Contains information like the chain ID, account address, nonce, and signature, enabling granular control.

How It Works:

  • A list of authorization tuples is processed to link executable code to the EOA.
  • Gas costs are allocated based on authorization tuple processing and whether the designated code already exists.
  • Accounts can "clear" their delegation designation, reverting to EOA defaults for functionality like transaction origination.

What are the security implications of this EIP?

  1. Delegation Risks: Poorly designed delegation contracts may expose EOAs to unauthorized actions. Replay attacks, gas griefing, and arbitrary function calls need mitigations like nonce verification and well-formed authorization.
  2. Breaks Assumptions: Reentrancy checks relying on tx.origin == msg.sender become ineffective, potentially impacting existing smart contract assumptions.
  3. Relayer Exploits: Authorized accounts could deplete relayer resources via invalidation attacks or asset transfers. Systems may require bonds or reputation tracking.
  4. Transaction Propagation Challenges: Dynamic nonce changes and balance updates may complicate mempool behavior and transaction invalidation.
  5. Front-running Concerns: Smart contract wallets must account for initial account configuration to avoid unauthorized initialization.

The EIP includes mechanisms like authorization checks and signature validation to mitigate risks, but developers and integrators must carefully design delegation implementations.

‍