Ethereum Improvement Proposal (EIP-5806) Overview

What is an EIP?

Definition and Purpose

Ethereum Improvement Proposals (EIPs) are formal documents that propose changes or enhancements to the Ethereum blockchain. They provide technical specifications and motivations for new features, standards, or processes, serving as a transparent, community-driven mechanism for Ethereum’s evolution. EIPs ensure changes are thoroughly discussed, vetted, and documented, fostering interoperability and innovation.

Types of EIPs

• Standards Track: Affect Ethereum’s protocol, including Core (consensus changes), Networking, Interface, and ERC (application standards like ERC-20).

• Informational: Provide guidelines or information without proposing changes.

• Meta: Address off-chain processes, governance, or tools.

EIP Creation and Acceptance Process

1. Proposal: An idea is discussed on forums like Ethereum Magicians.

2. Draft: The EIP is submitted to the EIPs GitHub repository with a formal structure.

3. Review: The author requests peer review.

4. Last Call: The EIP is finalized and open for final community review (typically 14 days).

5. Final: The EIP is accepted and implemented, or marked as Stagnant/Withdrawn if inactive or rejected.

EIP-5806: Delegate Call for EOAs

Overview

EIP Number: 5806
Title: EOA Delegate Transactions
Status: Stagnant
Type: Standards Track (Core)
Abstract: EIP-5806 proposes a new transaction type that allows Externally Owned Accounts (EOAs) to execute arbitrary code using a delegate-call-like mechanism, enabling EOAs to perform complex operations (e.g., batching transactions) while maintaining the EOA as the msg.sender.

EIPs It Improves or Builds On

EIP-5806 builds on EIP-7 (DELEGATECALL Opcode), which introduced the DELEGATECALL opcode for smart contracts to execute another contract’s code in the caller’s context.

• Why EIP-7?: EIP-7 enables contracts to perform delegate calls, preserving the caller’s storage and msg.sender. EIP-5806 extends this capability to EOAs, which currently cannot use DELEGATECALL.

• Motivation for Improvement: EOAs are limited to basic transactions (ETH transfers, contract deployment, or function calls). They cannot execute arbitrary code or batch operations, unlike smart contracts. EIP-5806 addresses this by allowing EOAs to leverage existing delegate call functionality, enhancing their flexibility without requiring full account abstraction (e.g., ERC-4337).

Why EIP-5806 Was Proposed

Motivation:

• EOA Limitations: EOAs, controlled by private keys, are the most common Ethereum accounts but are restricted to simple actions: sending ETH, deploying contracts, or calling contract functions. They cannot execute complex logic (e.g., batching multiple calls) or arbitrary code directly.

• Account Abstraction Challenges: Proposals like ERC-4337 aim to make accounts programmable via smart wallets, but adoption is slow due to:

  • High gas costs for deploying smart contract wallets.

  • Lack of universal dApp support for smart wallets.

  • Inability to migrate non-transferable assets (e.g., soulbound tokens, NFTs) from EOAs to smart wallets.

• User Experience (UX) Issues: Performing multiple actions (e.g., approving and transferring tokens) requires separate transactions, incurring high gas costs (21,000 gas overhead per transaction) and introducing security risks (e.g., front-running between approval and transfer).

• Goal: EIP-5806 enables EOAs to execute arbitrary code (via delegate calls to contracts like the multicall contract at 0xcA11bde05977b3631167028862bE2a173976CA11) to batch transactions, emit events, or implement custom logic, improving UX and security while requiring minimal EVM changes.

How EIP-5806 Works

Technical Approach:

• New Transaction Type: EIP-5806 introduces a transaction type that allows an EOA to initiate a delegate-call-like operation to a target smart contract.

• Delegate Call Mechanics: In a delegate call, the target contract’s code is executed, but the context (storage, balance, msg.sender) belongs to the caller. For EIP-5806:

  • The EOA specifies a target contract (e.g., a multicall contract).

  • The EVM executes the target contract’s code, but msg.sender remains the EOA’s address, and no storage is modified (since EOAs lack storage).

  • The transaction can include data to execute multiple function calls or custom logic defined in the target contract.

• Example: An EOA could delegate-call a multicall contract to:

  • Approve a token spend.

  • Transfer tokens to a DEX.

  • Swap tokens for another asset.

  • All in one transaction, reducing gas costs and risks.

• Minimal EVM Changes: The EVM is modified to allow EOAs to initiate a delegate-call-like operation, leveraging the existing DELEGATECALL opcode logic without requiring new opcodes.

Addressing EOA Lack of Code and Storage:

• Your Concern: EOAs don’t have code or storage, so how can they provide a context for a delegate call?

• Explanation: In a traditional delegate call (contract-to-contract), the caller’s storage and context are used, but EOAs lack both. EIP-5806 addresses this by:

  • No Storage Dependency: The delegate call doesn’t rely on the EOA having storage. The target contract’s code executes without modifying any storage unless explicitly programmed to interact with other contracts’ storage. For example, a multicall contract can call multiple contracts, updating their storage (e.g., token balances), without needing EOA storage.

  • Context as msg.sender and Balance: The EOA’s context in this case is its address (for msg.sender) and its ETH balance (for gas and value transfers). The delegate call ensures that all actions appear to originate from the EOA, maintaining its identity.

  • Execution Environment: The EVM treats the delegate call as executing in a “virtual” context where the EOA is the initiator. The target contract’s code runs in isolation, using the EOA’s msg.sender and balance, without needing EOA-specific code or storage.

• Analogy: Think of the EOA as a person borrowing a recipe book (target contract’s code) to cook a meal. The person doesn’t need their own kitchen (storage) or cooking skills (code); they just follow the recipe, and the meal is credited to them (msg.sender).

Technical Changes

• New Transaction Type: Adds a transaction type to the EVM that supports delegate-call-like behavior for EOAs.

• EVM Modification: Extends the DELEGATECALL opcode’s logic to handle EOA-initiated calls, ensuring the EOA’s address is preserved as msg.sender.

• Backward Compatibility: Compatible with existing contracts, as it reuses the DELEGATECALL mechanism. No changes are needed for dApps or contracts using standard interfaces (e.g., ERC-20).

• Security Considerations:

  • Ensures the target contract cannot modify non-existent EOA storage, preventing unintended side effects.

  • Mitigates risks like reentrancy by relying on existing DELEGATECALL safeguards.

  • Potential risks (e.g., malicious target contracts) require users to trust the delegate-called contract, similar to current EOA interactions.

Why and How It Solves the Problem

• Why Needed:

  • UX Improvement: Enables EOAs to batch transactions (e.g., via multicall contracts), reducing gas costs and simplifying interactions with dApps.

  • Security: Eliminates the need for multiple transactions, reducing vulnerabilities like front-running (e.g., exploiting token approvals).

  • Accessibility: Allows EOA users to access smart contract-like functionality without migrating to smart wallets, preserving non-transferable assets.

• How It Solves:

  • By enabling delegate calls, EOAs can execute complex logic defined in trusted contracts (e.g., multicall or custom logic contracts).

  • The EVM’s delegate call mechanism ensures the EOA remains the msg.sender, maintaining security and compatibility.

  • Example: An EOA delegate-calls a multicall contract to execute approve and transferFrom in one transaction, saving ~21,000 gas per eliminated transaction and reducing exploit windows.

Conclusion

EIP-5806 is a pragmatic enhancement to EOAs, bridging the gap between their simplicity and the flexibility of smart contracts. By leveraging a delegate-call-like mechanism, it empowers EOAs to execute arbitrary code, improving UX and security without requiring the complex infrastructure of full account abstraction. Its reliance on existing EVM mechanics (EIP-7’s DELEGATECALL) ensures minimal disruption, making it a feasible short-term solution for Ethereum’s evolving ecosystem.