Intent-Based Architectures and Projects Experimenting with Them
Using current systems in Web3 proves to be a complicated and time-consuming endeavor. It involves specifying an execution path across diverse infrastructures, which requires a thorough understanding. Consequently, users face constant frustration in achieving their end goals and are vulnerable to exploitation by more sophisticated actors. This situation arises because the prevailing standard method for users to interact with Ethereum involves crafting and signing transactions in a specific format that provides all the necessary information for the Ethereum Virtual Machine (EVM) to execute a state transition.
Intents were introduced to ease the burden on users. In essence, an intent is a set of declarative constraints that allows a user to delegate transaction creation to a network of specialized third party actors while retaining full control over the process. In simpler terms, if a transaction specifies “how” an action should be executed, an intent defines “what” the desired outcome of that action should be. This declarative approach brings about exciting advancements in user experience and efficiency. With intents, users can effortlessly express their desired outcomes. This stands in stark contrast to the current imperative paradigm of transacting, where every parameter must be explicitly specified by the user.
This blog post aims to explore approaches to achieve such a declarative paradigm. Additionally, it will delve into why Account Abstraction alone falls short and provide an overview of projects that are currently exploring the concept of intents.
Transactions are a dead end for end users
The current transaction-based approach in Web3 proves to be complex and therefore leads to a suboptimal user experience and a loss of efficiency, as users are compelled to make decisions without having sufficient access to information or employing sophisticated execution strategies.
To illustrate this complexity, consider a scenario in which you wish to interact with a decentralized application (dApp) on the Arbitrum network, but your funds are currently stored on the Ethereum blockchain:
- Visit the dApp website
- Attempt to connect your wallet to Arbitrum but discover there are no funds available
- Open a new tab to explore the best way to bridge your funds
- Go to the bridge website
- Connect your wallet to another blockchain (Ethereum)
- Initiate the bridging process to transfer funds from Ethereum to Arbitrum
- Wait for the bridging transaction to complete
- Return to the original tab
- Switch your wallet back to Arbitrum
- Now, you can finally use the dApp on Arbitrum with the bridged funds
Even before the user has a chance to interact with the dApp itself, frustration sets in. These issues become even more pronounced in a world of million rollups.
So how can we make such a shift from an imperative to a declarative paradigm? To understand the basics, let me first give a brief summary of Account Abstraction (AA) based on articles by Alchemy and Stanley He.
Short recap on Account Abstraction
In Ethereum, there are two types of addresses: smart contracts and external-owned accounts (EOAs). While EOAs have the ability to initiate transactions, smart contracts lack this capability. As a result, the majority of Ethereum wallets used today are EOAs. Although there are smart contract wallets (SCWs) like Safe, they require EOAs to trigger any transactions since smart contracts cannot initiate them on their own. Nevertheless, SCWs offer significant advantages as they can execute complex logic, enabling a wide array of new applications for wallets, while EOAs are limited to transaction signing.
To address the need for SCWs without requiring a separate EOA, ERC-4337 introduces a novel transaction type known as User Operation (UserOp) and introduces a new role called “Bundlers.” Furthermore, ERC-1271 (Standard Signature Validation Method for Contracts) introduces standard way for any contracts to verify whether a signature on a behalf of a given contract is valid. This is possible via the implementation of a isValidSignature(hash, signature) function on the signing contract, which can be called to validate a signature. These updates enhances the user experience with SCWs, enabling a smoother flow for users. The process is as follows (as also depicted in the illustration below):
The user signs a UserOp, specifying the desired operation. Instead of sending these UserOps directly to the main mempool, multiple users send their UserOps to an alternative mempool. Here, executors and bundlers come into play, bundling these UserOps together and submitting them as bundles to an entry point contract. This entry point contract then communicates with the smart contract wallet.
Once the SCW receives the bundled UserOps, it goes through a two-step process. First, it performs a ValidateOp, which involves checking the appropriate signers, access control, and rate limiting to ensure the operations are legitimate and secure. After successful validation, the SCW proceeds to execute the operations using the ExecuteOp function. These operations could include tasks like transferring funds, executing swaps, or purchasing NFTs.
One of the key benefits of Account Abstraction is gas abstraction, which simplifies the gas payment process for users. This is where paymasters come into play. A paymaster contract acts as another entity. When a user sends a transaction, the UserOp is sent to the paymaster contract. The paymaster then validates and ensures that it will cover the gas cost for the transaction. It sends the corresponding amount of native gas tokens back to the bundlers, acting as a refund mechanism. Only after this gas payment is taken care of, the UserOp proceeds to go through the ValidateOp and ExecuteOp stages.
The paymaster also offers a post-user operation hook, which allows for additional actions to be taken after the UserOp has been executed, providing further flexibility and control in the process. By utilizing paymasters and gas abstraction, users can carry out transactions without worrying about managing gas costs directly, making the process more seamless and user-friendly.
One limitation of AA is its inability to support cross-chain paymasters. Let’s consider a scenario where a user possesses USDC on a SCW residing on the Ethereum network but desires to use a paymaster to cover transaction costs on the Arbitrum network. The challenge arises when the paymaster attempts to transfer USDC from the user to the paymaster during the post-operation function. The USDC resides on Ethereum, while the paymaster contract is located on Arbitrum. Essentially, Account Abstraction is primarily designed for single-domain usage and lacks the inherent capability to operate seamlessly across multiple chains. However, we will get into that later.
Intent-specific applications
Account Abstraction is often reduced to “gasless transaction”, “seedless recovery”, and possibly “rate limit”. Yes, those are cool, but not cool enough. While these features are undoubtedly interesting, they may not fully capture the real essence of what makes AA truly remarkable. The most intriguing aspect of Account Abstraction lies in its architecture, which transforms wallets into the entry of intents.
So what is an intent?
In the standard process of transactions, when a validator receives a transaction signature, they are bound to follow a specific computational path based on a particular state. Additionally, a fee serves as an incentive for the validator to proceed in this manner. However, with intents, things work differently. An intent doesn’t prescribe a fixed computational path but instead allows any path that meets specific conditions. When a user signs and shares an intent, they grant recipients the authority to choose a computational path on their behalf. This distinction enables a more precise definition of intents as signed messages facilitating a series of state transitions from a given starting point. For a deeper understanding of the mathematical formalization of intent solving, I recommend reading “Lagrangian Mechanics of Intent Solving I” by Fabrizio Genovese.
Notably, a single transaction can include multiple intents, resulting in the matching of overlapping intents. This significantly improves gas and economic efficiency. For example, in a builder-maintained orderbook, two orders can be efficiently netted against each other before reaching the market. Furthermore, intents allow for more flexible user gas payments, such as enabling third parties to sponsor gas or accepting payments in different tokens.
Therefore, UserOps are not intents as they are basically transactions. However, AA makes wallets the entry of intents, enabled by the validation logic within a smart contract wallet. This validation logic allows for the expression and enforcement of simple intents concerning user accounts. However, the SCW lacks the ability to reason about global states.
Account Abstraction is fundamentally designed to serve “specific intents.” In this context, users can specify and enforce simplified intents through their SCW, as long as the intents meet certain restrictive requirements:
- They are single-domain focused
- They only use and enforce information related to the user account
- They involve gas reimbursement
Examples of intent-specific applications
As a result, Account Abstraction primarily caters to user-centric objectives. Nevertheless, there are numerous examples of “intent-specific” applications that can be achieved using AA as also highlighted by Paradigm:
- Limit Orders: Users can specify that 100 X tokens may be taken from their account only if they receive at least 200 Y tokens
- Gas Sponsorship: Users have the option to pay transaction fees in USDC instead of ETH, with USDC allocated in their account for covering the paymaster’s gas costs
- Delegation: It is possible to restrict interactions with specific accounts in pre-authorized ways. For instance, ETH can be designated for purchasing NFTs listed on OpenSea, or a particular address can be limited to interacting only with Uniswap & Sushiswap
- Transaction Batching: Users can allow the batching of multiple intents in a single transaction for enhanced gas efficiency
- Aggregators: Users can specify using the “best” price or yield for a particular action. This intent can be fulfilled by providing proof of executing an aggregation over multiple venues and selecting the optimal path
While AA and intent-specific apps are a significant advancement, they have their limitations, especially in a multi-chain environment. Let’s consider a scenario where I possess ETH and aim to purchase as much coin XYZ as possible, utilizing liquidity across various rollups. With AA, I can effortlessly and quickly employ my preferred DEX aggregator on any rollup. However, the challenge remains that I still need to manually discover the best DEX aggregator available across all rollups.
Hence, there is a need for a comprehensive and versatile language for intents that can effectively scale in a multi-chain world.
General purpose solutions
In an intents-centric world, users declare or sign their preferences, and the network relies on third-party actors (solvers/executors) to execute these preferences on their behalf. It’s important to highlight that the current transaction-based approach also allows the user to outsource transactions, but the difference is who that third party is. Right now, it’s applications who construct the transaction on behalf of the user, and they do so without optimizing for the best outcome. So the innovation with intents is not the ability to outsource transaction creation to a third party, but rather the addition of a network of specialized third parties who can provide better outcomes.
This can result in enhanced execution efficiency as these solvers can integrate more information regarding the state of other chains, without requiring communication with users.
To illustrate this, let’s revisit the scenario where I have ETH and my goal is to purchase as much coin XYZ as possible by utilizing liquidity across different rollups. In an intents-centric world, I can inform the mempool that I possess ETH and aim to acquire the maximum possible amount of coin XYZ. A highly sophisticated solver, who has invested significant effort in this multi-domain dark forest, will efficiently find a solution. The incentivization of these solvers should lead to fairly optimal outcomes. In this multi-chain landscape, even basic tasks become impractical for example a single company running a DEX aggregator to integrate with all the new rollups and domains. Therefore, intent-specific apps lack scalability in such a multi-chain environment. However, a flexible and general language for intents scales effectively because it operates as a permissionless system. There’s no need for a single company to act as the world’s DEX aggregator encompassing every chain. Instead, a pool of solvers can compete to serve users, with some specialized for specific rollup classes and others for different domains. This approach demonstrates that cross-domain intents hold significant utility and power beyond vanilla Account Abstraction, proving advantageous even for simple use cases.
The ideal infrastructure for expressing, communicating, and executing intents should minimize MEV (Miner Extractable Value), maximize censorship resistance, and be optimized for cross-domain interactions. Moreover, it should carefully consider the balance between granular user intent communication and user experience, as this decision significantly influences the architecture of the intents protocol. Also, numerous unanswered questions remain, such as how to demonstrate what is optimal, where the cross-domain intents will be posted, and how the solver will determine what to search for.
Examples of general purpose solutions
While the vision is promising, the first step is to establish an intent layer where users can express their intents and solvers can compete to solve them. Projects like Anoma, SUAVE, Essential, and CoW Protocol are all vying to become the intent layer for blockchains, using different methodologies. However, it’s still early to compare them as the concept of an intent layer is evolving, and many of its design principles appear to contradict each other. Building such a layer poses significant challenges.
Anoma is a unified architecture for full-stack decentralized applications. It is designed from the ground up for applications that involve infinite users, issuing infinite numbers of intents, each of arbitrary complexity. Anoma is designed following the principles of intent-centricity and homogeneous architecture / heterogeneous security, together constituting a declarative paradigm for building decentralized applications. Intents are submitted to intent gossip nodes, which form pools of intents. Matchmakers analyze the pools to find combinable intents that satisfy each other when combined. The protocol’s state machine enables step-by-step execution with decoupled validation, facilitated by validity predicates acting as invariants on user accounts. Anoma makes it straightforward to build novel applications that are otherwise clunky, limited or impossible to build on existing architectures including Ethereum (EVM) and Ethereum-like protocols.
SUAVE — the Single Unifying Auction for Value Expression. SUAVE is an attempt to empower users and maximally decentralize public blockchains. SUAVE unbundles the mempool and block builder role from existing blockchains and offers a highly specialized and decentralized plug-and-play alternative. Sharing the same sequencing layer allows crypto to stay decentralized, block builders to capture cross-domain MEV, validators to maximize their revenue, and users to transact with the best execution, while reducing the economic centralization pressure on each domain. SUAVE is an integrated environment that facilitates decentralized collaboration in expressing, executing, and settling preferences. The core concept is preferences, messages signed by users to express goals, enabling simple transfers or complex sequences across multiple blockchains. Executors compete to provide the best execution, including capturing MEV and offering decentralized order flow value.
Essential is developing a range of products to drive the transition from value extraction to intent satisfaction in the blockchain ecosystem. They are creating a domain-specific language (DSL) for expressing intents, an Ethereum standard for intent-centric account abstraction, and a modular intent layer. The DSL allows for standardized intent expression and optimization for solving, enhancing composability and development of intent-based applications. The intent-centric account abstraction standard empowers solvers to construct valid transactions based on user intents, bringing intent functionality to existing EVM chains. The modular intent layer ensures an intent-only architecture, aggregated orderflow, MEV resistance, and cross-chain intent execution possibilities. Essential’s mission is to empower users and eliminate exploitation, fostering a user-centric and equitable blockchain future.
CoW Protocol technology powers a network of traders and solvers, enabling trustless and efficient peer-to-peer trading. Leveraging batch auctions as a key concept uniquely positions CoW Protocol as native trading infrastructure for discrete-time settlement layers like Ethereum and enables fair and accessible trading to its users. Trades can be settled via underlying on-chain AMMs directly or via DEX Aggregators, depending on which pool/path offers the best price. It is thus essentially acting as a DexAggregator of the DexAggregators. CoW Protocol enables batch auctions to maximize liquidity via Coincidence of Wants (CoWs) in addition to tapping all available on-chain liquidity whenever needed. Batch Auctions are continuously run by the protocol because the solvers, the parties in charge of finding the most optimal settlement for the batch, are in competition to settle it. The winning solver will be the one that can maximize traders surplus by either having the most optimal CoW, finding the best liquidity sources, or combining both in a single settlement.
Overview of projects experimenting with intents
The illustration below provides a non-exhaustive overview of projects exploring intents. However, it’s essential to acknowledge that there might be some overlap between categories, and the presentation is simplified. Canonical examples of intent-specific applications garnering significant attention currently are 1inch Fusion or UniswapX. As the space is still young and rapidly evolving, it’s likely that this illustration could change considerably in just a few months.
Closing words
The current transaction-based approach in Web3 proves to be complex and time-consuming for end users. It involves specifying execution paths across various infrastructures, leading to frustrating user experiences and potential exploitation by more sophisticated actors. Intent-based applications offer a promising shift from an imperative to a declarative paradigm, enhancing user experience and minimizing MEV leakage. While Account Abstraction (AA) and intent-specific apps bring exciting advancements, they have limitations, particularly in a multi-chain world.
Building an intent layer for a fully intent-centric world poses significant challenges as we need to overcome the complexity of current systems and create a user-friendly, efficient, and decentralized infrastructure for expressing and executing intents. Thus, we are are still far far away from this paradigm. However, several projects are working on this endeavor and we expect more to emerge in the future.
As the adoption of intents grows, fueled in part by ERC4337, there is a potential trend of users moving towards alternative mempools. Careful management is crucial to prevent risks of centralization and the rise of rent-seeking intermediaries.
Acknowledgements: This article expands upon the content presented in prior posts, such as Paradigm, MetaWeb.VC, Uma Roy, Alchemy, Archetype, Zaki Manian, Alliance and 20squares.
Many thanks to Lukas Schor, Liesl Eichholz, Diogo Almeida & Mikey for conversations around this topic.
If you have a project experimenting with intents, please reach out!
