From Meta-transactions, Account abstraction to Intents: Evolution of DApp-User Interactions

We have seen the evolution of user interactions in web2 from complicated command lines to graphical user interfaces that brought mass adoption to now intuitive natural user interfaces like voice. Web3 UX is seeing a similar evolution.

‍

Most instances of dApp-user interaction in web3 is a transaction. Original transactions & EOA wallets were complicated. Meta-transactions & now account abstraction are bringing us to a more simpler experience. And intents will be cherry on the cake which will make interacting with dApps as intuitive as talking to a human.

‍

‍

Let’s look at the evolution of dApp-user interactions & how they may look in the future.

‍

EOAs & Transactions

The command line interface era

‍

The traditional way of interacting with a dApp is to send a transaction to the Ethereum Virtual Machine (EVM) with your wallet (EOA). But this has always been a complicated process. This is because all the onus is on the user to manage everything. From wallet to nonce to calculating & paying gas.

‍

The complexity is kind of like the command line interfaces of the computer of the olden days. You had to type pretty much every detail on the command line, which was complicated to look at and required considerable knowledge to operate.

It involves, first and foremost, creating and maintaining an EOA (externally owned account) wallet. Understanding what it is, saving the seed phrases, and being comfortable with having no recovery mechanism.

‍

Then comes the part of gas and transaction management. Having tokens in your wallet to pay for gas is a major headache. Then being able to accurately manage nonce. And pre EIP1559, being able to estimate the right gas on your metamask advanced settings to perfectly balance between avoiding failed transactions and overspending on gas.

‍

And as almost every interaction on a dApp is a transaction, there are tons of unnecessary steps. Approval transactions, signature pop-ups at every step, 4 different transactions to complete one task and so on.

‍

Thus, the key friction points in web3 UX were twofold - wallets / accounts and transactions / interactions.

‍

In the initial days, web3 UX was completely broken and siloed for only pure degens.

‍

The first evolution: Relayers & Meta-transactions

The first major innovation in web3 transactions was meta-transactions. Or as Biconomy has pioneered them as - Gasless transactions.

‍

The idea is that the user doesn’t need to pay gas, or own native tokens to pay for gas. They also didn’t need to manage the transaction. The relayers did all of that on their behalf. Thus, for web3 users, specially newbies, interacting with a dApp became a lot easier. Just onboard, create a wallet, and start using the dApp as they don’t need to worry about gas or failed transactions.

‍

The improved UX with gasless transactions caught on in the industry. We supported 300+ dApps with 36 million gasless transactions.

‍

Such concepts such as relayers and meta-transactions simplified one part of the friction points in web3 UX - transactions/interactions.

‍

Account Abstraction & Smart Accounts

The Graphical User Interface Era

‍

The other part of the puzzle - wallets / accounts - is where account abstraction comes in.

Account Abstraction has been a buzz lately. And rightly so, as it brings huge UX improvements. Account Abstraction brings ‘programmability’ via smart accounts and standardised implementation of relayers.

‍

Smart Accounts make it extremely easier for anyone to onboard. Newbies can onboard & create a wallet via email or fingerprints. No need to save long seed phrases. There’s also the possibility of recovering your account. And crucially, smart accounts bring programmability - devs can customise all aspects of the UX to suit specific needs.

‍

‍

And AA also enables the benefits of meta-transactions on steroids.

• Users can enjoy gasless transactions and paying gas in any token
• AA enables one-click UX where multiple transactions get bundled together into a single transaction for the user
• AA also allows the dApp to remove redundant steps like approvals & tons of pop-up signatures with session keys

‍

This one click intuitive UX that AA enables is like the evolution of graphical user interfaces (GUIs). Compared to command line interfaces, GUIs were intuitive. You didn’t need to write lines of code to get something done, you just needed to do a couple clicks with the mouse. You can ‘read’ what each click can do and most of the steps to make it happen get abstracted in the background.

‍

And most importantly GUIs, like account abstraction, made computers ready to be used by the masses and the normies.

‍

The advent of Intent  

The Natural User Interface Era

‍

As GUIs evolved, interacting with apps became more natural - touch, gestures, voice etc. You can just say ‘Alexa! Play Calm Down’. Instead of opening Spotify, typing the song name, & clicking on play. All those steps get abstracted from you.

‍

That’s what intents plan to do for web3 interactions. Users can state what they want - ‘I wanna get yield on ETH. I have USDC’. Instead of doing all the steps themselves - swap USDC to ETH, find the protocol with best yield, approve & then supply ETH liquidity.

CowSwap is a project where we can already see a live example. CowSwap users sign an intent to swap a token at a specified limit price This intent is then handed off to a third party (solvers) which compete for the user's order flow by giving them the best price. Solver with the winning bid then gets the permission to execute this order on behalf of the user.

‍

Intents help ‘translate’ what the user wants from natural conversational language to the required blockchain transaction bundle & steps to make it happen. Third parties can take these the desired outcome along with the constraints mentioned by the user (known as intents) & execute them on the blockchain. This essentially abstracts all associated complexities from the user. And the beautiful part is that this ‘control’ is given to a third party to execute these transactions in a constrained manner. The user is essentially granting a third party permission under certain parameters to figure out the right transaction path & build the bundle of transactions required to execute the required ‘intent’.

‍

However, it’s not all rosy. Intents are a new direction and have various potential risks that the industry will need to mitigate. These include figuring out how to be trustless and permissionless. Read this amazing article by Paradigm on some of the risk considerations of intent based architecture.

‍

How would Account abstraction and smart accounts be compatible with Intents?

Intents are a layer of abstraction on top of the powers of account abstraction. Additionally the user would use smart accounts as their base wallet to access dApps and manage their assets. And ERC4337 gives a standardised way to enable users to let the third party execute these order flows on their behalf. Thus, there's a strong synergy between smart accounts & intents.

Intents will be successful standing on the shoulders of giants such as account abstraction. We will release more insights on the interesting play between AA & Intents, so follow us on twitter.

‍

Conclusion

There’s still a long way to go before we can properly implement ‘intents’ into popular dApps, but it gives us a glimpse into the future of web3 UX - As simple as web2 yet with all the powers of web3. And it's a natural evolution of web3 UI after the adoption account abstraction & smart accounts.

‍

‍