Unbundling the future of Dapp and wallet UX

The end game for Ethereum UX and accounts looks very likely to be in the direction of smart accounts. We’ve seen the rise of standards like ERC 4337 helping to pave the way for smart account adoption. We have also seen the introduction of EIP 3074 and EIP 7702  that will give a short term remedy for EOAs before the transition to smart accounts.

Regardless of the recent contention around EIPs and ERCs, I believe it's an interesting exercise to actually think extensively about the user journey, who owns the user, and look at what the potential end games could look like for a dapp and a wallet.

Let's explore.

TLDR: We’ve seen great strides in UX over the past year, and we’re still on the journey with many more improvements to be made to make building Dapps easier and making wallets smarter.

Mainly, we introduce the concept of a Uniform UX that completely entails the function of what the future of wallets would and should look like and how dapps are able to completely transform their UX as a result. Naturally, through Account Abstraction and smart contract accounts at large are we able to achieve the UX users deserve.

In light of this, there is always an interesting tension between how the user interacts with dapps and wallets. We assess this by looking at the following 4 major touchpoints that users go through:

1. 3rd Party wallets and extensions
2. SuperApp Wallets
3. App specific wallets
4. Embedded wallets

‍

Additionally with the rise of chain abstraction looming into the ecosystem, it accelerates the transition to achieve the holy grail of UX that we can see at the wallet level, which empowers dapps to curate best in class experiences anywhere from a spectrum that caters UX to the needs of newbies all the way to degens. Not all UX is created equal.

‍

Where we are

First, let's look at where things stand, especially with regards to the different standards being proposed by the Ethereum community. EIP 3074 is not going ahead in the next Pectra hardfork and will be replaced by EIP 7702 (as of writing).

This article will NOT go into any details of the standards or comparing them. You can find great articles about the latest EIP 7702 here and here, and also articles related to EIP 3074 here, here and here.

This article is all about having empathy for users and Ethereum’s future UX and we all have a part to play in onboarding the masses.  

Before we get into it, let's shed a bit of light into the AA space to give some context. We have seen quite a few AA infrastructure and Smart Account providers paving the way for what this end game could look like given the limitations of EOAs.

Smart accounts ultimately make a clear distinction between signature validation and execution. Here are a few examples of use cases and live implementations we are seeing with ERC 4337 Smart Accounts:

• Safe enabling Multisig
• Trust Wallet enabling users to create a wallet with passkeys (no seed phrase) and allowing users to pay gas in any token across the EVMs they support
• Anichess.com, a chess game, onboarding users through social login and gasless minting of NFTs in the gaming app
• Alfafrens is a SocialFi app on Farcaster for gated alfa chat subscriptions powered by Superfluid and $DEGEN on Base. $DEGEN is used to pay gas fees for any onchain action on the app
• Drakula enabling a TikTok like experience through onchain creator earnings with a fully onchain gasless experience using Degen as the currency on Base
• CyberConnect enabling a multichain gas tank experience for their users allowing users to pay gas on any chain for a transaction on a different chain
• Kwenta allowing traders to enable one click trading experiences on chain through session keys and batched transactions
• Eesee enabling users to do all transactions via USDB with gas being paid in USDB on Blast
• And many more

The interface for these smart account experiences (i.e. where the signer lives) have either been EOA wallets like Metamask, Rabby etc or Embedded Wallets like Privy, Web3Auth, and Dynamic. ‍

‍
The need for Uniform UX

We all know UX still sucks. In general, in order to better the UX (in a non custodial manner), Dapps today have to integrate embedded wallets, enable meta transactions, AA solutions and more which further fragments an already fragmented ecosystem where users have funds on different wallets and chains and wallets don’t have uniform UX. Dapps have to build wallet functionality, and do deeper integrations because the majority of wallets do not have these functionalities (Metamask Snaps to a large degree is an exception working towards this).

Imagine a world where Dapps can easily achieve seamless web3 experiences by curating their own UX on top of a framework/Uniform UX where they don't need to reinvent the wheel and know that whatever the wallet the user is using/onboarding with already has smart features ready:

• Dapps want to enable sponsored transactions for themselves? Well they can work with infra/relayer providers to easily enable it and using existing popular libraries like Ethers/Viem to build the transactions and is compatible with any wallet
• Dapps want users to pay gas in any token? Well they can rely on the wallet itself
• Dapps want to remove the annoying approvals that plague Ethereum? They can use batched transactions enabled at the wallet level and on top introduce batched transactions for specific flows in their app and the wallet would understand it
• Dapps want to enable permissions/session keys? Through AA, they can use permission frameworks that the Smart Account (natively on the wallet) supports and/or build their own flows on top if they need extra permissions
• Dapps want to build specific modules for specific use cases? Well, through ERC 7579 or 6900, apps can build their own specific modules which users can interact with
• A dapp is built across multiple L2s which is either visible or invisible to their users, and they dont want the user to keep switching network? Well the user would not need to switch chains, they can just set the transactions they want to do and the wallet by default will know how to handle it and enable signatures for the user to sign before its sent off. The dapp in this context defers to how they enabled a chain abstraction environment along with the wallet understanding it.  

This is why it's important to ask, out of all the amazing AA features and improvements that are talked about all the time, which ones should be built by a dapp, and which ones should be built by the wallet? It makes no sense for a dapp to build a recovery feature for example, but rather rely on the wallet (3rd party extension, embedded wallet etc). However, if wallets understood permission capabilities and batched transactions, this would allow the dapp to curate new experiences for their users unique to their app.

What does the Uniform UX look like?

It could look like the following:

• Onboard via email, passkeys or otherwise (via different signature schemes)
• Gas Abstraction:some text
  • Pay gas in the token the user is transacting
  • Wallets natively supporting gasless transactions i.e. new users get 5 free transactions when they onboard or how Coinbase allows free USDC sends on select chains
• Multisig
• Batched transactions
• Access delegation/Advanced permissions
• Key rotation
• Account recovery
• Chain abstraction
• Least privilege
• Import Account
• Anything else that is missing…

You can think of this similar to Polygon’s Agglayer or Optimism’s Superchain where there's a base layer of consistency with a degree for rollups to customise their environment. Well, dapps should have that degree of flexibility to customise their environment too. Eventually, a Uniform UX leads to different types of customised UX that is curated by many different dapps. Not all UX is created equal.

Dapps and Wallets

This leads to a question that has always intrigued me; Who owns the end user in Web3? Dapps or Wallets? We have seen major applications relying on users coming from different wallets before building out their own wallet i.e. Uniswap, Ronin and more. New apps often go with an embedded wallet flow, where users move their assets to newly generated wallets created by the app and thus rely on getting users themselves as opposed to being open to all wallets via wallet connect. It's a really interesting thought exercise because when compared to Web2, who owns the customer? Shops/apps or Banks? Well it's both. We as users have multiple direct relationships and it probably would look the same as web3 matures. We’ll look into this a bit more later in the article.

Here’s a general flow of a user interaction across 5 common paths.  

These paths all suffer the fragmentation issues because the current status quo sucks. Let's analyse the UX journey of Dapps and wallets, and how Uniform UX can play a role.

‍

Wallets (3rd Party Wallets and SuperApp Wallet)

A. 3rd Party Wallets

We all know wallets today can be radically improved. Users need to understand how a wallet works by understanding seed phrases, understanding and needing gas, navigating through chains individually, multi-click transactions, and more! We definitely have seen improvements in wallet interface experiences such as Rabby, Zerion, Rainbow and more taking a different approach in their interface and experience compared to the wallet of choice which has and still is Metamask that is the defacto wallet for web3.

Apps today cede sign up, sign in, and checkout to random third party extensions which could have significant material impact to their business and a ton of friction in getting started. It mainly arises as well from two issues:

• The fact that developers don’t know which wallet their user is going to connect with and in theory need to support all wallets
• Majority of users still use 3rd Party Wallets and so Dapps want to attract as many users and volume to their dapp as possible

‍

One of the main limitations here for dapps is that transaction flows and UX are limited to how these 3rd Party Wallets work with the base blockchain protocol + lock ins to ensure ecosystem compatibility. Thus, the majority of dapps just have to accept the status quo.

What is great about the Uniform UX is that there are no limitations. Granted it will always be the case a 3rd Party Wallet will not know what the dapp UX would look like and that's totally fine, but it can provide and empower Dapp builders with base functionality at a core level (much like how we see wallets supporting Swaps and Cross chain aggregators natively in their wallets nowadays) to easily allow dapps to curate their own UX on top.

This is why Account Abstraction (in any form) is powerful because it can at least provide some of the base and consistent functionality that all users and developers deserve.

The Uniform UX baked into 3rd party wallets can solve many problems from day 1 so that dapps don't need to reinvent the wheel, especially dapps that are finding PMF, just want to get started or utilise the existing majority users that use these wallets. This kicks in the a flywheel as the more users using 3rd party wallets, the more market dynamics compel Dapps to always support these wallets because of the number of users they have.

Imagine Metamask just provided users to sign in with email from day 1, you then received USDC and then spent USDC whilst all paying your transaction and gas fees in USDC itself. It fundamentally changes the way dapp developers will interact with these wallets and how users will interact with them too.

We’re slowly seeing this through Trust Wallet, and Coinbase building smart accounts to enable these experiences, in different ways. TW mobile app optimising for passkeys and paying gas in different tokens. Coinbase smart wallet focuses on a Web UI (No app/extension) that’s easy to use and get users to transact seamlessly, and only afterwards they can start to ‘power up’ for enhanced features.

Now imagine you’re connecting to a dapp and you as a user want some guarantees the dapp you’re connecting to can only have access to certain things and not others, well, with a lot of work happening on permissions, and session keys by Biconomy, WalletConnect and may others, this future is definitely not too far off. By having this advanced permission functionality at the wallet level, Dapps can curate these extra guardrails.

Although the above are great strides, the majority of users are on EOAs and getting users to migrate their assets from EOAs to smart accounts is a big challenge. Another reason the Uniform UX is structurally challenging for many wallets is because they have to think about new behaviours that will change the way their wallet works as well as serving existing users, as well as ensuring there is dapp compatibility. This is why EIP 7702 is extremely important because it provides the groundwork for Uniform UX, consensus on the upgrade path, and accounts of any nature can work with all dapps. Hence upgrading users from EOAs to smart accounts will not be a roadblock anymore once EIP 7702 is in!

‍

B. SuperApp Wallets

Another interesting direction we might see wallets taking or what we’re seeing take shape is the concept of SuperApps, which has been written about here and here.

There are three type of Superapp wallets:

1. App store: It’s a powerful wallet with native apps, going beyond what typical wallets provide. It resembles an app store-like experience where instead of interacting with dapps on a standalone interface, you can interact with a variety of dapps in the wallet as well as enhancing the security of your wallet easily.  
   We’ve already seen some Superapps in the making such as the Safe App Store where currently the user does not need to leave the wallet. They can have their experience all in the Safe UI. It's like a browser for web3.

2. Everything app: Superapps can come in the from specific app use cases which drives mass adoption for an initial use case before it can become an ‘everything app’.
3. Existing Wallets: Metamask and its counterparts can also be seen as SuperApp wallets (because users can easily do in wallet swaps, staking etc in the wallet directly), and as menrtioned above the UX itself can be far more advanced given the increased scope a Uniform UX provides (largely through smart account capabilities)

Regardless of the wallet type (3rd party based or SuperApp based wallet), a Uniform UX, will radically change how both users and developers interact and build curated experiences.

‍

Dapps (App based wallets and Embedded Wallets)

Lets diverge a bit from the ‘Fat Wallet’ thesis. The Dapp thesis essentially means Dapps own the users and a wallet thus becomes a means to access the dapp. This gives rise to Dapps willing to curate their own experiences either by building their own wallet or building a fully fledged end to end experience like we have seen through embedded wallets where they control the UX and the user journey (like how we see in Web2).

‍

A. App Based Wallet

AKA Let’s build a Insert Popular dapp Wallet

Speaking from a Dapp perspective, the real pain is not knowing what wallet a user is going to connect with. So developer teams have to try to account for potential wallets. And most Dapps we see try to connect with all through popular libraries and integrations like Wallet Connect.

During the Dapp’s journey, be it right from the beginning or when they’ve amassed a big user base, there is a sound argument that dapps want to own the users (here I mean the relationship, not securing and custodying keys). We can clearly see Dapps/Appchains such as Uniswap, Ronin, Magic Eden and more have already gone into the direction of owning the user in the form of pushing users to use their wallet for their app/ecosystem. Yes, users, if they ‘power up’ can export their key and use any wallet, but in the minds of new users, if I want to or I’m recommended to use Uniswap, wouldn’t it make sense to use Uniswap Wallet to access the app? This doesn't mean that all dapps will stop supporting other wallets, but rather direct users to use their wallet to connect to the dapp instead. We have seen some dapps go the route of tying their wallet strictly to their application and most recent examples of this can be seen in Web3 gaming with examples like Gunzilla.

However, this route is probably not the best one moving forward because of a number of challenges:

• Protocols and app front ends will still want to allow users to connect any wallet so not to limit the number of potential users
• What extra value add, other than brand value, will these app specific wallets really provide for their user
• Users still suffer from the previous UX and feature challenges showcased in the previous section

‍

The same way 3rd party wallets/extensions can utilise the Uniform UX to completely improve their wallet, so can App based wallets.

‍

B. Embedded wallets

In the context of embedded wallets, within this paradigm, we have seen many use cases where Dapps can curate the UX either through the standard MPC/EOA infrastructure or utilising the Smart Account 4337 model where MPC/EOA is used only as a signer for the smart account and not as the users wallet. It is no surprise using 4337 infrastructure is becoming easier for dapps to integrate, although some challenges exist such as higher gas, gas estimation difficulty, and new infrastructure stack developers need to learn about. The migration painpoint doesn't exist here because Dapps are willing to get users to migrate assets to their Dapp (in this case to their embedded EOA or Embedded Smart Account). If users want to use the app, they will move their funds to a designated address shown to the user no questions asked. We have seen this model proven out with apps like Friend Tech and Alfafrens leading the way.

Dapps/appchains owning this user journey means they’re willing to have tighter integrations between the wallet interface and their dapp. The wallet can even be invisible as far as the user is concerned, where the user has come for the app. When it comes to the Uniform UX, well, its up to the dapp to decide what it should look like because they know their users better and know what they’re optimising for. Additionally, they have access to a wide range of tools to enable best in class experience that standalone wallets will not be able to provide.

With embedded wallets, we do see some challenges. Fragmentation exists because most dapps using embedded wallets are siloed. So if I sign up with the same email on Dapp A and Dapp B (and the backend uses Privy/Web3Auth as an embedded wallet provider), then as a user I will have and see two different accounts. Global wallets solve for this (which a majority of embedded wallet providers are moving towards). This means if I sign in with the same email, the account/identity I had previously with an app, will also exist on other apps that integrate the same embedded wallet provider (think Sign in with Google). This will nicely solve account and asset fragmentation across single chains and multichain. It additionally enables a unique identity layer for dapps to know more about their users and allow users to build up a history. As consumer Dapps continue to proliferate, it is no surprise global embedded wallets will continue to grow and potentially compete with 3rd party wallets such as Metamask or Rabby.

The Uniform UX we talked about earlier, isn’t only reserved for 3rd Party Wallets, App based wallets and Superapp wallets. They are also extremely relevant for embedded wallet providers who currently sit around the ‘Status Quo’ or in between the Status Quo and Uniform UX. This is because of two major reasons:

• We’re yet to see a major embedded wallet provider fully enabling smart accounts only which by default will get them to supporting a Uniform UX
• Till now, Dapps integrate both an embedded wallet provider and a AA provider together to achieve and enable a Uniform UX in their dapp

‍

As mentioned earlier, the goal is to ensure Dapps have to do as little work as possible and this will happen once a Uniform UX is available across all 3rd party wallets, app wallets and embedded wallets alike.

We talked about what a Uniform UX looks like, why it’s important and how it relates to 3rd party wallets, SuperApp wallets, App based wallets and Embedded wallets. I couldn’t end this article without exploring how chain abstraction fits into the puzzle, especially since the majority of the UX hurdles we see are from the tens, hundreds and soon thousands of chains users and developers will have to deal with.

‍

Chain Abstraction

Most of the AA integrations and overall majority of dapps in Web3 are on a single chain instance. This means users either know they’re on a particular chain or they don’t, but from a transaction perspective in nearly all cases it's on one chain.

The next step is the multichain instance because we can now finally start to solve the excruciating pain points we’ve been burdened with for a while such as:

• Bridging tokens and assets
• Having gas on all networks you’re transacting on
• Knowing which chain and having to manually connect
• Multiclick transactions in a multichain setting
• Devs having to build a replicable instance for every chain - the way dapps will build in a chain abstracted world will be radically different to today
• Hard to try new apps on different chains

‍

Just imagine if we can live in a world like this allowing seamless payment from funds spread across my accounts to purchase an NFT on Solana.

Chain Abstraction is unique because it enables a framework for UX that serves users on both ends of the spectrum (newbies and degens) and it's up to the dapp and wallet to configure how much of Web3 they should make invisible. Depending on the actual user, not all UX is created equal (Uniform UX powers the transaction flow and design choices for different users). One user might use 3 chains and would have no idea because it's hidden, but an experienced degen knows they’re using 3+ chains and wants an easier way of doing things. Chain abstraction is for all.

This is why Account Abstraction is unique in its current form. It has the potential to transcend from being a great single chain solution to becoming a critical chain abstraction infrastructure that will power the next wave of use cases and user onboarding. Dapps do not want to introduce friction if they are multichain first or decide to go multichain.
Additionally, for a new L2 coming to market, you want to easily enable users to access your chain very easily. With chain abstraction, users from all chains now become the market.  

Chain abstraction is becoming a more and more relevant topic, albeit in its early days. All wallets (regardless of the type) will support as many chains as it can because the market demands it and in order to enable seamless flow and interaction (which the market is continuously demanding), chain abstraction will most likely be a default.

‍

Conclusion

As an industry, we should strive towards the Uniform UX that users deserve, regardless of the recent EIP/ERC fiasco. Without the Uniform UX, it’s as if all we’re asking for is faster horses. By removing friction, we expand markets, exponentially. And what better way to remove friction is by increasing the possibilities wallets can enable at the core layer and what dapps can do once the Uniform UX exists.

All wallets, regardless of the type, will transition to the Uniform UX, once we see critical mass and the sooner we get there, the better. During that process it is important for all builders and developers to look out for ways we can bring this Uniform UX to life. I believe smart accounts and tooling around this inevitable future are the building blocks towards this.

Dapps should build with smart accounts, WaaS providers can look to prioritise smart accounts and wallets of all types can easily scope how smart accounts can be part of their strategy (many have already undergone this exercise).

In that process, wallets will have more robust features, users get a better experience, and dapps will have better tools to build with. We ultimately believe that given smart accounts sit at the heart of this upcoming transformation, it feels like an iPhone/App store moment is in the making.

‍
------------------------------------

This piece was authored by Ahmed Al-Balaghi

Acknowledgements by Author

I wanted to involve as many builders in the write up of this article. In no particular order, thank you to those who have contributed:

Ben Basche, Ankit Chiplunkar, Ankush Swarnakar, Derek Rein, Graeme Barnes, Kurt Larsen, Noam Hurwitz, Matti G, Max Mironov, Hasu and Rapolas  

‍

‍