EIP-3074: EOA Delegation with AUTH and AUTHCALL

Definition

EIP-3074, or Ethereum Improvement Proposal 3074, introduces two new Ethereum Virtual Machine (EVM) opcodes, AUTH and AUTHCALL, designed to enhance the functionality of Externally Owned Accounts (EOAs). An EOA is the most common type of Ethereum account, controlled by a private key, similar to a traditional bank account where you hold the keys. Unlike smart contract accounts, EOAs historically lacked the ability to execute complex logic or delegate control over their assets to another entity. EIP-3074 addresses this limitation by allowing an EOA to temporarily delegate its control to a smart contract, known as an "invoker." This delegation enables the invoker contract to initiate transactions on behalf of the EOA, effectively allowing EOAs to mimic some advanced features typically associated with smart contract wallets without requiring the EOA holder to deploy a new contract or migrate funds. The core idea is to provide a flexible framework for developers to build novel transaction schemes for EOAs, bridging the gap between the simplicity of EOAs and the programmability of smart contracts.

EIP-3074: An Ethereum Improvement Proposal introducing AUTH and AUTHCALL opcodes, enabling Externally Owned Accounts (EOAs) to delegate transaction control to a smart contract.

Key Takeaway

The fundamental takeaway from EIP-3074 is its capacity to empower existing Externally Owned Accounts (EOAs) with capabilities traditionally reserved for smart contract wallets. This means an EOA can, through a signed authorization, allow a designated smart contract to perform actions on its behalf, such as sending transactions, interacting with other contracts, or even paying gas fees for the EOA. This delegation significantly enhances the user experience on Ethereum by enabling features like gas sponsorship, batch transactions, and custom transaction logic directly from an EOA, all while maintaining the EOA's original address and private key control. It represents a significant step towards a more flexible and user-friendly account abstraction model on Ethereum, without forcing users to abandon their existing EOA infrastructure.

Mechanics

EIP-3074 operates through the introduction of two specific EVM opcodes: AUTH (0xf6) and AUTHCALL (0xf7). The process begins with an EOA holder signing a message that authorizes a specific "invoker" smart contract to act on their behalf. This signature is crucial as it cryptographically proves the EOA's intent to delegate control. The signed message typically includes the address of the invoker contract and a nonce to prevent replay attacks.

Once the EOA has provided this valid signature, the invoker contract can then utilize the AUTH opcode. The AUTH opcode takes the EOA's signature and the invoker's address as inputs. When executed, AUTH verifies the signature against the EOA's address and, if valid, sets a special context variable called authorized within the current execution frame. This authorized variable temporarily stores the address of the EOA that has granted delegation. It's important to understand that this authorization is not permanent; it's typically valid for a specific transaction or a set of transactions defined by the signed message.

Following a successful AUTH operation, the invoker contract can then use the AUTHCALL opcode. The AUTHCALL opcode functions similarly to the existing CALL opcode but with a critical distinction: any call made using AUTHCALL will appear to originate from the address stored in the authorized context variable, rather than from the invoker contract itself. This means that if the EOA "Alice" has authorized the invoker contract "InvokerX," then any AUTHCALL initiated by InvokerX will be treated by other smart contracts as if Alice herself made the call. This mechanism allows the invoker to perform actions like transferring tokens, interacting with DeFi protocols, or executing complex multi-step operations on behalf of Alice, all while the underlying transactions are still attributed to Alice's EOA. The authorized variable is specific to the current execution frame, meaning nested calls can have different authorized accounts or no authorized account at all, providing a secure and isolated delegation environment.

Trading Relevance

EIP-3074 introduces several profound implications for cryptocurrency trading, particularly for users relying on Externally Owned Accounts (EOAs). One of the most significant benefits is the potential for gas sponsorship. With EIP-3074, an EOA can authorize an invoker contract to pay for its transaction fees. This means traders could potentially execute trades without needing to hold ETH for gas, as the invoker (which could be a centralized exchange, a DeFi protocol, or a specialized service) covers the cost. This significantly lowers the barrier to entry for new users and streamlines the trading experience, especially during periods of high network congestion where gas prices can be prohibitive.

Furthermore, EIP-3074 facilitates batch transactions and custom transaction logic. Imagine a scenario where a trader wants to approve a token for spending on a decentralized exchange (DEX) and then immediately execute a swap. Currently, this requires two separate transactions, each incurring gas fees and requiring user confirmation. With EIP-3074, an EOA could authorize an invoker contract to perform both actions in a single, atomic transaction. This not only saves on gas costs but also improves efficiency and reduces the risk of front-running between the approval and swap steps. Invoker contracts could also implement sophisticated trading strategies, such as automated rebalancing, stop-loss orders, or complex arbitrage opportunities, all executed on behalf of the EOA without the EOA holder needing to manually sign each individual step. This opens up possibilities for more advanced, programmatic trading directly from an EOA, blurring the lines between traditional EOA usage and the capabilities of smart contract-based trading bots.

Risks

While EIP-3074 offers substantial benefits, it also introduces new vectors for risk that users must understand. The primary risk lies in the delegation of control itself. When an EOA signs a message authorizing an invoker contract, it is essentially granting that contract the ability to act on its behalf. If the invoker contract is malicious or contains vulnerabilities, it could potentially drain the EOA's funds or execute unauthorized transactions. Users must exercise extreme caution when choosing which invoker contracts to authorize. It is paramount to only delegate control to reputable, audited, and well-understood smart contracts. A signed authorization, once broadcast, can be used by the invoker to perform actions, and revoking this authorization might not be as straightforward as simply not signing future transactions, depending on the scope of the initial authorization.

Another significant concern is the scope of authorization. The signed message that enables AUTH can define the specific actions an invoker is allowed to perform, or it could be broad, granting extensive control. A poorly designed or overly permissive authorization could lead to unintended consequences. For instance, if an EOA authorizes an invoker to spend any amount of a specific token, that invoker could potentially spend all of it. Unlike traditional smart contract approvals (e.g., ERC-20 approve), where a specific spending limit is set, the delegation via EIP-3074 can be more encompassing. Users need to carefully review the details of the authorization message they are signing, understanding precisely what permissions they are granting and for how long. The "all or nothing" nature of delegating control to a specific invoker for a defined scope means that a single mistake in authorization could have severe financial repercussions. Therefore, robust user interfaces and clear communication from dApps implementing EIP-3074 will be essential to mitigate these risks and ensure users make informed decisions about their delegated permissions.

History and Examples

EIP-3074 emerged from the ongoing pursuit of account abstraction on Ethereum, a long-standing goal to make all accounts behave like smart contracts, offering greater flexibility and programmability. Historically, Ethereum has distinguished between EOAs (controlled by private keys) and contract accounts (controlled by code). This distinction created a dichotomy where EOAs were simple but limited, while contract accounts were powerful but required deployment and management. EIP-3074, first proposed by Sam Wilson, Matt Garnett, and others, represents a protocol-level approach to bridge this gap for existing EOAs. It was developed in parallel with other account abstraction efforts, most notably ERC-4337. While ERC-4337 focuses on a smart contract-based solution that doesn't require protocol changes, EIP-3074 introduces new opcodes directly into the EVM, offering a different pathway to similar functionalities for existing EOAs.

A practical example of EIP-3074's utility could be seen in a decentralized application (dApp) that wants to offer a seamless user experience. Imagine a user wanting to participate in a liquidity pool, which typically involves approving two tokens and then adding them to the pool. With EIP-3074, the dApp could present a single authorization request to the user. Once signed, an invoker contract managed by the dApp could then use AUTHCALL to execute all necessary approvals and the final liquidity addition in a single, bundled transaction, with the dApp potentially even sponsoring the gas fees. Another compelling use case involves social recovery. An EOA holder could authorize a specific smart contract to initiate a recovery process if their private key is lost, allowing trusted guardians to approve a new key. This moves beyond simple transaction delegation to more complex account management. Furthermore, EIP-3074 could enable subscription payments directly from an EOA, where a user authorizes a contract to make recurring payments up to a certain limit, without needing to manually confirm each payment. These examples highlight how EIP-3074 aims to enhance user convenience and expand the capabilities of standard Ethereum wallets.

Common Misunderstandings

One of the most prevalent misunderstandings surrounding EIP-3074 is the belief that it converts an EOA into a smart contract account. This is incorrect. EIP-3074 does not alter the fundamental nature of an EOA. An EOA remains an EOA, still controlled by its private key. Instead, EIP-3074 provides a mechanism for an EOA to delegate its transaction-initiating authority to a smart contract. The EOA's address remains the origin of the transaction from the perspective of other contracts when AUTHCALL is used, but the actual execution logic is handled by the invoker contract. This distinction is crucial: the EOA doesn't become programmable itself; it merely grants a smart contract the temporary right to act as its proxy. The private key still holds ultimate control, and the delegation can be thought of as a temporary, revocable power of attorney, not a change in account type.

Another common misconception is that EIP-3074 provides full account abstraction on its own. While it is a significant step towards account abstraction, it is not the complete solution. Full account abstraction aims for a unified account model where all accounts can have arbitrary verification logic and pay for gas in any token, among other features. EIP-3074 primarily addresses the delegation of transaction execution from EOAs. It doesn't inherently change how gas is paid (though it enables gas sponsorship) or allow for arbitrary signature schemes directly within the EOA. It also doesn't solve the issue of existing smart contract wallets not being able to convert into EOAs. Furthermore, some users might mistakenly believe that authorizing an invoker contract means their private key is shared or compromised. This is false. The EOA's private key is used only to sign the initial authorization message; it is never exposed to the invoker contract. The security of the EOA's private key remains paramount and separate from the delegation mechanism. Understanding these nuances is essential for correctly appreciating EIP-3074's scope and limitations within the broader Ethereum ecosystem.

Summary

EIP-3074 introduces the AUTH and AUTHCALL opcodes to the Ethereum Virtual Machine, fundamentally enhancing the capabilities of Externally Owned Accounts (EOAs). By enabling EOAs to delegate transaction control to smart contracts, this proposal allows existing wallets to access advanced features like gas sponsorship, batch transactions, and custom logic, previously exclusive to smart contract accounts. This mechanism involves an EOA signing a message to authorize an "invoker" contract, which then uses AUTH to establish the EOA as the authorized sender and AUTHCALL to execute transactions on its behalf. While offering significant improvements in user experience and flexibility, EIP-3074 also necessitates careful consideration of the risks associated with delegating control to invoker contracts. It represents a pivotal step in Ethereum's journey towards a more comprehensive account abstraction, providing a flexible and powerful framework for developers and users alike, without altering the core nature of EOAs.