# EIP-3074 Explained

By [PowerPool Research](https://paragraph.com/@cvp) · 2024-05-13

---

**TL:DR**

Account Abstraction is still one of the major hurdles of Ethereum developers. The recently approved EIP-3074 aims to take the first step towards bridging the gap between the EVM and the UX of traditional financial systems.

By adding 2 new opcodes - `AUTH` and `AUTHCALL`, EIP-3074 gives EOAs (Externally Owned Accounts) the functionality of SCAs (Smart Contract Accounts) and will change how users interact with the EVM.

**EIP-3074 aims to “supercharge” EOAs!**

Authorized transactions unlock the following for users’ EOAs:

*   Sponsored transactions
    
*   Performing multiple actions in one transaction
    
*   A pathway to asset recovery in case of private key loss
    

However, with all its benefits, EIP-3074 comes with some potential downsides:

*   Security concerns. A malicious invoker can steal funds from users.
    
*   Potential issues with Ethereum upgrades down the road
    

**Current downsides of EOAs**
-----------------------------

EOAs are in essence just a stored private key that encodes the user’s public key and blockchain address. While EOAs align with the core principle of asset self-custody on the blockchain, they fall short in providing the user experience that traditional wallet users are accustomed to.

The limitations of modern EOAs can be summarized by the following:

*   Each on-chain action requires a dedicated transaction (even more in case if token approval is needed)
    
*   ETH is required to perform all on-chain actions
    
*   It is impossible to recover funds if the private key is lost
    

EIP-3074 is aimed to address these issues and enhance the UX of EOAs. By serving as a form of native account abstraction, this upgrade makes a crucial step in Ethereum’s journey towards reaching the milestone of the next billion users.

### **Motivation behind EIP-3074**

There have been frequent requests to expand functionality of the EOAs, including adding features like batch processing, gas sponsorship, expiration times, and scripting. However, such additions can increase the complexity and rigidity of the protocol, and broaden its vulnerability to attacks.

This EIP takes a different route. Instead of building these functionalities directly into the protocol as part of the transaction validity requirements, it allows users to delegate control of their EOA to a contract. This approach offers developers a flexible framework to create unique transaction schemes for EOAs, effectively letting an EOA operate like a smart contract wallet without needing to deploy an actual contract.

Though this EIP offers significant advantages for individual users, the primary motivation behind it is "sponsored transactions." This means that the cost of a transaction is paid by a different account than the one initiating it. Given the substantial growth of tokens on Ethereum, it's become common for EOAs to hold valuable assets without having any ether. Currently, these assets must be converted to ether to cover gas fees. Yet, without ether for the conversion, this becomes a deadlock. Sponsored transactions break this cycle by allowing another account to cover the fees, enabling EOAs to operate even without holding ether.

**How it works**
----------------

A new context variable `authorized` is introduced. This variable is valid for the current execution context only (i.e., there can be several `authorized` values for the same contract, so long as they remain in separate call hierarchies). This variable stores the address of the account that has authorized (hence the name) the contract in question to act on its behalf **in the current execution context**.

_It must be stated that the execution context is mutated under nested calls. Therefore, a call within a call has a context distinct from that of the parent call._

### **Setting the authorized context variable**

For the purposes of setting the `authorized` context variable, a new opcode `AUTH 0xf6` is introduced. This opcode takes in the address of the authorizer (`authority` in the specification) and a specification of a contiguous memory range wherein the data necessary for proving authorization (i.e., ECDSA-security provision data) is stored. This data consists of the signature of a string with a specific structure and an optional EVM word (32 bytes) of `commit`.

_It must be said that_ `authority` _must not be a contract; i.e., its_ `EXTCODESIZE` _must be nil. Otherwise, the operation fails._

_Any failure of the_ `AUTH` _opcode unsets_ `authorized`_, even if it has been set in this execution context before._

The string that must be signed (the message over which the signature is computed) is constructed as a concatenation (here ||):

`MSG = keccak256(MAGIC||chainId||nonce||invokerAddress||commit)`

Here:

1.  `MAGIC` - a fixed bytestring (`0x04`) meant to prevent signature collisions
    
2.  `chainId` - chain ID for use on other EVM chains. Padded to a full EVM word
    
3.  `nonce` - current nonce of the signer, padded to a EVM word from the left
    
4.  `invokerAddress` - address of the contract from where the opcode is executed (i.e., active state address); padded to a EVM word from the left
    
5.  `commit` - the commit value residing in the memory as described above; it is meant to encode custom conditions determining validity of possible txns to be undertaken from the authorized contract on behalf of the `authority`.
    

This opcode sets the `authorized` context variable to equal `authority`, provided that the signer address equals `authority` (as can be determined from the signature) and that the signature is valid. The return value of `AUTH` is a boolean success indicator.

_The memory range accepted by_ `AUTH` _is not fixed as one may assume from the above description. It is dynamic for the purposes of upgradeability; however, all supernumerary bytes are currently ignored._

### **Calling from the authorized contract (AUTHCALL)**

There is also another opcode introduced: `AUTHCALL 0xf7`. It is intended as a modification of the extant `CALL 0xf1` opcode and takes the same arguments (`gas`, `addr`, `value`, `argsOffset`, `argsLength`, `retOffset`, `retLength`). The nature of these arguments are rather self-evident from their names. However, should the need to examine them arise, one is recommended to seek information on the arguments of the `CALL` opcode, which are exactly the same.

There are a number of logical differences in the execution of `AUTHCALL` as opposed to `OPCALL`. They are as follows (ordered by precedence):

1.  The caller address of the call is `authorized`, unless it is unset, in which case `AUTHCALL` fails. This is the mechanism whereby a contract may be aliased as an EOA.
    
2.  If `gas` is zero, all available gas is sent
    
3.  If the gas available for a subcall is exceeded by `gas`, the opcode fails
    

_The subcall gas is computed according to the pseudocode below_

if (gas == 0){

subcall\_gas = remaining\_gas - (remaining\_gas//64) //see EIP-150 for reasoning

}

elif (remaining\_gas - (remaining\_gas//64) < gas) {

OPCODE\_FAILS

}

else {

subcall\_gas = gas

}

1.  The 2300 gas stipend that usually accompanies nonzero `value` calls is not allocated
    
2.  `value` is deducted from the balance of `authorized` and not the contract
    

_The authorized value is unchanged by AUTHCALL_

### **How the commit works**

Usage of `commit` is not enforced in any way by the EIP, and, indeed, the community is expected to develop standards regarding its usage (and pay attention to the contracts they authorize to) on its own (though a set of recommendations is provided).

However, the intent behind `commit` is to provide the user with the ability to encode specification of permitted calls or properties thereof (e.g., by computing a hash of the call values, which the invoker then must check before a call goes through). Since the `commit` is signed over, it cannot be tampered with without invalidating the signature unless the private key of the authorizer is compromised.

The EIP recommends that the commit be made by hashing the values which the invoker must validate. It therefore follows that the invoker should ensure the integrity of the input (i.e., that it is authorized by the user) by computing the commit hash itself as a validation operation.

An example of the commit for a multi-call authorization, taken from the EIP text, is given below (the values given are hashed to produce the commit field)

![https://eips.ethereum.org/EIPS/eip-3074](https://storage.googleapis.com/papyrus_images/4a93d02b72ec24005b06d292a4acee0b66132ffb2c917feb207d0d62d96f225f.png)

https://eips.ethereum.org/EIPS/eip-3074

This also means that control of the EOA can be arbitrarily delegated via the commit field with whatever conditionals the user desires to specify (ref. to the picture below for an example)

![https://eips.ethereum.org/EIPS/eip-3074](https://storage.googleapis.com/papyrus_images/95a5d5e027f9e3d80d5bc2a29adb44ec0cfd90fc22d82af5b71c2983d9ad2637.png)

https://eips.ethereum.org/EIPS/eip-3074

### **Consequences**

1.  The EIP significantly broadens the native functionality of the EOAs, allowing arbitrary delegation without using the current conventional account abstraction tools. This means that once the invoker contract template is developed , all AA solutions but those with the most robust ecosystem built around them, will eventually wither for reasons of superior ease of usage of the EIP-3074 framework (as a funny miscellaneous fact: it would, in fact, be cheaper to use `AUTHCALL` instead of CALL for sending native tokens for reasons of not providing the 2300 gas stipend for seeding the gas counter).
    
2.  The pressure on existing AA solutions will only increase with time as more elaborate invoker templates will be developed. For example, solutions that allow to realize a form of joint signature with no extra off-chain technology.
    
3.  Although the demand to trust the invoker which is authorized certainly sounds problematic, it is in fact no different from using one of the existing solutions, which also require the user to put his trust into their proper operation.
    
4.  Moreover, this EIP will bring on-chain a certain form of conditionality on the transactions from a EOA that require no off-chain components to exist for monitoring, therefore definitely expanding automation possibilities.
    

### **Conclusion**

EIP-3074 marks a significant milestone in Ethereum’s evolution towards a more user-centric, accessible, and cost-effective future. By enabling the possibility of delegating control of an EOA to a smart contract invoker, this upgrade opens up avenues for a range of new possibilities like batched and sponsored transactions, the possibility to retrieve funds in case of lost private keys, and much more.

These advancements will not only provide a much needed path to native Account Abstraction, streamlining user interactions, but expand the range of use cases for robust and decentralized on-chain automation.

---

*Originally published on [PowerPool Research](https://paragraph.com/@cvp/eip-3074-explained)*