Abstract Istanbul

Recap of the largest AA-focused event

Antoine Sparenberg
Mar 21, 2024


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 Account Abstraction.

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 Account Abstraction

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 Account Abstraction. Let's revisit why Account Abstraction is a prerequisite for widespread adoption:

  1. Web3 UX sucks: The current user experience is burdened with seed phrases, unforgiving user interactions, and unnecessary complexity.
  2. The pool of early adopters willing to tolerate this cumbersome experience is limited.
  3. Newcomers are gravitating towards centralized non-custodial solutions offering superior user experiences.
  4. 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.
  5. Account Abstraction 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.
The UX of web3 is really hard

Multiple flavors of Account Abstraction

While the importance of Account Abstraction is widely acknowledged, there's no consensus on the best implementation. Different protocols experiment with multiple implementations, aiming to bring Account Abstraction 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 Account Abstraction while necessitating limited changes to the protocol.

The most advanced implementation of Account Abstraction 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 Account Abstraction 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.

ERC-4337 is like Google Translate: you can use it to have a basic conversation, but it’s too limited for deeper conversations. If we want to integrate our accounts with web2 applications using webAuthn and the kinds of signatures the rest of the internet uses, we need to go one step further.” - Joe Andrews, Aztec Labs

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 Account Abstraction before potentially integrating them back later into L1 at protocol level.

One could believe that Ethereum should ossify and that most innovation should happen on L2 - Bobbin Threadbare, Polygon Miden

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 Account Abstraction approach to specific use-cases.

Native Account Abstraction

With EOAs

Some Layer 2 solutions, such as zkSync, Polygon Miden or Fuel Network, have opted to implement Account Abstraction 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 Account Abstraction at the protocol level: “One fundamental role of L2s is to provide a better UX to the Ethereum community, so Account Abstraction 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.

Account Abstraction's challenges and what’s next

While we now have tools and solutions for Account Abstraction 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 Account Abstraction 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.

Account Abstraction 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 Account Abstraction 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 Account Abstraction 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 Account Abstraction implementations, and developers are considering how to best build with AA. This could lead to a scenario where standard Account Abstraction 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.

“As an industry, we don’t really know yet what we are doing or how people will use what we are building. With standards, we take our best guess on what works and what doesn’t, but people might have different opinions, decide to go their own ways, and explore their own things. Successful ecosystems will attract builders and users and define their own standards. Once we have multiple implementations that work well, the inertia to merge into one is not only hard to overcome but potentially counterproductive.” - Henri Lieutaud, Starknet Foundation

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 Account Abstraction. 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 Account Abstraction 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 Account Abstraction 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 Account Abstraction 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 Account Abstraction experiences, and users have no short-term incentive to switch to more expensive smart accounts if it does not improve their web3 experience.


To foster Account Abstraction 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, Account Abstraction 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 Account Abstraction 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 Account Abstraction-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.


Predicting the pace at which these changes will unfold is no easy task. Overcoming inertia is a challenge, and widespread Account Abstraction 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 Account Abstraction in a blockchain’s value proposition. They are implementing native account abstraction while removing EOAs altogether, making Account Abstraction a de-facto reality from day one. These chains are likely to lead Account Abstraction adoption and be the first to capture new user bases.

Own It

We use 🍪 cookies to personalise your experience on Argent. Privacy Policy


HQ London, made with ❤️ across Europe