EIP-3074 Explained

March 25, 2024

Table of Contents

Account Abstraction (AA) remains to this day one of Ethereum’s biggest unsolved problems, going back almost a decade at this point. This post aims to shed some light on EIP-3074 which, while being overall a simple change to the EVM, requires a certain understanding of how things might work with it, with regards to user experience and the expectations around wallets.

The target audience of this article is general users who want to understand the context around why this EIP is great and the changes it will bring, but it also contains the obligatory technical section so please bear with me.

The problems with EOAs today

Externally Owned Accounts (EOAs) are simple enough to describe: A private key resolves to the address of the account where assets are sent to and held, and the private key is used to sign transactions to do anything with those assets, using ETH held in the account to pay for gas fees.

While crypto natives are by a wide margin used to this paradigm, it’s pretty terrible in practice in terms of user experience and security:

User experience: Just received a token in a fresh EOA? Now you need to get your hands on some ETH in order to do anything with them. You could swap some of that token for ETH, but unfortunately you can’t pay for the fees required to make the swap since you don’t have any ETH in that account yet. This by itself might be the biggest barrier to adoption, especially when it comes to non-financial use-cases.

Even on L2s where transaction fees are cheap (and are going to get cheaper), it’s pretty silly to expect users to have to buy a token from somewhere before doing anything with the ERC20s/ERC721s tokens a dapp just minted for them (which by themselves have no market value). If gas payment could be abstracted away from the users, suddenly a lot of workflows would become possible and UX would improve massively. Even for financial use-cases, the idea of being able to pay for transaction fees in any token you want is pretty enticing.

Another pain point is the lack of batching capabilities for many use-cases (think having to first approve a contract for every ERC20 token you want to use) which requires a lot of time and money in many cases – 21,000 gas to validate the signature for each transaction!

Security: In general, the idea of being able to revoke/rotate your private keys is considered a very basic no-brainer to have. But in crypto, your private key is intimately linked to your account. Lose your private key, you lose your assets. Want to change private key for security reasons? You have to migrate every single asset one by one to a completely different account.

Also, EOAs strictly lock you into a very specific signature scheme (“ECDSA on secp256k1”) which is likely going to have to change in the future anyway (to protect the chain against quantum computers) whereas it would be much better to have a more open system to validate any arbitrary signature scheme with custom validation rules (think social recovery schemes, etc.)

In short, EOAs are pretty terrible and it’s time to fix it with some form of Account Abstraction. Or alternatively, this tweet said it best: You call it account abstraction. I call it “reasonable features to have in an account system that should have been there in day one.

Account Abstraction Goals

Before diving more in depth about EIP-3074, it’s worth to quickly review the main goals of account abstraction:

  • Gas sponsorship: Where a different account pays for the fees of a transaction initiated by a different account

  • Signer-Account split: Separate the funds from the private key to make key rotation/revocation easier

  • Transaction batching: Easy one-to-many transactions that does a bunch of DeFi things at once

  • Custom validation logic: Natively support multisigs, threshold signatures, different signature schemes, etc. but also things like “a single signature is enough to transfer under $x per day, but for larger amounts a 2-of-2 signature is needed”, or force a delay for large transfers and have them be cancellable by an alternate private key. Really, anything you can imagine fits in here.

  • Signature aggregation: Allowing the bundling of many transactions that can be verified by a single signature (e.g. with BLS signatures)

Pretty much everyone agrees on wanting to achieve these goals, and it seems the agreed upon endgame is smart wallets following the EIP-4337 standard (implemented natively as RIP-7560 on rollups). EIP-3074 however, takes a different (but not incompatible!) approach that could more easily bring benefits to existing users who have all their assets in various EOAs. It is not by itself an account abstraction solution.

Overview of the EIP

The idea here is that instead of doing a myriad of complicated upgrades to accounts to let them do fancy stuff with specific use-cases in mind, we merely add the capacity for EOAs to delegate some control to smart contracts. This way, the core protocol upgrade stays relatively simple, and some AA goals (not all) can be achieved by leveraging the turing-completeness of smart contracts.

In a nutshell, it works by introducing having EOAs sign messages that represents action (or actions) to be executed by an invoker. Under the hood, the entire magic of 3074 works by adding two new opcodes to the EVM:

  • AUTH: Validates a signature of a hash of the action(s) (known as the commit), performs a few security checks, and returns the address of the EOA that signed it. If everything checks out, the context variable “authorized” is set to be the signer’s address.

  • AUTHCALL: behaves almost identically to the existing CALL opcode, setting the authorized address as msg.sender in the child call, effectively letting the invoker contract impersonate your EOA for the calls it make to other contracts.

    • The latest version of the EIP also allows for the invoker to spend Ether from the balance of the authorized EOA

These two opcodes are sufficient to enable powerful new UX workflows that solve coveted AA goals, namely gas sponsorship (signing a message is free for the EOA, the invoker is the one who pays the gas fees) and transaction batching – once AUTH sets the authorized address, AUTHCALL can be used multiples times in the same call

It’s worth emphasizing that, as far as the core protocol is concerned, EIP-3074 is a very simple upgrade, all things considered. A lot of the complexity is therefore delegated to the application layer (where it arguably belongs). EIP-3074 provides new tools for developers of smart contracts and wallets to create sophisticated workflows, but by itself it makes no effort to describe the various standards that need to be built to leverage these two new opcodes.

Anatomy of a 3074 message

As currently specified in the EIP, the messages to be signed will be a keccak256 hash of a series of concatenated values in this order: MAGIC || chainId || nonce || invokerAddress || commit, and each one has a simple purpose:

  • MAGIC is just the byte 0x04, it is there to prevent collision with other signature formats like ERC-712
  • chainId is to prevent replay attacks across different EVM chains/rollups
  • nonce must be equal to the signing EOA’s nonce, in order to allow in-protocol revocation of all previous authorizations
    • Note that this is a fairly recent addition to the EIP, previously there was no way to revoke outstanding authorizations, which raised some security concerns.
  • invokerAddress must be equal to the address of the contract using the AUTH opcode, to prevent the signature being used by a different invoker
  • commit is any arbitrary 32 bytes values to encode any additional logic or conditions, to be interpreted by the invoker contract

Aside from commit, all these values can be inferred easily during execution. AUTH thus receives as inputs the elliptic curve values of the signature (yParity, r, s) and the commit. Even though the ecrecover precompile is used to calculate the original address of the EOA that signed the message, the authorizing address is still passed as argument in order to be compatible with potential future upgrades where the signer might be a smart contract, and/or the signature scheme used doesn’t support computing the original address from the signature alone.

Security concerns around invokers

A potentially scary thing about these messages comes from the fact that the core protocol doesn’t know or care what the commit actually represents: If AUTH successfully validates the signature, then the invoker contract can do whatever it wants with your wallet, through a series of AUTHCALL uses that impersonate your EOA. This means that a malicious invoker contract could in theory use a series of AUTHCALLs to drain all the assets in your wallet, assuming that they managed to trick you into signing a message you shouldn’t sign. In practice, this leads to an expectation that wallets will hold a whitelist of thoroughly audited invokers to protect users.

The worst-case scenario above is effectively equivalent to having your seed phrase compromised by a bad actor. And this is actually a pretty interesting lens through which you can view the capacity of EIP-3074: It is kind of like giving your seed phrase to an invoker smart contract, but with explicit restrictions about what the contract can do, and these restrictions are laid out openly in code visible onchain to everyone – which is why the few invokers that are going to be widely used must be fully audited, non-upgradable, formally verified, etc.

The argument around these concerns is that it is not that much of an extra risk compared to the analogous risks that already exist today, whether it be relying on smart wallets like Gnosis Safes being secure enough to hold your assets, or trusting that your wallet software is properly securing your seed phrase and won’t (and hopefully can’t) have a malicious update that sends your seed phrase to a bad guy’s remote server. On the upside however, the UX benefits from the workflows provided by EIP-3074 are huge, so it’s overall a fairly good trade-off to make.

Example workflows and use-cases

Before going through some workflows enabled by EIP-3074, I think it’s worth to first take a little detour to highlight that we can already somewhat get a taste of what the UX benefits look like namely through ERC20 gas-free approvals (for tokens who support ERC-2612 permits) and DEXs like CowSwap that leverage this standard: sign a gas-free approval message, and then sign a second message to initiate the swap you want to do. Then it’s up to CowSwap’s bundlers to do the work of finding the best trades, aggregating them onchain, and ultimately paying the gas fees needed to execute your swap. So this is in a nutshell what it would look like after EIP-3074, except it would be way more generalized than just ERC20 approvals and it wouldn’t require any upgrade from existing smart contracts.

Aside from gas sponsorship and transaction batching which are fairly straight-forward to conceptualize, EIP-3074 also unlocks some noteworthy use-cases that are worth exploring briefly:

Asset recovery

With traditional EOAs, there is always this “all or nothing” aspect of your seed phrase: if you lose it, all your funds are inaccessible forever, and if you get it compromise, all your funds are stolen. With smart wallets, you can have precise recovery options in case of loss of private key. EIP-3074 of course isn’t a sophisticated smart wallet solution by itself, but it still enables recovery of funds in case you lose your private key.

Now, picture this hypothetical workflow: as soon as you create your wallet, you sign a message for a specific invoker that lets you transfer all your assets to a different wallet of your choosing. Now this signed message becomes an extra tool that can recover your assets in case you ever lose your seed phrase. But unlike a traditional seed phrase or private key, it is only useful to you, meaning there is no absolute need to keep that signed message secure at all costs, you just need to store it somewhere you’re sure you won’t ever lose it. (If you’re feeling fancy, you could even put it onchain!)

Note that I used the pronoun “you” in the little example above, but in reality this could just as easily be the responsibility of your wallet software to automatically generate, sign and store this recovery message wherever appropriate (e.g. things like cloud storage) and deal with the recovery for you if the need ever arises.

Synthetic EOAs

A pretty nifty thing enabled by EIP-3074 is the idea of a “synthetic EOA” – that is, an account that doesn’t actually have any private key attached to it, like a smart contract account except it can’t hold EVM bytecode either.

The way this works is through a quirk of the ECDSA signature scheme, where you can feed a signature that looks valid to the AUTH opcode, and the recovery algorithm will resolve to an Ethereum address of a synthetic EOA. And from there, anyone can send funds to that synthetic EOA’s address, and this account can only be controlled by the invoker contract that generated it. It is somewhat similar to counterfactual wallets, except without the need to deploy code (e.g. with CREATE2) to recover funds sent to it, saving a lot of gas in the process.

A simple example to wrap your head around is that of deposit addresses for exchanges: instead of generating a fresh EOA for each customer to receive deposits, the exchange could use an invoker contract that generate these synthetic EOAs in order to receive and process deposits from customers. Then when they want to move these deposits into another wallet, they could use their invoker contract to simply loop through all the synthetic EOAs and sweep funds into the exchange’s main wallet in a single transaction. This is infinitely better than having to send Ether to each one of those EOAs and making a second transaction to move the funds out of every single EOA into the main wallet.

Extra general purpose restrictions

Another interesting use-case of EIP-3074 and synthetic EOAs is to have users control them through an invoker that enforces a wide array of possible things:

  1. Different signature scheme – to a quantum-proof scheme, or one that supports signature aggregation
  2. Different authentication method (multisig, threshold signature, etc.)
  3. Arbitrary spending conditions, like requiring an extra signature to move more than N coins in a day/week, adding a revocable delay for large transfers, etc.
  4. Any combination of the above!

While I admit that the idea of a synthetic EOA may feel a bit hacky, you gotta admit it’s pretty cool that such a relatively simple EIP unlocks so much possibilities.

What about ERC-4337?

As stated repeatedly throughout this article, EIP-3074 by itself doesn’t aim to “solve account abstraction” the same way that smart wallets do. It is best to view EIP-3074 as “supercharging EOAs” by offering them a whole ensemble of features “for free” through the introduction of the two opcodes and invokers – an immediate benefit to the millions of EOAs that are active today across the various EVM chains.

In contrast, ERC-4337 does describe an account abstraction solution using a higher-level mempool and wallet features enforced by smart contracts. Being an ERC rather than an EIP, it notably doesn’t require any changes to the protocol. Because of that (and for other reasons), it’s becoming increasingly apparent that ERC-4337 is going to be the standard that smart wallets implement across the EVM ecosystem going forward. Since we eventually want all users on these smart wallets, some people wonder if there truly is a need to implement EIP-3074 at all – here are a few arguments why EIP-3074 is still worth it:

  • ERC-4337 wallets are great for onboarding new users, but today’s existing users of EOAs still bear the brunt of having to deploy a smart wallet and migrate all their assets to it one by one, which takes a lot of time and (on mainnet) a lot of gas fees. Supercharging EOAs would bring immense UX benefits by providing smart wallet functionalities without having to do anything.

  • ERC-4337 and EIP-3074 are not mutually incompatible – in fact, EIP-3074 can easily let any EOA act like a 4337-compliant smart wallet. Infrastructure developed with ERC-4337 in mind (like the decentralized fee market of the alt-mempool) can be leveraged by EIP-3074 invokers to benefits EOA
  • Related to the point above, the relatively low user base of smart wallets compared to EOAs is somewhat of a deterrent hindering progress on dev tooling and other infrastructure around 4337, which in turn doesn’t entice users to switch from EOAs to smart wallets. EIP-3074 can help break this catch-22 situation, since now suddenly every EOA can take advantage of things being developed for 4337 (effectively a massive bump in addressable user base!)

Also, on the long run, a natural follow-up to EIP-3074 is EIP-5003, which introduces a new opcode (AUTHUSURP) to insert EVM code inside EOAs, effectively turning them into smart contract. This would then allow a relatively low-friction way to convert EOAs into full blown smart wallets, at which point the user never even has to look back to their previous EOA days.