Deep dive into how "intent computing" is changing Web3 interactions?
Original author: Bastian Wetzel
Original translation: Shenchao TechFlow
It turns out that using the current various systems in Web3 is a complex and time-consuming task. It involves specifying the execution path between different infrastructures, which requires a comprehensive understanding. Therefore, users face continuous frustrations and are susceptible to exploitation by more complex participants when trying to achieve their end goals.
This situation arises because mainstream standard methods for users to interact with Ethereum require creating and signing transactions in a specific format that provides all the necessary information for Ethereum Virtual Machine (EVM) to execute state transitions.
The introduction of Intents aims to alleviate the burden on users. Essentially, an Intent is a set of declarative constraints that allow users to delegate transaction creation to specialized third-party participant networks while retaining full control over the process. In simple terms, if a transaction specifies "how" to perform an operation, then the Intent defines "what the expected result of that operation is".
This declarative approach brings exciting advances in user experience and efficiency. With Intents, users can easily express their expected results. This stands in stark contrast to the current imperative transactions where each parameter must be explicitly specified by the user.
Tx (transaction) is a dead end for end users
The current transaction-based methods in Web3 have proven to be complex, resulting in poor user experience and efficiency loss as users are forced to make decisions without sufficient access to information or using complex execution strategies.
To illustrate this complexity, consider the following scenario: you want 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 find no funds available
Open a new tab to explore the best way to transfer your funds across chains
Go to the cross-chain bridge
Connect your wallet to another blockchain (Ethereum)
Transfer funds from Ethereum to Arbitrum
Wait for the cross-chain transfer to complete
Return to the original tab
Switch your wallet back to Arbitrum
Now, you can finally use the funds bridged on Arbitrum to use the dApp.
Even before users have a chance to interact with the dApp itself, they feel frustrated. These issues become even more apparent in a future world with millions of Rollups.
So, how do we transition from an imperative paradigm to a declarative one? To understand the basic principles, let me first provide a brief summary of the Account Abstraction (AA) concept.
A Brief Overview of Account Abstraction
In Ethereum, there are two types of addresses: smart contracts and externally owned accounts (EOA).
EOA has the capability to initiate transactions, while smart contracts cannot. Therefore, most Ethereum wallets used today are EOAs. Although there are smart contract wallets (SCW) like Safe, they require an EOA to trigger any transactions as smart contracts themselves cannot initiate transactions. Nevertheless, SCWs have significant advantages as they can execute complex logic, providing various new applications for wallets, while EOAs are limited to signing.
To fulfill the demand for SCWs without requiring a separate EOA, ERC-4337 introduced a new transaction type called User Operation (UserOp) and introduced a new role called "Bundlers." Additionally, ERC-1271 (a standard signature verification method for contracts) introduced a standard way to verify the signature of a given contract. These updates improve the user experience of SCWs, offering a smoother process for users. The specific process is as follows:
The user signs a UserOp, specifying the desired operation. The UserOp is not directly sent to the main memory pool but is sent by multiple users to an alternative memory pool. Here, the executors and Bundlers come into play, bundling these UserOps together and submitting them as a bundle to the entry contract. Then, the entry contract communicates with the smart contract wallet.
Once the bundled UserOp is received by the SCW, it undergoes a two-step process. First, it goes through ValidateOp, which involves checking the appropriate signers, access control, and rate limitations to ensure that the operation is legitimate and secure. Once validation is successful, the SCW proceeds to execute the operation using the ExecuteOp function. These operations may include fund transfers, executing exchanges, or purchasing NFTs, among other tasks.
The key advantage of account abstraction is Gas abstraction, which simplifies the user's Gas payment process. This is the role of the payer. The payer contract acts as another entity. When a user sends a transaction, the UserOp is sent to the payer contract. The payer verifies and ensures that it will pay for the Gas cost of the transaction. It refunds the corresponding amount of native Gas tokens to the Bundlers, serving as a refund mechanism. Only after this Gas payment is processed, the UserOp goes through the ValidateOp and ExecuteOp phases.
The payer also allows users to perform additional operations after executing the UserOp, providing further flexibility and control. By leveraging the payer and Gas abstraction, users can transact without worrying about managing Gas costs directly, making the process smoother and user-friendly.
One limitation of AA is that it does not support cross-chain payers. Let's consider a scenario where a user has USDC on the SCW on the Ethereum network but wants to use the payer to pay for transaction fees on the Arbitrum network. There would be an issue when the payer attempts to transfer USDC from the user to the payer during the post-operation function. USDC is stored on Ethereum while the payer contract is on Arbitrum. Essentially, account abstraction is primarily designed for single-domain use and lacks the inherent capability to seamlessly operate across multiple chains.
Applications specific to Intents
Account abstraction is often simplified as "gasless transactions," "mnemonic recovery-free," and potentially "rate limiting." Yes, these features are indeed interesting, but they don't capture the truly remarkable essence of AA. The most remarkable aspect of account abstraction lies in its architecture, which transforms wallets into entry points for intents.
So, what is an intent?
In a standard transaction process, when validators receive a transaction signature, they follow a specific computational path based on specific states. Additionally, fees serve as incentives for validators to operate in this manner. However, the situation is different when using intents. Intents do not dictate a fixed computation path but allow for any path that satisfies specific conditions. When users sign and share an intent, they authorize the receiver to choose a computational path on their behalf. This distinction makes intents more precisely defined as signed messages, facilitating a series of state transitions starting from a given initial point.
It is worth noting that a single transaction can contain multiple intents, enabling the matching of overlapping intents. This significantly improves Gas and economic efficiency. For example, in an order book maintained by a builder, two orders can be efficiently offset against each other before reaching the market. Additionally, intents allow for more flexible user Gas payment, such as allowing third-party gas sponsorship or accepting payment in different tokens.
Therefore, UserOps are not intents because they are essentially Tx. However, AA makes wallets the entry point for intents, which is achieved through the validation logic within the smart contract wallet. This validation logic allows for the expression and execution of simple intents related to user accounts. However, SCW lacks the ability to reason about the global state.
Account abstraction is fundamentally serving "specific intents". In this case, users can specify and implement simplified intents through their SCWs, as long as these intents satisfy certain restrictive requirements:
They focus on a single domain;
They only use and execute information related to user accounts;
They involve Gas compensation.
Examples of intent-specific applications
Therefore, account abstraction primarily caters to user-centric goals. However, there are many examples of "intent-specific" applications that can be implemented using AAs, as emphasized by Paradigm:
Limit orders: Users can specify that they can only withdraw 100 X tokens from their account if they receive at least 200 Y tokens.
Gas sponsorship: Users can choose to pay transaction fees using USDC instead of ETH and allocate USDC in their account to cover the gas fees of the payer.
Delegation: Interactions with specific accounts can be restricted in a pre-authorized manner. For example, ETH can be specified to be used for purchasing NFTs listed on OpenSea, or a specific address can limit interactions only with Uniswap and Sushiswap.
Batch transactions: Users can allow multiple intents to be batched into a single transaction to improve gas efficiency.
Aggregators: Users can specify performing specific operations using the "best" price or yield. This intent can be achieved by providing proof of aggregating and selecting the best path to execute across multiple venues.
Although AA and specific intent applications are significant advancements, they also have limitations in a multi-chain environment. Let's consider a scenario: I own ETH and want to buy token XYZ using the liquidity across different Rollups as much as possible. With AA, I can easily and quickly use my preferred DEX aggregator on any Rollup. However, the challenge is that I still need to manually discover the best DEX aggregator available on all Rollups.
Therefore, in a multi-chain world, there is a need for a comprehensive and flexible intent language that can effectively enhance scalability.
General Solution
In an intent-centric world, users declare or sign their preferences, and the network relies on third-party participants (solvers/ executors) to execute those preferences on their behalf.
It is important to emphasize that the current transaction-based approach also allows users to outsource transactions, but the difference lies in who the third party is. Currently, applications build transactions on behalf of users, and they do not optimize for obtaining the best results. Therefore, the innovation of intent is not about outsourcing transaction creation to a third party, but rather adding a dedicated third-party network that can provide better outcomes.
This can improve execution efficiency as these solvers can integrate more information about the state of other chains without the need to communicate with users.
To illustrate this point, let's revisit the scenario where I own ETH and the goal is to buy as much XYZ coin as possible by leveraging the liquidity between different Rollups. In an intent-centric world, I can inform the mempool that I own ETH and want to acquire the maximum possible amount of XYZ coin. A highly sophisticated solver will efficiently find a solution. The incentives for these solvers should result in fairly optimized outcomes. In this multi-chain environment, even basic tasks become impractical, such as a single company running a DEX aggregator to integrate with all new Rollups and domains. Therefore, specific intent applications lack scalability in such a multi-chain environment. However, for intents, a flexible and general-purpose language can effectively scale as it operates as a permissionless system. There is no need for a single company to act as a full-chain DEX aggregator covering every chain. Instead, a set of solvers can compete to serve users, with some specifically dedicated to certain Rollup categories and others for different domains. This approach demonstrates the practicality and capability of cross-chain intents, going beyond ordinary account abstractions, even benefiting simple use cases.
The ideal infrastructure for expressing, communicating, and executing intentions should minimize miner-extractable value (MEV), maximize censorship resistance, and optimize for cross-domain interactions. Additionally, it should carefully consider the balance between conveying fine user intentions and user experience, as this decision has significant implications for the architecture of the intent protocol. There are also many unanswered questions, such as how to prove what is optimal, where cross-domain intentions will be published, and how solvers will determine what to search for.
Examples of General Solutions
While this vision shows promise, the first step is to establish an intent layer where users can express their intentions and solvers can compete to fulfill these intentions. Projects like Anoma, SUAVE, Essential, and CoW Protocol are all vying to become the intent layer for blockchain, each adopting different approaches.
However, due to the evolving nature of the intent layer concept and many seemingly conflicting design principles, it is still premature to make comparisons. Building such a layer faces significant challenges.
Anoma is a unified architecture for full-stack decentralized applications. It is designed from the ground up for applications involving an infinite number of users issuing an infinite number of intents, with varying complexities for each intent. Anoma follows the principles of intent-centricity and homomorphic architecture/heterogeneous security, collectively forming a declarative paradigm for building decentralized applications. Intents are submitted to intent propagation nodes, which form intent pools. Matchmakers analyze these pools to find compatible intents that can fulfill each other when combined. The protocol's state machine achieves progressive execution and decoupled validation through effective predicates as invariants on user accounts. Anoma simplifies the construction of novel applications that may be cumbersome, limited, or impossible on existing Ethereum (EVM) and Ethereum-like protocols.
SUAVE is a unified auction protocol for value expression. SUAVE aims to empower users and achieve maximum decentralization of public blockchains. It decouples the roles of the memory pool and block construction from existing blockchains and provides a highly specialized and decentralized plug-and-play alternative. Sharing the same ordering layer keeps cryptocurrencies decentralized, allowing block builders to capture cross-domain MEV, validators to maximize income, and users to perform optimal transaction execution while reducing economic centralization pressures in each domain. SUAVE is an integrated environment that facilitates decentralized collaboration in expressing, executing, and settling preferences. The core concept is preferences, where user-signed messages are used to express goals and enable simple transfers or complex sequences across multiple blockchains. Solvers compete to provide optimal execution, including capturing MEV and delivering decentralized order flow value.
Essential is developing a series of products to facilitate the transformation of blockchain ecosystems from value extraction to intent fulfillment. They are creating a Domain-Specific Language (DSL) for expressing intent, an Ethereum standard for intent-based account abstractions, and a modular intent layer. The DSL allows for standardized intent expression and optimized solving, enhancing the composability and development of intent-based applications. The intent-based account abstraction standard empowers solvers to construct efficient transactions based on user intent, bringing intent functionality to existing EVM chains. The modular intent layer ensures an architecture focused solely on intent, aggregated order flow, MEV resistance, and cross-chain intent execution. Essential's mission is to empower users, eliminate exploitation, and promote a user-centric and fair blockchain future.
The CoW Protocol technology builds a network for traders and solvers, enabling trustless and efficient peer-to-peer transactions. CoW Protocol positions itself uniquely as the native transaction infrastructure for discrete-time settlement layers (such as Ethereum) by treating batch auctions as a fundamental concept, providing users with fair and accessible transactions. Transactions can settle directly through on-chain AMMs or through DEX aggregators, depending on which pool/path offers the best price. Thus, it is essentially a Dex Aggregator of Dex Aggregators. CoW Protocol achieves batch auctions through Coincidence of Wants (CoWs) to maximize liquidity and leverage all available on-chain liquidity when needed. The protocol continuously runs batch auctions as solvers, the parties responsible for finding optimal batch settlements, compete to resolve them.
Intent Experiment Overview
The following illustration provides a non-exhaustive overview of intent experiment projects. However, it should be acknowledged that there may be some overlap between different categories, and this presentation is simplified. Typical examples of intent-specific applications that have garnered significant attention are 1inch Fusion or UniswapX. Given that this field is still young and rapidly evolving, this illustration may undergo substantial changes in just a few months.
Conclusion
For the end-users, the current Tx-based approach in Web3 has proven to be complex and time-consuming. It involves specifying execution paths among various infrastructures, leading to frustrating user experiences and potential exploitation by more sophisticated participants. Intent-based applications offer a promising shift from imperative to declarative paradigms, enhancing user experience and minimizing MEV. While Account Abstraction (AA) and specific intent applications bring exciting progress, they also come with certain limitations, especially in a multi-chain world.
Building an intent-centric world poses significant challenges as we need to overcome the complexity of the current systems and create a user-friendly, efficient, and decentralized infrastructure to express and execute intents. Therefore, we still have a long way to go towards this paradigm. However, there are several projects dedicated to this effort, and we expect to see more emerging in the future.
With the growing adoption of intent (driven by ERC 4337), users may turn to alternative memory pools. Prudent management is crucial to prevent centralized risks and the rise of rent-seeking intermediaries.
