Intents explained: declarative constraints, solvers and mempool designs
Post1,973 words
Explains intents versus transactions (declarative outcome vs imperative path), solver roles, MEV implications and three intent propagation designs: permissionless, permissioned and hybrid mempools, with use cases.
Key claims
An intent is a signed set of declarative constraints delegated to solvers (Paradigm definition)
Ethereum's mempool cannot propagate intents, so specialized solutions are needed
Permissioned intent pools are appealing short term but conflict with blockchain principles
WTF are Intents and why you should care?
Intents will change the game, anon! 🚀
Are you ready to capitalize on it or are you fading yet another narrative? 💸
Let me walk you through:
🤖 The concept of Intents
⚙️ The Tech behind it
🚀 Use Cases
🔮 Outlook
🔍 Conclusion
⚠️ WARNING: The below content might make you overly bullish. This is not financial advice and I strongly discourage apeing one narrative with your entire net worth.
🤖 The concept of Intents
As web3 technology advances towards mass adoption, it is important to ensure that users can navigate the complexities of the web3 landscape on their own. In contrast to the early days of blockchain, where users had to understand intricate technical details, the future lies in providing a UX that guides and empowers users to effortlessly interact with decentralized systems.
Taking inspiration from the evolution of web2, where user needs were met with user-friendly tools like search engines and chatbots such as ChatGPT, web3 must deliver a powerful experience that is also easy to use.
In this new post series, I will explore how the confluence of technologies such as Account Abstraction and Intents will reshape UX in the crypto space and enable novel use cases that will finally lead us into the era of mass adoption. 🔮✨
Today, we start this series with an in-depth exploration of the concept of intents. ⬇️
So, in order to understand intents, we have to understand where we currently stand and how crypto UX looks today.
When we interact with a blockchain or an application that is built on-chain, what we basically do is express the desire to get something done. We want to swap a token on uniswap, we want to transfer tokens from A to B or we want to provide liquidity, or whatever it might be.
However, there are different ways to express that desire! ⬇️
In the current, transaction-based flow, we have to give very specific instructions by signing transactions with our private key for every step of the interaction (approve tokens, sign transaction, etc.). This is an imperative paradigm of concise order & execution.
With intents, this is fundamentally different. If a transaction explicitly specifies the method for performing an action, an intent specifies the desired outcome of that action, creating a declarative paradigm.
For example:
▶️ A transaction may state: "do A then B, pay exactly C to get X back"
▶️ An intent would express "I want X and I'm willing to pay up to C.”
An analogy I like a lot to simplify this a bit using a familiar concept is one that @WinterSoldierxz recently used, comparing transactions and intents as follows:
💸 Transactions
Transactions specify an execution path (specific location, store and item)
▶️ E.g. I go to McDonald’s two blocks down to buy a Big Mac meal with fries and coke zero for $8
This translates well to your typical on-chain transaction, where you swap:
- For a specific item (Token)
- At a specific location (Chain)
- A specific store (DEX)
- At a specific Price
🤖 Intents
Intents specify a desire
▶️ E.g. I want a burger with fries and coke zero
As buyers, we express intent and allow third parties to fulfill our desire in exchange for value
You specify your requirement and some conditions for fulfillment, without specifying where it’s from or how it’s obtained
@WinterSoldierxz suggests to think of intents as unfulfilled transactions:
McDonald’s can fulfill your intent. So can Five Guys, In-N-Out, or the bodega at the street corner.
Rings a bell? It should! Every time you use Trip(.)com or Uber Eats you're tapping into an intent network. These typically provide greater access to information and sellers, and complete txns far more effectively and efficiently than you can by specifying your own path of execution.
⚙️ The Tech behind it
So, now that we understand intents conceptionally, how can we define intents in more technical terms? A definition I like a lot is the one by @paradigm:
“An intent is a signed set of declarative constraints which allow a user to outsource transaction creation to a third party without relinquishing full control to the transacting party”
Let’s put that into the context of blockchains! ⬇️
This declarative paradigm introduces exciting improvements in user experience (UX) and efficiency. With intents, users can simply express their desired outcome, leaving the task of achieving that outcome to sophisticated third parties. This is in contrast to the current imperative paradigm, where every parameter is explicitly specified by the user.
While these improvements hold promise for the web3 space, intent-based designs on Ethereum can also have significant implications for off-chain infrastructure. In particular, there are important connections to activities related to MEV (Miner Extractable Value) and market control.
In the standard transaction-based flow, a transaction signature enables the validator to follow a specific computational path against a particular state.
In contrast, an intent does not specify a specific computational path, but rather allows for any path that satisfies certain constraints.
When a user signs and shares an intent, they effectively grant permission to what is referred to as “solvers” to choose a computational path on their behalf (see figure below). This distinction allows for a slightly more precise definition of intents as signed messages that permit a set of state transitions from a given starting state. A transaction is a special case of an intent that allows for a unique transition.
Importantly, many intents can be included in a single transaction, allowing for matching overlapping intents, increasing gas and economic efficiency.
So how can we make intents a reality? ⬇️
The Ethereum mempool is limited. For some applications, this is due to its lack of privacy (sandwiching) and for others, it is due to its inability to support broader message formats. Unfortunately, the current design does also not support the propagation of intents and will not be able to do so in the foreseeable future. As a result, specialized solutions need to be developed for this purpose, and developers working on intent-based apps will need to make specific design choices. One important decision is whether intents will be propagated to a permissioned set of solvers or be available in a permissionless manner, allowing any party to become a solver and execute the intent.
In principle, there are three high-level designs:
🔓 Permissionless Mempools
One potential design to aim for is a decentralized API that allows the distribution of intents across multiple nodes in a system, providing unrestricted access to solvers.
This approach has been previously implemented. For example, in the 0x protocol, relayers communicate and share limit orders among themselves through gossiping, and record them on-chain when a match is found. The concept is also being explored in the context of a shared ERC4337 mempool, addressing concerns regarding centralization and censorship risk. You can find more information about this idea here.
🔒 Permissioned Mempools
A centralized API that is trusted is more resistant to DoS attacks and does not require intent propagation. This trusted model also provides some protection against MEV concerns. As long as the trust assumptions remain valid, the execution quality should be guaranteed. Trusted intermediaries may also have reputations associated with them, which incentivizes them to ensure good execution.
For these reasons, permissioned intent pools are appealing to intent-based application developers in the short term. However, it is important to note that strong trust assumptions have limitations and are somewhat contradictory to the principles of blockchain.
🔐 Hybrid Solutions
There are solutions that combine elements from the options mentioned above. For example, one could have permissioned propagation but permissionless execution (assuming trust assumptions hold), or vice versa. An example of a hybrid solution is order flow auctions. The main concept behind these designs is that users who require a counterparty may need to differentiate between better and worse counterparties, such as to trade at a favorable price.
The typical design flow involves a trusted party who receives the intents (or transactions) from the user and facilitates the auction on their behalf. Participation in the auction is sometimes permissionless. However, these types of designs have their own limitations and are likely to face similar concerns as permissioned intent pools.
🚀 Use Cases
As outlined in the introduction to this post, intents have great potential to revolutionize the UX of web3! I will dive into intent-based applications in-depth in upcoming posts. Today I will only outline some high level insights.
▶️ Smart Wallets: ERC-4337 introduces the UserOps layer, which allows users to express their intent and compile it into executable signed transactions. The growing number of ERC4337 users, facilitated by modular smart accounts such as ZeroDev, Biconomy, and Safe, has the potential to lead to the development of Smart Contract Wallets (SCW).
▶️ Intent-based RFQ DEXes: Intent-based trading aims to enhance capital efficiency and user experience in decentralized exchanges (DEX). Innovations like CoW Hooks enable complex actions such as trading, bridging, staking, and deposits. Platforms like UniswapX allow off-chain matching and on-chain settlement through solvers. Emerging Intent-based swaps like BananaHq, Brink, and Based Markets are transforming the DEX landscape.
▶️ Builder-maintained Orderbooks (as proposed by @jump_ ): Two orders can be netted against each other before going to a market. The design suggests traders leverage Flashbots and the existing searcher network (acting as solvers) to emulate an order book matching engine. However, this design has inherent limitations and significant tradeoffs compared to alternative solutions involving centralized servers or specialized networks.
▶️ Intelligent Interaction Gateways: In a similar manner to how TG Bot has revolutionized the frontend interaction interface for Web3, interaction gateways now place importance on understanding user intent and converting it into automated, actionable tasks in a systematic manner. This transformation goes beyond TG Bot-like trading bots and includes Web3 AI agents and Web3 smart search engines, all working together to make Web3 interactions smarter and more intuitive.
▶️ Cross-domain intents: Instead of performing multiple transactions on different domains, a single message is used to execute seamless cross-chain interactions. This approach also incorporates various replay resistance schemes and offers more flexibility in user gas payments. For instance, it allows third parties to sponsor gas or enables payments in different tokens.
🔮 Outlook
Looking ahead, intents are generating renewed excitement in the context of cross-chain MEV (e.g. SUAVE) and ERC4337-style account abstraction. The former will improve the efficiency of on-chain interactions across networks, while the latter has the potential to revolutionize general user experience.
However, due to the limitations of Ethereum's mempool design and the lack of mature solutions, wallet and application developers face challenges in connecting users to the blockchain while without compromises on certain security/trust assumptions
While teams like Flashbots (SUAVE) and @anoma are working on general-purpose solutions that combine privacy and permissionlessness, the ideal system is unlikely to be ready in the near term. Therefore, different solutions with their own tradeoffs may serve different applications best. I anticipate a wide range of design possibilities to emerge around the concept of intents!
🔍 Conclusion
The adoption of intents represents a shift from an imperative to a declarative paradigm. This shift promises to significantly improve user experience (UX) and reduce efficiency loss caused by Minimal Extractable Value (MEV) leakage. The demand for these applications is clear, and intent-based applications have been widely used for several years.
The growing adoption of intents, partly driven by ERC4337, is likely accelerating a move from the Ethereum mempool to new venues. While this move is justified and inevitable, designers of intent-based applications should exercise caution when designing the off-chain components of their systems, especially while robust infrastructure is still being developed.
That's a wrap for today! I hope you enjoyed this deep dive! 🫡
Make sure to follow me @zerokn0wledge_ and stay tuned for more insights into the world of intents and AA. ✨
3 more images on X