A Focus on Intent-Based Architectures: The Good, the Bad, and Why Care

Picture this: you’re a new web3 user and wanted to degen some rETH on Arbitrum with your USDC on Ethereum Mainnet. You have no clue where to start and how to do it. You don’t know about bridges, or swaps, and what are the cheapest and safest options that are available for you.

So you Google: ‘How to buy rETH on Arbitrum with USDC on Mainnet’

The search results are all suggesting different options. And the sheer amount of time just reading each of them has taken at least 30 minutes and it still doesn’t give you any clear choice for your problem.

The requirements are very simple but there seems to be no straightforward answer for you.

Now imagine a magic search box where you can type ‘Buy at least 0.5 rETH on Arbitrum with 1000 USDC on Mainnet’ and an agent will process all the necessary transactions for you. You don’t have to do your research and make choices—the system does that, you simply just need to specify what you want to achieve.

That is what intents are for.

But it is not magic. Under the hood lies an infrastructure that powers this technology.

A Deeper Look Intent-centric Architecture

To simplify, all intent architectures consist of four main components:

• Client
• Intent Pool
• Solvers
• Settlement

When a user signs an intent through a client, it goes to a pool that is discoverable by a bunch of counterparties called Solvers. Solvers compete to give the most efficient path to solve given the intent’s constraints, and in exchange, they keep whatever arbitrary fee they set for solving each intent.

But isn’t that just a limit order? Yes, too. The concept of declarative orders isn’t new in the space.

We’ve already seen UniswapX, 1inch, CowSwap and other aggregators use a similar infrastructure. It solves for the user intent to buy a minimum amount of tokens for a maximum price to be paid. As a matter of fact, there are already DEXes with no frontend like Ekubo that only uses aggregators to route to their liquidity, yet manages to get 70% of StarkNet’s total trading volume.

Intents have generated significant buzz recently, as examining transactions through the user's perspective unveils a whole new ecosystem and introduces concepts that have the potential to reshape how developers approach user experience in web3. But intents, broadly speaking, encompass any expressed goal to change from one state to another.

Are Intents Different from Limit Orders?

Right now we have protocol-specific solvers that can find the best route for people’s limit orders. Limit orders are intents. The terms can be interchangeable as of the time of writing as intent-based systems are mostly being used for limit orders. Let’s look at a typical RFQ (Request for Quote) for instance:

Remember, any signed transaction is an intent. For example, sending 1ETH to your friend’s wallet:

Then, there are many complex intents. So we can have multiple solvers to compete for the best route to do them:

It shifts the focus from imperative (the user needing to define the flow of operations) to declarative (the user only defining what they need to accomplish). The solvers become increasingly useful as the intents they solve become more complex.

Intents are currently being used in DeFi, but imagine the use cases in different verticals. For instance, in NFT marketplaces, what if a user wanted to buy an NFT that was previously owned by a celebrity address for a maximum specified amount? There can be an intent market for NFTs, too. Or in DePin, imagine Bittensor, but you only want to provide your compute and knowledge to AI models that you think are safe and ethical– an intent-based architecture might be able to help in that case.

Account Abstraction + Intents = UX on Steroids

Intents aren't new, and the concept of giving users a way to outsource their transactions while still maintaining full control of their wallets has spurred the creation of infrastructures that enable it. The most popular of them is ERC-4337.

Account Abstraction has components that can make solving intents so much easier:

·          Gasless transaction: if the user can transact without worrying whether they have the right amount of a specific token, then intents get exponentially easier to solve.

·           Delegation: pre-authorizing the wallet to only interact with specified accounts enables the user to still have control over who gets to solve the intents and avoid untrusted actors from hijacking the transactions.

·           Bundling: solvers can batch intents for gas efficiency

You can create a smart contract  wallet for your users using just their social logins through Web3Auth’s integration with partners like Safe, Biconomy, 0xPass, and many more. And we made it so much simpler with our account abstraction partners.

There are also newer proposals on ERC-4337’s alt mempool infrastructure that can lessen the pitfalls of using intent systems, but more on that later.

The Good: Death to Extractive MEV

The pool where expressed intents go has a very different mechanics from the mempool where blockchain transactions go. In the mempool, MEVs are paid to extract as much value from the users. But in the intent pool, the solver wins an auction by providing the lowest cost or most efficient pathway for the user.

Instead of the user needing to pay a maximum fee only to get refunded later, they are immediately given the best price, practically eliminating the possibility of being exploited for the maximum amount of fees possible.

The Bad: Centralization Risks

Everything good that was said about intents will only work if there are enough solvers competing with each other. If there is a monopoly of solvers then the whole incentive system flips because the dominating solver will have unchecked power to decide on how the transactions in the pool are executed, regardless of whether it’s the optimal route or not.

If solvers are competing to be the most efficient ‘router’ of the intent, then they will rely on transaction simulations that will require them to have the latest information before the block is produced. The participants who have this kind of information advantage are the block builders. Therefore, solvers are also incentivized to become block builders as well. As a solver dominates the intents market, they will also become bigger block builders and so the cycle of centralization starts.

To reference how intent pools can prevent this from the design, we can reference this ERC-4337 proposal to see how similar architectures can use unified pools. Lessening the fragmentation among intent pools can increase the number of solvers and decrease the likelihood of centralization.

Why Care?

The chief motivation for further developments on already existing intent systems is that it can dramatically lower the knowledge requirements and simplify the steps for anyone who wants to get started in interacting with web3 protocols.

And there is no better time to tackle and coordinate early iterations of UX-driven infrastructures like ERC-4337, wallet creation and authentication, and solver auctions than today. Here at Web3Auth, we put the user at heart, both end users and devs alike and stay tuned for more updates that will pave the way for a future driven by user intents.