The Pitfalls of EIP-3074, and How to Avoid Them

(Thanks to Yoav Weiss and Dan Finlay for feedback and review.)

EIP-3074 has been confirmed for the next Ethereum hardfork (”Pectra”), which is amazing news for the Ethereum community. For the first time, EOA users will be able to enjoy the benefits of account abstraction (AA)—gas sponsorship, transaction batching, session keys, passkeys, etc. At ZeroDev, we cannot be more excited to bring these smart account features to EOA users.

At its core, 3074 is a very simple proposal. Two new opcodes, AUTH and AUTHCALL, together enable a smart contract (known as an “invoker”) to take over the address of an EOA. Most of the complexity in enabling the aforementioned AA features is left out of the protocol itself, and left to the application layer (specifically invokers and relayers) to handle.

By leaving complexity out of the spec, however, EIP-3074 opens up many possible paths to account abstraction. The danger is that some of these paths may lead to a future of AA that is more centralized and permissioned than any of us intended or desired. This blog post explains:

• How EIP-3074 could lead to 1) permissioned mempools and 2) popular wallets gate-keeping account innovations.
• How to avoid such outcomes.

Why EIP-3074 Needs Relayers

One common misconception about EIP-3074 is that, by itself, it enables account abstraction. Actually, by itself, EIP-3074 only enables execution abstraction, meaning that EOAs can execute calls through smart contracts, notably enabling transaction batching.

The main part of AA, however, is validation abstraction—determining the validity of transactions through smart contracts. Validation abstraction is what enables use cases such as gas sponsorship, session keys, passkeys, etc.

Because EIP-3074 doesn’t support validation abstraction natively, it must rely on relayers to “package” smart account transactions into EOA transactions, in order to achieve validation abstraction and therefore most of the benefits of AA.

Can EIP-3074 Relayers Form a Permissionless Mempool?

A mempool is said to be permissionless when any relayer can join and anyone can send transactions. While permissioned mempools (like Flashbots Protect) have a role, a permissionless mempool is crucial as the last line of defense against censorship.

If we are not careful, however, EIP-3074 mempools may become exclusively permissioned.

Why Permissionless Mempools Are Hard

In a permissionless mempool, every node sees every transaction, requiring protection against Denial-of-Service (DoS) attacks. Smart account transactions are particularly challenging for DoS protection because:

• High Validation Cost: Validation involves running smart contract code, consuming more computational resources than simple EOA validation.
• State Change Vulnerability: Since the validation contract can read chain state, a transaction that is valid when submitted may become invalid by the time it's mined. If a relayer pays gas to submit an invalid transaction, they suffer an economic loss.

Since EIP-3074 doesn’t address this problem, the problem must be solved by invokers and relayers. If it’s not solved, the default behavior would be for all 3074 relayers to only accept transactions from trusted senders, resulting in fragmented and permissioned mempools, and a low degree of censorship resistance.

How to Build a Permissionless Mempool

The trick to protecting a mempool from DoS attacks is to leverage validation-execution separation, the idea that underpins ERC-4337 and EIP-7560 (native AA).

• The smart account should implement a restricted validate() function separate from an unrestricted execute() function.
• Relayers only simulate the cheap validate() function.
• The validate() function is limited in gas and can only access state inside the account, preventing external state changes from invalidating the transaction. The execute() function handles the actual transaction execution.

Therefore, EIP-3074 invokers should implement validation-execution separation. Without it, 3074 relayers will have to whitelist transaction senders and mempool participants in order to protect themselves, leading to permissioned and fragmented mempools.

Will Popular Wallets Gate-Keep Account Innovations?

Invokers are security-critical—a malicious invoker could easily lose all your assets. As such, wallets like MetaMask will almost certainly whitelist invokers for their users, triggering a warning or failure if a non-whitelisted invoker is used.

This whitelisting is understandable, as invokers are essentially part of the wallet software. However, MetaMask does let users run custom code through Snaps, which manage security via a separation of concerns: a core kernel handles security-critical aspects (like keys), and modules (Snaps) handle less critical tasks.

Since EIP-3074 says nothing about how invokers should be implemented, the danger is that popular wallets might whitelist only non-extensible invokers, leaving no room for innovations from third parties whatsoever.

Can There Be “Snaps” for Invokers?

Ideally, an invoker would be architected like MetaMask itself. An “invoker kernel” would handle the core logic, while exposing an “invoker modules” interface for less security-critical functions.

As an example, consider gas abstraction, where gas is paid by a “gas module” (e.g., a DEX that swaps ERC-20s for gas tokens). If the invoker kernel is properly designed, a malicious gas module should not be able to steal user assets—the worst it can do is fail to pay gas. This is why ERC-4337 allows any account to work with any paymaster without explicit trust.

The bottom line is, given a securely designed “invoker kernel,” many aspects of a smart account can be securely modularized. That’s what we should strive for with EIP-3074, so that we can keep users safe while ensuring that account innovations are not monopolized by wallet companies.

Conclusions

The greatest strength of EIP-3074, its simplicity, is also its greatest weakness. Because it’s so simple, the application layer has to tackle most of the complexity of AA, opening up a lot of room for mistakes.

This post highlights two particular pitfalls to avoid:

1. Permissionless Mempools: If we don’t implement validation-execution separation for invokers, a permissionless mempool will struggle to exist, fragmenting the relayer ecosystem and increasing the risks of censorship.
2. Innovation Gatekeeping: If popular wallets don’t whitelist modular invokers that properly implement separation-of-concerns, users will only have access to a fixed set of account functionalities, severely limiting the potential of account abstraction.

In a follow-up blog post, I will make the case that the best way to avoid these pitfalls is to use EIP-3074 in conjunction with ERC-4337 (and eventually EIP-7560), which will give EOA users the benefits of ERC-4337 “for free”: permissionless mempools, diverse paymasters, modular smart accounts, and more.

At the end of the day, the future of AA is bright, and all the more so with EIP-3074 bringing AA to EOA users. Let’s try to build around EIP-3074 the right way, so that we can preserve the spirit of Ethereum itself: open, innovative, and permissionless.