Breaking the dilemma of poor user experience How does intent computing change Web3 interaction?

Improving user experience The impact of intent computing on Web3 interaction

Author: Bastian Wetzel; Translation: Deep Tide TechFlow

It has been proven that using various existing systems in Web3 is a complex and time-consuming task. It involves specifying execution paths between different infrastructures, which requires a comprehensive understanding. As a result, users face continuous frustrations and are susceptible to exploitation by more complex participants when trying to achieve their end goals.

This situation arises because the 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 the 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 the creation of transactions 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, an intent defines “what the expected result of that operation is.”

• Bald Runaway How a Low-Level Scam Deceives Everyone
• Semafor US Department of Justice considering fraud charges against Binance
• The Future of Worldcoin

This declarative approach brings exciting progress in user experience and efficiency. Through intents, users can easily express their expected results. This contrasts sharply with 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 the use of 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:

1. Access the dApp website

2. Attempt to connect your wallet to Arbitrum but find no available funds

3. Open a new tab to explore the best way to move your funds across chains

4. Go to the cross-chain bridge

5. Connect your wallet to another blockchain (Ethereum)

6. Transfer funds from Ethereum to Arbitrum

7. Wait for the cross-chain transfer to complete

8. Return to the original tab

9. Switch your wallet back to Arbitrum

10. Now, you can finally use the funds bridged on Arbitrum with the dApp.

Even before users have the opportunity to interact with the dApp itself, they already feel frustrated. These issues become even more apparent in a future world of millions of Rollups.

So, how do we transition from an imperative paradigm to a declarative paradigm? To understand the basic principles, let me first briefly summarize the concept of Account Abstraction (AA).

Brief Review of Account Abstraction

In Ethereum, there are two types of addresses: smart contracts and externally owned accounts (EOA).

EOA (Externally Owned Account) has the ability to initiate transactions, while smart contracts cannot. Therefore, most Ethereum wallets used today are EOAs. Although there are smart contract wallets (SCWs) such as Safe, they require EOAs to trigger any transactions, as smart contracts themselves cannot initiate transactions. Nevertheless, SCWs have significant advantages as they can execute complex logic and provide various new applications for wallets, while EOAs are limited to signing.

To meet the demand for SCWs without the need for a separate EOA, ERC-4337 introduces a new type of transaction called User Operation (UserOp) and introduces a new role called “Bundlers”. In addition, ERC-1271 (a standard signature verification method for contracts) introduces a standard method to verify the validity of a given contract’s signature. These updates improve the user experience of SCWs and provide users with smoother processes. 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 a secondary 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 performs ValidateOp, which involves checking the appropriate signers, access control, and rate limits to ensure that the operation is legal and secure. Upon successful validation, the SCW proceeds to execute the operation using the ExecuteOp function. These operations may include transferring funds, executing exchanges, or purchasing NFTs.

One key advantage of account abstraction is Gas abstraction, which simplifies the process of gas payment for users. This is where the payer comes into play. The payer contract acts as another entity. When a user sends a transaction, the UserOp is sent to the payer contract. The payer contract 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, acting as a refund mechanism. Only after this gas payment is processed does the UserOp go through the ValidateOp and ExecuteOp stages.

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 more user-friendly.

One limitation of AA (Account Abstraction) is that it does not support cross-chain payers. Let’s consider a scenario where a user has USDC on an SCW on the Ethereum network but wants to use a payer to pay for transactions on the Arbitrum network. Issues arise when the payer contract attempts to transfer USDC from the user 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 ability to seamlessly operate across multiple chains.

Applications specific to Intents

The account abstraction is typically simplified as “gasless transactions”, “mnemonic recovery-free”, and potential “rate limiting”. Yes, these features are indeed interesting, but not cool enough. They may not fully capture the essence of what is truly fascinating about AA. The most fascinating aspect of account abstraction lies in its architecture, which transforms wallets into gateways of intent.

So, what is intent?

In a standard transaction process, when validators receive a transaction signature, they follow specific computation paths based on specific states. Additionally, fees serve as incentives to encourage validators to operate in this way. However, the situation is different when using intent. Intent does not prescribe a fixed computation path but allows any path that fulfills specific conditions. When users sign and share their intent, they authorize the recipient to choose the computation path on their behalf. This distinction makes intent more precisely defined as a signed message, facilitating a series of state transitions starting from a given initial point.

It is worth noting that a single transaction can contain multiple intents, achieving the matching of overlapping intents. This significantly improves gas and economic efficiency. For example, in an order book maintained by builders, two orders can be efficiently offset against each other before reaching the market. Additionally, intent allows for more flexible user gas payments, such as allowing third-party gas sponsorship or accepting payment in different tokens.

Therefore, UserOps are not intent as they are essentially Txs. However, AA makes wallets a gateway of intent, which is achieved through the validation logic within smart contract wallets. This validation logic allows for the expression and execution of simple intents related to user accounts. However, SCWs lack the ability to reason about global state.

Account abstraction fundamentally serves “specific intents”. In this case, users can specify and implement simplified intents through their SCWs, as long as these intents meet 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 AA, as emphasized by the LianGuairadigm:

• 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 in USDC instead of ETH and allocate USDC in their accounts to cover the gas fees of the sender.

• Delegation: Interactions with specific accounts can be restricted in a pre-authorized manner. For example, ETH can specify to be used for purchasing NFTs listed on OpenSea, or a specific address can restrict interactions only to Uniswap and Sushiswap.

• Transaction batching: Users can allow multiple intents to be batched into a single transaction to improve gas efficiency.

• Aggregator: Users can specify operations to be performed with the “best” price or yield. This intent can be achieved by providing proof that aggregates and selects the best path across multiple venues.

Although AA and intent-specific 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 as much as possible by leveraging liquidity on different Rollups. With AA, I can easily and quickly use my favorite 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.

Generic Solution

In an intent-centric world, users declare or sign their preferences, and the network relies on third-party participants (solvers/ executors) to execute these preferences on their behalf.

It is important to note 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 the best outcome. Therefore, the innovation of intent is not about outsourcing transaction creation to a third party, but adding a dedicated third-party network that can provide better results.

This can improve execution efficiency as these solvers can integrate more information about the status of other chains without needing to communicate with users.

To illustrate this, let’s revisit the scenario where I own ETH and my goal is to buy as many XYZ tokens as possible by leveraging liquidity between different Rollups. In an intent-centric world, I can inform the mempool that I own ETH and want to get the maximum possible amount of XYZ tokens. A highly complex solver will efficiently find a solution. The incentives for these solvers should lead to fairly optimized results. 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, intent-specific applications lack scalability in such a multi-chain environment. However, for intent, a flexible and generic 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 provide services to users, with some specifically dedicated to certain categories of Rollups and others for different domains. This approach demonstrates the practicality and capability of cross-chain intent, going beyond ordinary account abstractions, even for simple use cases.

The ideal infrastructure for expressing, communicating, and executing intent 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-grained user intent and user experience, as this decision has a significant impact on the architecture of the intent protocol. Furthermore, there are many unanswered questions, such as how to prove what is optimal, where cross-domain intents will be published, and how solvers will determine what to search for.

Examples of General Solutions

While this vision is promising, the first step is to establish an intent layer where users can express their intentions and solvers can compete to fulfill those intentions. Projects like Anoma, SUAVE, Essential, and CoW Protocol are all vying to become the intent layer of the blockchain, each adopting different approaches.

However, as the concept of the intent layer is still evolving and many design principles seem to contradict each other, it is still too early to make comparisons. Building such a layer faces significant challenges.

Anoma is a unified architecture for full-stack decentralized applications. It is designed from scratch for applications involving unlimited users issuing an unlimited number of intents, each with varying complexities. Anoma follows the principles of intent-centricity and homogenous architecture/heterogeneous security, together forming a declarative paradigm for building decentralized applications. Intents are submitted to intent propagation nodes, which form intent pools. Matchers analyze these pools to find intents that can be combined and mutually satisfied when combined. The protocol’s state machine achieves progressive execution and decoupled validation through effective predicates as invariants on user accounts. Anoma makes it easy to build novel applications that may be cumbersome, limited, or impossible to build 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. SUAVE decouples the roles of mempool and block builders from existing blockchains and provides a highly specialized and decentralized plug-and-play alternative. The shared ordering layer keeps cryptocurrencies decentralized, allowing block builders to capture cross-domain MEV, validators to maximize income, and users to perform optimal execution trades while reducing economic concentration pressure on each domain. SUAVE is an integrated environment that facilitates decentralized collaboration in expressing, executing, and settling preferences. The core concept is preference, where user-signed messages are used to express goals and enable simple transfers or complex sequence functionality across multiple blockchains. Solvers compete to provide optimal execution, including capturing MEV and providing decentralized order flow value.

Essential is developing a range of products to drive the transformation of the blockchain ecosystem from value extraction to intent fulfillment. They are creating a domain-specific language (DSL) for expressing intent, an intent-oriented account abstraction Ethereum standard, 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-oriented account abstraction standard empowers solvers to build efficient transactions based on user intent, introducing intent functionality into existing EVM chains. The modular intent layer ensures the possibility of 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 incorporating batch auctions as a key concept, providing users with fair and accessible transactions. Transactions can be settled directly through the underlying on-chain AMM or through a DEX aggregator, 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 utilize 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 solve them.

Intent Experiment Project Overview

The following illustration provides a non-exhaustive overview of an intent experiment project. 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. Since this field is still young and rapidly evolving, this illustration may undergo significant changes in just a few months.

Conclusion

For end users, the current transaction-based methods in Web3 have proven to be complex and time-consuming. They involve specifying execution paths between various infrastructures, resulting in a frustrating user experience 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 intent-specific applications bring exciting progress, they also have limitations, especially in a multi-chain world.

Building an intent layer for a fully intent-centric world faces significant challenges as we need to overcome the complexity of the current system and create a user-friendly, efficient, and decentralized infrastructure to express and execute intent. Thus, we still have a long way to go for this paradigm. However, several projects are dedicated to this effort, and we expect more projects to emerge in the future.

As intent adoption continues to grow (driven by ERC4337), users may turn to alternative mempools. Prudent management is crucial to prevent centralization risks and the rise of rent-seeking intermediaries.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!