Is EIP-3074 a good idea?
Everything you need to know about the latest Ethereum wallet UX upgrade.
It was recently announced that EIP-3074 would be included in the next Ethereum hard fork as a protocol-level improvement to Ethereum wallet UX. A curious mix of reactions followed from the Ethereum community:
Celebration: “…a monumental upgrade to Ethereum UX” (Uniswap founder)
Concern: “…very problematic" (Gnosis founder)
Confusion: “mixed feelings…not sure this is the right strategy” (one of the EIP-3074 authors)
So what actually is EIP-3074? Are my assets safe? How is this different to smart contract wallets, account abstraction or ERC-4337? Why does the Ethereum community name everything with confusing numbers?
If you’re a regular EVM user or developer, it’s worth understanding where wallets are heading next - but first, let’s start at the beginning.
EOAs vs. Smart Contract Wallets
The basic account primitive of the EVM is the Externally Owned Account (EOA).
Account: an Ethereum address (e.g. 0xabcdef)
Externally Owned: the controller of this address is a cryptographic private key
The other type of Ethereum “account” is a smart contract, which also has an address, but contains code and has no native controlling key: if you want to send transactions via a smart contract account, you need to build that capability into its code!
All transactions on Ethereum must be initiated by an EOA, so they are by far the most common type of Ethereum account for users. However, EOAs have a number of major UX and security downsides:
They must have enough ETH to use as gas in their transactions (problematic if the user has other valuable assets e.g. NFTs, but no ETH)
They cannot send bundled transactions/interact with >1 smart contract atomically
They cannot have on-chain recovery mechanisms (e.g. social recovery)
They are very easy to compromise, and all your assets will be drained if they are
To solve these challenges, a long term goal of the blockchain research community has been “account abstraction” (AA): switching users from EOAs to “smart contract wallets” which are controlled by on-chain code code. The user usually still needs some key material on their device, but we can program arbitrary logic into the smart contract code to control user assets and solve the issues described above.
Some chains have introduced account abstraction as a native primitive (e.g. Starknet), while Ethereum has been content to have wallet providers create their own smart contract wallet implementations. There are now dozens of smart contract wallets which offer different functionality for different purposes (e.g. Gnosis Safe, Argent, Coinbase Smart Wallet, Immutable Passport).
However, the numbers speak for themselves: fewer than 0.1% of Ethereum users use smart contract wallets, and there are still tens of millions of active Ethereum EOAs. Getting these users to switch is a monumental undertaking and a security nightmare.
How can EIP-3074 help?
EIP-3074 was proposed in late 2020 as a way to help EOA users get some of the benefits of account abstraction immediately, without needing to fully convert their accounts into smart contract wallets.
EIP-3074 introduces two new opcodes, AUTH and AUTHCALL. These opcodes allow users to temporarily delegate control of their EOA account to another account (the “invoker”, usually a smart contract) by signing a message. Another account (the “sponsor/bundler”) then sends a transaction which uses that message with an AUTH opcode to make the delegation official on-chain. The “invoker” account can then use AUTHCALL to transact as the user.
There will probably be a few standard invoker contracts (e.g. one that handles batching), and these invokers will replicate some of the key UX benefits of account abstraction!
Batched Transactions
Consider the common flow of ERC20 approval + transfer, which currently requires two separate Ethereum transactions for EOAs. Through a delegation to a batching invoker, this can be reduced to one transaction (though wallets would still need to show two confirmations). Additionally, many applications attempt to avoid this “double request” on subsequent interactions by requesting unlimited spent approval during the user’s first interaction. This leaves users fatally exposed to any future bugs in those protocols, so by avoiding it we’d get a large security improvement for free!
Gas Sponsorship
Let’s say our user has $20 of USDC in their wallet, but no ETH with which to pay the gas fee (e.g. of a swap). A dapp could request permission to act on behalf of the user via an invoker, pay the gas fee themselves, and then seek reimbursement from the user’s USDC balance. The invoker contract must contain logic restricting the transactions it sends to only those approved by the user via an explicit signature.
Additional custom invokers will likely follow, and users could access this UX without needing to switch away from their existing, familiar wallets (assuming those wallets added EIP-3074 support).
How is this different to ERC-4337?
Hang on, I thought we already had an account abstraction proposal with a strange number? What happened to ERC-4337?
ERC-4337 is a standard for smart contract wallets which aims to consolidate the currently fragmented smart contract wallet ecosystem. ERC-4337 accounts are full smart contract wallets: user assets are stored in a smart contract rather than an EOA. There are lots of different implementations, but the overall flow for ERC-4337 transactions is as follows (note that alex.eth is a smart contract):
The goal of ERC4337 is to pioneer the widespread adoption of smart contract wallets without any change to the core EVM. Eventually, account abstraction is likely to be incorporated into chains natively: there is already a plan to introduce native account abstraction to Ethereum L2s via RIP-7560, and this could be extended to Ethereum itself in future (via EIP-2938 or a successor).
Today, ERC-4337 is still in its infancy. The standard is yet to be finalised, and last week there were only ~200,000 ERC-4337 transactions across all EVM chains (90%+ on Polygon). EIP-3074 and ERC-4337 are parallel improvements to wallet UX, and most Ethereum users today are EOA users. Proponents of both have argued that the fastest way to improve Ethereum UX is pushing ahead on both fronts as fast as possible!
So why are some people against EIP-3074?
EIP-3074 is a potentially major security attack vector
The most common complaint you will have seen on Twitter is that after EIP-3074, “one signature can drain my account of all my ETH, ERC20s and NFTs”. This is true: delegate to a malicious invoker, and all your assets will be lost. Of course, one malicious “export private key” with an EOA wallet and your assets are also lost - but signatures are much more common in the standard flow of web3 applications, and many users just mash confirm as fast as possible.
However, there are some major caveats here. EIP-3074 signatures are very recognisable - they must have a “magic prefix” (literally just “0x04”). Today, most wallets only support signing with a different prefix defined in ERC-191, so there’s a low (but not zero!) chance of any current signatures being used to spoof EIP-3074 delegations. As wallets implement support for EIP-3074, they will likely introduce very scary screens which get users to double check their actions before signing this message - think “export your private key” levels of security. This limits the UX benefits of EIP-3074: if you need to approve the big red warning screen every time you want to use a different invoker, we haven’t made any progress.
To counter this, many wallets may choose to implement a list of approved invokers (e.g. the standard transaction batcher), and only display the scary screens when users step outside these bounds. However, this is an obvious centralisation vector, is going to be idiosyncratic across wallets, and relies on co-ordination between dapps and wallets (e.g. both choosing the same gas sponsorship invoker).
Assuming your wallet implements EIP-3074 sensibly, there’s no reason to believe that EIP-3074 will be a security disaster - but that’s a big assumption across the hundreds of Ethereum wallets. No matter what, it will be an important new attack vector which will no doubt cause some high profile incidents - I actually wonder whether disguised batch transactions (which applies to all AA wallets) is actually the largest area of long term risk.
EIP-3074 won’t permanently “abstract” your wallet
Some people have described EIP-3074 as “upgrading your EOA into a smart contract wallet”. This is misleading - more accurately users are “temporarily giving permission to a smart contract to act on your behalf”, which has a few major limitations:
Delegating to an invoker is temporary and can be revoked at any time. This means that if someone compromises your private key, or tricks you into signing a malicious transaction, your assets will still be drained. You get some of the UX benefits of account abstraction, but none of the security benefits. In fact, EIP-3074 may massively reduce the incentive for wallets and users to upgrade to full smart contract wallets - contradicting our long term goal.
Any time you send an actual EOA transaction, you will clear any existing invoker authorisations. This is fantastic for fast revocation, but if you ever need to send a non-EIP-3074 transaction for any reason, you’ll have to go through your wallet’s “scary screen” process all over again, for all of your existing authorisations - not fun.
For many people in the Ethereum community, this feels like a job half done. If we are going to spend 2-3 years working to get dapps and wallets to support EIP-3074 interactions, why not implement the ability to make these delegations permanent, and replace the code of the account entirely (fully converting it into a smart contract wallet)? EIP-5003 would introduce another new opcode, AUTHUSURP, which would do exactly that, and there is now a large push to have EIP-5003 included in the next Ethereum hardfork to “finish the job”.
Even though this proposal has support of a number of major Ethereum community members, it isn’t a magic bullet:
EIP-5003 accounts will still have some limitations compared to full smart contract wallets
There’s no easy way to invalidate existing or new signatures from the EOA’s private key, and many contracts treat these signatures as authoritative
There are all sorts of challenges with cross-chain support, though many of these are also present with ERC-4337 wallets
EIP-3074 will require widespread wallet infrastructure changes
To enable the sponsored and batched transaction flow described above, we will need a flow which looks roughly like the following sketch:
The dapp must identify that these transactions should be batched together
The dapp must know whether our wallet supports batch transactions, and might need to include the cost of the particular invoker used by the wallet in their cost estimation for the transaction (to know whether they want to sponsor)
The wallet must know whether the dapp intends to sponsor the transaction
The wallet must check to see whether the user has already approved the necessary batch transaction and sponsorship invoker
The wallet must be able to convert the dapp’s request for “approve and transfer” into an EIP-3074 authorisation of the correct invoker and the subsequent requests - or maybe we ask dapps to do this?
The wallet must request the EIP-3074 signature from the user authoring the batch transaction invoker, with their custom EIP-3074 logic
The wallet must present UI to the user to confirm each of the transactions included in the batch. This will have to be built individually by each wallet.
Dapps will need to implement separate flows for batched/non-batched users, and custom error handling for any discrepancies. As you can see, getting this flow to be supported across all users/wallets/dapps is going to be an enormous task - and we haven’t even started with cross-L2 UX!
This is very similar to the current challenge faced by ERC-4337/smart contract wallets, and there are already proposals for new wallet RPC methods like EIP-5792 (batch transactions), standardising the paymaster APIs (EIP-7677), account-agnostic user operation bundles (ERC-7679) and more human-readable permissions for wallets. It’s possible that EIP-3074 batching is able to piggyback of this work in some/all cases, but it’s also entirely possible we end up with 3 separate flows (EOA, EIP-3074, ERC-4337)!
This big implementation lift has a large real world cost: the more complex we make Ethereum (both at the EVM layer and the wallet RPC layer), the more we distract builders from doing everything else Ethereum needs to succeed.
TL;DR
For users/dapps/wallets that adopt it, there is no doubt that EIP-3074 will be able to provide meaningful and immediate UX uplifts.
However, there is a big risk that uptake of this functionality will be very limited: the new UX will be confusing, complex and disparate across wallets. By the time dapps and wallets are offering widespread support for EIP-3074, full smart contract wallet standards will hopefully have the tooling and maturity to be a more attractive destination for users. I am most hopeful about EIP-3074 as an intermediate tool for users on their path to full smart contract wallets, and I agree with the argument that this is massively limited without the fast-follow inclusion of EIP-5003.
The largest risk to the Ethereum community is the effort required to support EIP-3074 will dilute the efforts of developers trying to move users to fully abstracted wallets. ERC-4337 is still not final, crucial EIPs for the wallet<>dapp layer are still up in the air, and attempts at native account abstraction on L2s via RIP-7560 have relatively low traction. Further division of developer focus is unlikely to produce better results!
Ultimately, whether EIP-3074 is a good idea will depend on the degree to which it can be the trojan horse for other paths towards account abstraction (ERC-4337 and native). In the success case, EIP-3074 is a fantastic immediate upgrade and provides the incentive for dapp developers to integrate the tooling necessary to kickstart ERC-4337 adoption. In the failure case, we end up with dapp developers needing to maintain custom flows for 8 different types of Ethereum account!