EIP-3074 became the hottest topic overnight, as it got cleared for inclusion on the next Ethereum hard fork (Pectra/Petra). However, what is all the hype about, and how will it impact Ethereum and the EVM ecosystem? In this article, we will explore this proposal, answer frequently asked questions, and dispel some myths and misunderstandings. Let’s dive in, shall we?
Account abstraction EIP/ERCs overview
To strengthen your understanding of Account аbstraction, you need to know that 99% of the time, when someone says "Account abstraction," they mean "smart (contract) accounts," which is when the account is based on contract code rather than a single private key. It can still be authenticated by a single private key, as is the case most of the time (this is important later on), but it can also be a multi-signature wallet, as is the case with Safe.
The original meaning of "account abstraction" was "to allow smart contracts to initiate transactions," but this has since changed to "all features that smart contract accounts enable."
Smart contract accounts enable these features and more
Gas abstraction: dApps sponsoring gas, the user paying gas in different ERC20 tokens, or even pre-paying for gas, which is great for cross-chain onboarding.
This is excellent for privacy and OpSec because it eliminates doxxing yourself by asking friends to fund your account with ETH MATIC, whatever the native currency of the chain/rollup, or worse, withdrawing from exchanges.
Transaction batching: Or bundling multiple actions in a single transaction. This is fantastic for both security and gas efficiency.
Security: Solving ERC-20 approvals. As a side effect of batching, we can do an exact amount approval together with each action that requires one, therefore making the approval problem disappear. Why? Because we do not need infinite/leftover approvals, and we don't need a second signature for the approval.
Custom cryptography: Enabling new cryptographic curves, WebAuthn, iOS secure enclave, quantum safety, and more.
Key rotation & account recovery: Changing the private keys for an existing account or recovering an account via schemes like Argent's social recovery
Notice anything? All of those help security in some way.
Back to ERCs.
Generally, all ERCs related to Account abstraction claim those features as their motivation, but they do not necessarily provide them; they just help pave the way for making those features mainstream.
Let's break it down. The large ERCs solve distinct problems:
Transaction initiation: The ability for contracts to initiate transactions.
Native: in-protocol special transaction type that can originate from a smart contract. Includes ERC-2938, later replaced by RIP-7560
Emulated: ERC-4337 is "emulated" in the sense that transactions are actually still initiated by an EOA. This doesn't mean the user must be aware of this EOA. This EOA is controlled and operated by the bundler.
Converting existing users: this is where EIP-3074 (and its smaller sidekick, ERC-5003) come in
EIP-3074 allows delegating the control of an EXISTING EOA to a smart contract. The smart contract can control this EOA and make calls from it's address, but it cannot initiate transactions. This is important because we still need to solve the transaction initiation problem.
ERC-5003 allows an EOA to be "fully" converted into a smart contract account, thanks to revoking the original private key that acts like a master key to this EOA.
Signatures: Contracts normally can't sign signatures. But they sort of can - they can define logic that defines what is a valid signature for that contract. For example, a smart contract wallet that's a multisig between Bob and Alice will define a valid signature as isValidSignature = isValid(bobsSignature) AND isValid(alicesSignature). This needs to be defined in the contract code.
ERC-1271 defines an interface to make this happen.
ERC-6492 extends it to support not-yet-deployed smart contract accounts: this enables the same address on all chains seamlessly, while still allowing the user to sign messages.
Both need to be implemented by dApps to work.
To truly create an AA experience, you must solve all of the above simultaneously. This is why EIP-3074 doesn't compete with ERC-4337, RIP-7560, or any other account abstraction ERC.
If you want to see all this visually, we suggest this slide from a talk on demystifying AA ERCs.
Mythbusting common EIP-3074 FUD
Let's start with the elephant in the room. There have been three pieces of FUD related to EIP-3074:
Allows malicious dApps to drain existing wallets in one transaction: It is true that such a signature can be produced, but there's no reason or use case for a wallet provider to ever allow dApps to get you to sign such requests. Securing this from the wallet side is much easier than securing your private key itself, and leaking a private key has the same effect.
The account retains a single master key (the original EOA key) There's an additional ERC that solves this, EIP-5003, otherwise known as AUTHUSURP, which allows the original private key to be revoked
EIP-3074 is a band-aid that doesn't bring the benefits of native AA: EIP-3074 was never meant to compete with actual AA proposals like RIP-7560. It's not a band-aid to AA; it's a migration path. We still need native AA because, as we remember earlier, it doesn't solve the transaction initiation problem.
EIP-3074 pros and cons
Pro: It creates a very easy migration path for existing users of MetaMask, Trezor, Ledger, etc., to experience the features of account abstraction on their existing accounts.
Con: It sacrifices key rotation. While all AA features mentioned above can be enabled, key rotation becomes slightly elusive because the original private key retains control over the account on all networks that have never been used, even with EIP-5003.
Mental exercise
Here's a mental exercise that will help you understand the moving pieces:
There exists an EOA, аlice.eth (0x696969..69), on the Ethereum mainnet. This EOA is cross-chain by definition, so it also exists on all rollups and EVM chains.
This EOA is solely controlled by a private key A, owned by Alice.
EIP-3074 goes live.
A malicious dApp tries to rug Alice and asks her to sign an EIP-3074 AUTH signature, authorizing a malicious contract. The wallet ignores this request and disconnects the dApp because it's well implemented, and there's no use case for ever allowing this from a dApp.
Alice clicks a button "enable Account abstraction" on their wallet provider (say MetaMask, via a Snap or Ambire, nattively). The wallet does sign an EIP-3074 AUTH signature, authorizing a contract that the wallet provider created that helps do batching, gas sponsorship, etc.
This contract is solely controlled via private key A.
alice.eth is now separately controlled by two entities: private key A (in EOA mode) and the new contract, which in itself is also solely controlled by private key A.
Alice can now do batching, but to do gas sponsorship, Alice's wallet provider needs to implement either ERC-4337 or RIP-7560 (if the network supports it), or a proprietary relayer so that Alice doesn't have to use her ETH (which is a hard requirement of the network if you want to initiate a transaction).
Alice decides to convert alice.eth to a multisig, and the wallet provider instructs the contract to revoke private key A and authorize a 2/2 multi-sig of private keys BMobilePhone and BLaptop.
However, this doesn't work because private key A still controls Alice.eth: As per EIP-3074, the original private key retains control despite being delegated to a contract.
EIP-5003 goes live on Ethereum, and it allows alice.eth to send a special instruction to the network via her wallet provider to revoke the control for private key A.
alice.eth is now successfully converted to a multi-sig, but only on Ethereum. Private key A (owned by Alice) still retains control over alice.eth on all other networks.
Ultimately, we've learned a few things:
We have done something amazing because, without EIP-3074, Alice would probably never have adopted Account abstraction.
EIP-3074 doesn't solve everything; we still need ERC-4337 and RIP-7560 as much as we needed yesterday.
EIP-3074 does not play nice with key rotation, even if we have EIP-5003. This is why we still need actual smart accounts to facilitate use cases like multi-sigs and key rotation.
As a side note, we believe that key rotation is way too new for most and a bit convoluted in a cross-chain world where you don't have the same state between all rollups and chains. Most users seem to be sticking to the one key = one account paradigm, especially with hardware wallets, which are sufficiently secure for most use cases.
FAQ
The rest of this article will be in a FAQ-esque format so we can better address some of the most common questions people have.
Does it help MetaMask get ahead?
We believe that Account abstraction companies will gain much greater value from easier onboarding UX than incumbents will from being able to offer AA features to their existing audience.
In other words, it "unleashes" the power of AA wallets over the whole addressable market, not only the early adopters willing to move their funds to a new address.
Thanks to MetaMask Snaps, many AA companies will pivot to building AA on MetaMask, which is the galaxy brain positioning that nobody except the most astute observers saw coming.
Is batching itself unsafe?
Absolutely not. You still see what you're signing. This, combined with transaction simulation, means that signing multiple actions is just as safe, and in most practical cases safer, than signing a single action.
Transaction batching is one of the most praised features of Account Abstraction
Does this help dApps adopt AA? Does it solve compatibility issues?
dApps do work with any form of Account abstraction with some exceptions:
Some dApps discriminate against smart (contract) accounts
Some dApps do not support ERC-1271
EIP-3074 magically solves both issues: accounts appear as EOAs (they have no code), so they cannot be discriminated against. As for signatures, AA-enabled (via 3074) EOAs will still sign as EOAs, so there is no drama. It will magically work with all dApps at the expense of losing key rotation.
However, if most people choose AA-enabled EOAs over pure smart accounts, it disincentivizes dApps from supporting ERC-1271 and ERC-6492, but ERC-4337 already helped raise a lot of awareness for the signature proposals.
What about revoking the original key?
You can revoke the key via EIP-5003 (which isn't planned in the hard fork yet).
One nuance to this is that this isn't a perfect solution in a cross-chain world. The EOA will always start as an EOA on every new chain you start to use, meaning that the original key can never be truly revoked. But this applies to every form of AA because the original permissions/privileges you created the account with are always what the account starts with on any new network.
EIP-3074 works better in bringing all AA features except key rotation to existing EOAs. In other words, if you choose to enable AA for an EOA, you are forever stuck with the original private key behind this EOA.
Does it kill native AA (RIP-7560)?
No, because you still need a solution to initiate the transaction, at least if you want to pay gas in a token different than the native one (or you need gas sponsorship).
ERC-4337 is one such solution that doesn't require protocol upgrades (it isn't native), but native, protocol-enshrined AA is immensely valuable, as it solves the gas overhead and complexity of ERC-4337.
But ser, what about EIP-7377
EIP-7377 allows converting an EOA to a smart account. Rather than allowing a smart contract to control the EOA alongside the original PK, this EIP allows a contract to take over the EOA in one transaction.
It can be considered an alternative to the EIP-3074 + EIP-5003, but it didn't gain as much momentum.
Closing thoughts
EIP-3074 is not a band-aid. It's extremely bullish for the future of Ethereum and the EVM ecosystem because asking users to suddenly abandon their existing accounts and transfer all their funds, staking positions, etc., to a new account (smart contract account) significantly raises the barrier to entry.
EIP-3074 will provide a new middle ground and gradual onboarding, which is exactly what we need to improve UX dramatically.
Interested in Ambire? Follow us:
Discord | X (Twitter) | Reddit | GitHub | Telegram | Facebook
