Introduction
In November, the focal point for account abstraction enthusiasts converged in Istanbul at the Abstract Istanbul event. Following the launch of ERC-4337 nine months prior, the event aimed to bring together leading minds in the Ethereum ecosystem to reflect on the future of AA.
For those who missed out on Abstract, fear not! This blog article serves as a comprehensive recap, delving into the key insights and highlights from the event.
💡 You can also catch some of the event recordings here.
Why we need AA
For years, Argent has championed the cause of account abstraction within the Ethereum ecosystem but despite increased awareness, there still exists a gap in understanding the critical nature of AA. Let's revisit why AA is a prerequisite for widespread adoption:
- Web3 UX sucks: The current user experience is burdened with seed phrases, unforgiving user interactions, and unnecessary complexity.
- The pool of early adopters willing to tolerate this cumbersome experience is limited.
- Newcomers are gravitating towards centralized non-custodial solutions offering superior user experiences.
- We must meet users where they are if we want to offer web3 services to the masses in a non-custodial and censorship-resistant manner.
- AA unlocks just that by enhancing user experience and flexibility and enabling familiar interactions without the need for seed phrases. It opens the door to web2-like services such as freemium models, social logins, and account recovery.
Multiple flavors of AA
While the importance of AA is widely acknowledged, there's no consensus on the best implementation. Different protocols experiment with multiple implementations, aiming to bring AA to the masses in various ways.
ERC-4337 on Ethereum
As Julien Niset, Co-Founder of Argent, emphasizes, implementing full Account Abstraction on Ethereum is no easy task as it requires multiple changes to the very heart of the protocol. **That’s why, since 2016, several approaches have been proposed to bring some of the features of AA while necessitating limited changes to the protocol.
The most advanced implementation of AA on Ethereum is ERC-4337, which simplifies writing and operating smart contract wallets on Ethereum by mutualizing some of the on-chain and off-chain infrastructure required.
EIP-4337 was designed to emulate AA without necessitating any changes to the protocol, so it comes with multiple shortcomings (design complexity, compatibility issues, no clear bundler business model…) but is a good trade-off to bring smart account capabilities to Ethereum.
While further discussions about protocol-level implementations on L1 are ongoing, Layer 2s represent a great design space to further explore multiple steps and experiment with different implementations of AA before potentially integrating them back later into L1 at protocol level.
ERC-4337 on L2s
EVM-equivalent Layer 2 solutions like Taiko are automatically compatible with ERC-4337 as it is implemented on L1. While advantageous in implementation simplicity, they inherit 4337 flaws and lack the ability to tailor their AA approach to specific use-cases.
Native AA
With EOAs
Some Layer 2 solutions, such as zkSync, Polygon Miden or Fuel Network, have opted to implement AA directly at the protocol level, drawing insights from L1 experiences and capitalizing on their greenfield designs.
Anthony Rose, SVP of Technology at zkSync, outlines the reasons for building AA at the protocol level: “One fundamental role of L2s is to provide a better UX to the Ethereum community, so AA plays a major role. At the time we launched zkSync Era, 4337 was being developed but not in a stable state yet, so we attempted to take the ideas of 4337 and implement them natively. Because AA is native on Era and there is a unified mempool, we inherit the censorship resistance properties of the protocol, which is a significant plus.”
Without EOAs
Others, like Aztec and Starknet, went even further by removing EOAs from their network.
On such L2s, smart wallets like Argent are not just first-class citizens; they're the ONLY citizens. Dapps only maintain a smart account interface and face no compatibility issues. That’s where smart wallets can best deliver on their mission.
AA’s challenges and what’s next
While we now have tools and solutions for AA implementation (with L2s playing a major role), adoption still has a way to go. Let's explore challenges and potential solutions.
Cost overhead
Cost overhead is a frequently cited challenge for AA adoption. Smart accounts consume slightly more gas than EOAs, which can be critical for some applications (e.g. pro-traders prioritize cost optimization over operational simplicity). However, this becomes a non-issue in the medium term with the expected migration to Layer 2s, where transaction costs are significantly reduced.
Interoperability and standardization
We need standardization…
As Nick Dodson from Fuel puts it, we want to get to a point where users shouldn’t care about the chain. They should express what they want, and it should be rendered on different networks, using the best paths and channels.
AA introduces increased complexity in cross-chain interoperability. For instance, smart accounts have chain-specific addresses, posing a challenge for identity management in a cross-chain world.
According to Anthony Rose, the only way to make AA interoperable is to define standards so that developers can forget about building the 4337 way, the Starknet way, or the zkSync way.
In that regard, ERC-4337 AA benefits from a head start as it offers a common interface for wallet providers and protocols to agree on standards and design interoperability. On the other hand, there is no common ground between protocol-level implementations of AA, making them even harder to integrate in a cross-chain setup.
… while preserving flexibility and innovation
While acknowledging the need for standards, panelists agree that flexibility must remain paramount. According to Anthony Rose, scaling isn’t just about building a VM environment but also about creating an experience. Many Layer 2s are thinking about their AA implementations, and developers are considering how to best build with AA. This could lead to a scenario where standard AA is implemented at the protocol level, potentially involving breaking changes in ERC-4337.
Henri Lieutaud from Starknet Foundation argues that multiple standards could end up coexisting.
Dapps adoption
Smart account compatibility
For smart account users to effectively utilize dapps and protocols, they must adhere to certain ground rules (e.g., compatibility with EIP-1271 or avoiding ecrecover in signature validation). Unfortunately, many Ethereum dapps are still not fully compatible with AA. When new dapps are constructed following these models or when incompatible dapps migrate to Layer 2s, they will replicate these incompatibilities.
This issue extends to all EVM-compatible chains. For instance, Marcin Michalski from Matter Labs notes that builders will sometimes inadvertently break AA in zkSync contracts because on L1, many contracts still assume that AA does not exist.
The chicken-and-egg problem
For smart accounts to gain traction, Dapps also need to construct dedicated user flows, leveraging AA to significantly improve UX. Otherwise, why would users switch to a more expensive smart account?
According to Hsuan Lee, CEO of Blocto, what is preventing AA from wide adoption is that there are many differences between EOAs and smart accounts, so devs have to talk to different wallets in different ways.
To date, the majority of the user base still employs EOAs, and Dapps are hesitant to isolate themselves from these users. Ideally, they should be able to segregate their users and offer different experiences based on the type of account being used (e.g., users on a smart account could benefit from multicall and free transactions, while users on an EOA would be stuck with the current experience).
From a Dapp perspective, this means double the trouble: two user flows, two different UIs; almost two different products.
So, Dapps have no short-term incentive to build dedicated AA experiences, and users have no short-term incentive to switch to more expensive smart accounts if it does not improve their web3 experience.
Solutions
To foster AA adoption, we need to break the inertia created by the chicken-and-egg problem. This will progressively happen thanks to the development of three combining forces:
- New Use Cases As the infrastructure is fairly recent and still under development, AA has mostly been applied to existing dapps and use cases, while AA-specific business models are yet to emerge. Increasingly, use cases such as onchain gaming will be developed that heavily rely on AA capabilities (sponsored gas fees, account programmability, session keys, passkeys) and will exclude EOA users.
- New Users There is a migration cost for current users to shift from their EOAs to smart accounts: new mental model, surrendering transaction history, incompatibility with some dapps, etc…. However, the good news is that smart accounts are excellent for onboarding new users! They enable tapping into new user bases thanks to increased security, decreased complexity, and web2-like onboarding processes. Chances are high that newcomers will increasingly join the space on smart accounts directly.
- Ditching EOAs The combination of AA-enabled use cases and new, less tech-savvy demographics will progressively shift the user base towards smart accounts and, as a result, encourage legacy dapps to build dedicated user flows.
Timing
Predicting the pace at which these changes will unfold is no easy task. Overcoming inertia is a challenge, and widespread AA adoption on Ethereum L1 and most Layer 2s is not likely to happen anytime soon.
An increasing number of new-generation Layer 2s are following Starknet’s lead, recognizing the importance of widespread AA in a blockchain’s value proposition. They are implementing native account abstraction while removing EOAs altogether, making AA a de-facto reality from day one. These chains are likely to lead AA adoption and be the first to capture new user bases.
These chains are likely to lead AA adoption and be the first to capture new user bases.
.png)