There is a lot of information out there about Account abstraction, as well as ERC-4337, but at times, it can get difficult to differentiate the facts and the myths about them. In this article, we will look at the most common misconceptions and the truth.
Myth: All Account abstraction wallets are based on social login/recovery
Social login and/or recovery are some ways to recover a wallet without needing a seed phrase while still being self-custodial. One such example is Argent, which uses social recovery.
There are other ways to log in or recover an Account abstraction wallet, e.g., email registration and recovery - such is the case for Ambire Wallet. While it is already implemented in the wallet, we are even taking it a step further by developing self-custodial email/password Authentication via DKIM. Ambire even won a grant from the Ethereum Foundation in 2023.
Myth: Account abstraction is not live
There are 2 things to consider here. Firstly, Account abstraction is a concept (aiming to make smart contract accounts native and to be used as wallets), which means that it’s a continuous effort. Many projects have been building on Account abstraction for years, even before it became a topic of interest using their own technology. Wallets like Ambire Wallet and Argent e.g., built their own relayers to enable transaction batching, paying for transaction fees in non-native tokens (e.g., stablecoins), etc.
Secondly, Account abstraction is often equated to ERC-4337, an Account abstraction Ethereum Improvement Proposal without the need for protocol changes. ERC-4337 went live on mainnet in March 2023, allowing for relayerless Account abstraction.
Myth: You need to integrate ERC-4337 for Account Abstraction benefits
There is a further misconception that to be considered an Account abstraction project, ERC-4337 needs to be integrated. This is only partially true - as we mentioned earlier, you can take advantage of all Account abstraction benefits without necessarily integrating ERC-4337. However, this requires an additional layer of infrastructure, such as a relayer. Of course, not every project has the capacity and resources to do this, but this doesn’t make it impossible.
Myth: You get a different address on every chain
Account abstraction smart contract wallets do not require you to have (and remember) a different address on every chain. In fact, you can have the exact same account address across all EVM networks. Furthermore, there are efforts to make sure that non-EVM chains in the future can also have the same address. This makes the smart contract wallet experience as seamless as using an EOA and reduces the chance of sending funds to the wrong address, thereby burning them.
In Ambire Wallet, e.g., your wallet address stays the same whether it’s on Ethereum, Polygon, Arbitrum, Base, etc. This makes it easier and friendlier for new users and experienced ones, as there is only one address to manage.
Myth: Account abstraction wallets do not have a private key
Smart contract wallets can be created without a seed phrase - but this does not mean that they do not have a private key! With them, the private keys are ‘under the hood.’ What does this mean? They’re still there, but you do not need to worry about them because mechanisms are developed to easily recover the account, e.g., without having to keep safe and input a seed phrase.
The reason why Account abstraction can eliminate the seed phrase is not because there aren’t private keys but because the importance of a single private key can be vastly reduced.
For example, if you create an Ambire Wallet with email and password, there are 2 private keys generated for you in the background, and they are your two signer keys (think of them as actual keys that open a lock) that control the account. One is unlocked with your email via a confirmation code, and the other with your password. Both are required to make transactions immediately, but only one of them can also sign transactions after a 3-day timelock. This allows you to recover your account in case you forget the password.
Myth: Transaction fees are significantly higher
Now, this isn’t necessarily a myth, even though there are efforts to make sure it will no longer be an issue in the future. Smart contract accounts have a slightly higher gas overhead per transaction because of the various additional on-chain accounting processes needed compared to EOA transactions. But Account abstraction allows for some pretty special features that can help offset the higher cost, e.g., transaction batching. At Ambire, we did a comparison between EOAs (e.g., MetaMask) and Ambire Wallet with our unique Gas Tank enabled.
Ambire Wallet consistently demonstrates reduced gas costs compared to EOA wallets as the number of operations increases. In fact, it offers savings ranging from around 10% to 37% for 2 to 15 operations:
In the future, technical improvements such as ERC-4337 userOp compression and ERC-7560 will allow for a significant reduction in Account abstraction fee overheads.
Myth: Account abstraction and ERC-4337 are competing with EIP-3074 and RIP-7560
First, let’s quickly look at what EIP-3074 & RIP-7560 are for those unfamiliar with them.
EIP-3074 is aimed at advancing externally owned accounts (EOAs), and it looks at two (you can say opposite) ideas: on the one hand, integrating smart contract account capabilities into EOAs, and on the other hand, extending EOA features to smart contract wallets. EIP-3074 can easily work in conjunction with ERC-4337, as they achieve completely different goals: one allows EOAs to become smart wallets, while the other provides a decentralized relayer network for transactions.
RIP-7560 is a proposal for native Account abstraction (essentially a native version of ERC-4337). Unlike ERC-4337, which implements Account abstraction as a layer on top of Ethereum's existing structure, RIP-7560 enshrines those capabilities directly into the Ethereum protocol.
Therefore, we can say that EIP-3074, RIP-7560 & ERC-4337 complement each other, rather than competing.
Myth: dApps also need to implement AA for it to work
dApps don’t really have to do much for you to use them with smart contract (Account abstraction) wallets. The integration work and implementation are usually required on the wallet level. Of course, if a dApp doesn’t yet support smart contract signatures, they need to implement them. We at Ambire put together a library to help dApps interact with smart wallets - and if a dApp integrates it, it won’t support just Ambire but any other Account abstraction wallet.
Myth: You can’t sign messages with a smart contract account
You may have heard that on Ethereum, only EOAs with their associated private keys can sign messages with the traditional signature authentication. This may have been the case in the very early days of smart contracts, but luckily, thanks to EIP-1271, there is now a new standard way to verify signatures for smart contract accounts.
Rather than relying solely on the Elliptic Curve Digital Signature Algorithm (ECDSA) signatures, which only works for EOAs, EIP-1271 allows smart contracts to define their own custom logic to verify signatures - which normally still uses ECDSA under the hood. This opens many doors for smart contract wallets to meet the different requirements of DeFi applications. Of course, this has already been implemented in Ambire, meaning you can sign messages with Ambire Wallet.
Our recommendation is to always do your research and use reliable sources of information. Not only when it comes to Account abstraction but also in general. Whenever there is a hot topic, it is unavoidable that there will also be misconceptions about it. With some digging, you can always find the truth!