Breaking the Deadlock of Poor User Experience: How "Intent-Centric Computing" Transforms Web3 Interactions?
TechFlow Selected TechFlow Selected
Breaking the Deadlock of Poor User Experience: How "Intent-Centric Computing" Transforms Web3 Interactions?
Through intents, users can easily express their desired outcomes, in stark contrast to the current imperative transactions.
Navigating Web3 tides with focused insightsAuthor: Bastian Wetzel
Compiled by: TechFlow
It turns out that using current systems in Web3 is complex and time-consuming. It involves specifying execution paths across different infrastructures, which requires comprehensive understanding. As a result, users face ongoing frustration in achieving their end goals and are vulnerable to exploitation by more sophisticated participants.
This situation arises because the mainstream method for users to interact with Ethereum requires creating and signing transactions in a specific format that contains all necessary information for the Ethereum Virtual Machine (EVM) to execute state transitions.
The introduction of intents aims to alleviate this burden on users. At its core, an intent is a set of declarative constraints that allows users to delegate transaction creation to a specialized network of third-party actors while retaining full control over the process. Put simply, if a transaction specifies "how" to perform an operation, an intent defines the "desired outcome" of that operation.
This declarative approach brings exciting improvements in user experience and efficiency. With intents, users can easily express their desired outcomes—contrasting sharply with today’s imperative transactions, where every parameter must be explicitly specified by the user.
Transactions (Tx) Are a Dead End for End Users
The current transaction-based approach in Web3 has proven to be complicated, leading to poor user experiences and inefficiencies, as users are forced to make decisions without sufficient access to information or the ability to use 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 held on the Ethereum blockchain:
-
Access the dApp website
-
Attempt to connect your wallet to Arbitrum, only to find no available funds
-
Open a new tab to explore the best way to move your funds cross-chain
-
Navigate to a 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
-
Finally, you can now use the dApp on Arbitrum with your bridged funds.
Users are already frustrated before they even get a chance to interact with the dApp itself. These issues become even more pronounced in a future world of millions of Rollups.
So, how do we transition from imperative to declarative paradigms? To understand the foundation, let me first briefly summarize the concept of Account Abstraction (AA).
A Brief Recap of Account Abstraction
In Ethereum, there are two types of addresses: smart contracts and externally owned accounts (EOAs).
EOAs have the ability to initiate transactions; smart contracts do not. Therefore, most Ethereum wallets used today are EOAs. While smart contract wallets (SCWs), such as Safe, exist, they still require an EOA to trigger any transaction since smart contracts themselves cannot initiate transactions. Nevertheless, SCWs offer significant advantages because they can execute complex logic, enabling new wallet functionalities beyond simple signing, which is all EOAs are limited to.
To meet the demand for SCWs without requiring a separate EOA, ERC-4337 introduced a new type of transaction called a UserOperation (UserOp), along with a new role called "Bundlers." Additionally, ERC-1271 (a standard signature verification method for contracts) introduced a standardized way to verify whether a given contract's signature is valid. These updates improved the user experience for SCWs, offering a smoother flow. The process works as follows:
-
The user signs a UserOp specifying the desired action. Instead of being sent 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 a bundle to an entry contract, which then communicates with the smart contract wallet.
-
Once the SCW receives the bundled UserOp, it undergoes a two-step process. First, it executes ValidateOp, which checks for proper signers, access controls, and rate limits to ensure the operation is legitimate and secure. Upon successful validation, the SCW proceeds with the ExecuteOp function to carry out the operation. These operations may include transferring funds, executing swaps, or purchasing NFTs.
A key advantage of account abstraction is gas abstraction, which simplifies the process of paying for gas. This is where the Paymaster comes in. A Paymaster contract acts as another entity. When a user sends a transaction, the UserOp is directed to the Paymaster contract. The Paymaster verifies and ensures it will cover the gas cost of the transaction. It refunds the appropriate amount of native gas tokens to the Bundlers, serving as a reimbursement mechanism. Only after this gas payment is processed does the UserOp proceed to the ValidateOp and ExecuteOp stages.
Paymasters also allow users to perform additional actions after executing a UserOp, providing further flexibility and control. By leveraging Paymasters and gas abstraction, users can transact without worrying about directly managing gas costs, making the process smoother and more user-friendly.
One limitation of AA is that it does not support cross-chain paymasters. Consider this scenario: a user holds USDC on their SCW on Ethereum but wants to use a Paymaster to cover transaction fees on Arbitrum. A problem arises when the Paymaster attempts to transfer USDC from the user during the post-operation phase—the USDC is stored on Ethereum, while the Paymaster contract resides on Arbitrum. Essentially, account abstraction is primarily designed for single-domain use and lacks inherent capability to operate seamlessly across multiple chains.
Intent-Specific Applications
Account abstraction is often reduced to "gasless transactions," "recovery without seed phrases," and possibly "rate limiting." Yes, these features are indeed interesting—but not cool enough. They may fail to fully capture the truly compelling essence of AA. The most compelling aspect of account abstraction lies in its architecture, which transforms wallets into gateways for intents.
So, What Is an Intent?
In a standard transaction process, when validators receive a signed transaction, they follow a specific computational path based on a particular state. Additionally, fees serve as incentives for validators to act accordingly. However, with intents, the situation differs. Intents do not prescribe a fixed computational path but instead allow any path that satisfies certain conditions. When a user signs and shares an intent, they authorize the recipient to choose the computational path on their behalf. This distinction makes intents more precisely defined as signed messages that facilitate a series of state transitions from a given starting point.
Notably, a single transaction can contain multiple intents, enabling efficient matching of overlapping intents. This significantly improves gas and economic efficiency. For example, within an order book maintained by builders, two orders can be efficiently offset against each other before reaching the market. Moreover, intents allow for more flexible user gas payments, such as allowing third parties to sponsor gas or accepting payments in different tokens.
Therefore, UserOps are not intents, as they are essentially transactions (Tx). However, AA enables wallets to become entry points for intents—achieved through validation logic inside smart contract wallets. This validation logic allows expression and execution of simple intents related to the user’s account. Yet, SCWs lack the ability to reason about global state.
At its core, account abstraction serves “intent-specific” purposes. In this context, users can specify and implement simplified intents via their SCW, provided these intents meet certain restrictive criteria:
-
They focus on a single domain;
-
They only use and execute information related to the user’s account;
-
They involve gas compensation.
Examples of Intent-Specific Applications
Thus, account abstraction primarily caters to user-centric goals. However, there are numerous examples of “intent-specific” applications that can be realized using AA, as highlighted by Paradigm:
-
Limit Orders: Users can specify that 100 units of token X should only be withdrawn from their account if they receive at least 200 units of token Y.
-
Gas Sponsorship: Users can opt to pay transaction fees in USDC instead of ETH, allocating USDC in their account to cover the Paymaster’s gas costs.
-
Delegation: Interactions with specific accounts can be pre-authorized under certain constraints. For instance, ETH could be designated solely for purchasing NFTs listed on OpenSea, or a specific address could be restricted to interacting only with Uniswap and Sushiswap.
-
Transaction Batching: Users can allow multiple intents to be batched into a single transaction for improved gas efficiency.
-
Aggregators: Users can specify performing an action at the “best” price or yield. This intent can be fulfilled by providing proof of aggregation across multiple venues and selecting the optimal path.
While AA and intent-specific applications represent major advancements, they also have limitations in multi-chain environments. Consider this scenario: I own ETH and aim to buy as much of token XYZ as possible by leveraging liquidity across different Rollups. Using AA, I can quickly and easily use 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.
Therefore, in a multi-chain world, there is a need for a comprehensive and flexible intent language capable of effectively scaling.
General Solutions
In an intent-centric world, users declare or sign their preferences, and the network relies on third-party participants (solvers/executioners) to execute these on their behalf.
It must be emphasized 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, but they are not necessarily optimized for achieving the best outcomes. Thus, the innovation of intents does not lie in outsourcing transaction creation per se, but in introducing a dedicated network of third parties capable of delivering better results.
This can improve execution efficiency, as solvers can integrate more information about the state of other chains without needing to communicate with the user.
To illustrate, revisit the scenario where I hold ETH and aim to purchase as much XYZ coin as possible by leveraging liquidity across different Rollups. In an intent-centric world, I could inform the mempool that I have ETH and wish to obtain the maximum possible amount of XYZ coin. A highly sophisticated solver would efficiently find a solution. Incentives for these solvers should lead to highly optimized outcomes. In such a multi-chain environment, even basic tasks become impractical—for example, a single company running a DEX aggregator trying to integrate with every new Rollup and domain. Hence, in such environments, intent-specific applications lack scalability. However, for intents, a flexible and general-purpose language can scale effectively because it operates as a permissionless system. There’s no need for one company to act as an omnichain DEX aggregator covering every chain. Instead, a set of solvers can compete to serve users—some specializing in specific categories of Rollups, others in different domains. This approach shows that cross-chain intents possess significant practicality and capability, surpassing ordinary account abstraction—even beneficial for simple use cases.
The ideal infrastructure for expressing, communicating, and executing intents should minimize miner extractable value (MEV), maximize censorship resistance, and optimize for cross-domain interactions. Furthermore, it should carefully balance precise user intent communication with user experience, as this decision significantly impacts the architecture of intent protocols. Additionally, many unanswered questions remain—such as how to prove what constitutes optimal execution, 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 establishing an intent layer where users can express their intents and solvers can compete to fulfill them. Projects like Anoma, SUAVE, Essential, and CoW Protocol are all vying to become the intent layer for blockchains, employing different approaches.
However, since the concept of an intent layer is still evolving and many design principles appear contradictory, it is too early to draw comparisons. Building such a layer faces significant challenges.
Anoma is a unified architecture for full-stack decentralized applications. It is built from the ground up for applications involving infinite users issuing an infinite number of intents, each varying in complexity. Anoma follows intent-centric and homogeneous-architecture/heterogeneous-security principles, collectively forming a declarative paradigm for building decentralized applications. Intents are submitted to intent propagation nodes, forming an intent pool. Matchers analyze these pools to find intents that can be combined and mutually satisfied. The protocol’s state machine enables stepwise execution and decoupled validation through validity predicates implemented as invariants on user accounts. Anoma makes it easy to build novel applications that would otherwise be clunky, limited, or impossible on existing Ethereum (EVM) and Ethereum-like protocols.
SUAVE is the Unified Auction for Value Expression. SUAVE aims to empower users and achieve maximum decentralization across public blockchains. SUAVE decouples the mempool and block-building roles from existing blockchains and offers a highly specialized, decentralized plug-and-play alternative. A shared ordering layer keeps cryptocurrencies decentralized, allows block builders to capture cross-domain MEV, enables validators to maximize revenue, and lets users execute optimally while reducing economic centralization pressure on individual domains. SUAVE is an integrated environment facilitating decentralized collaboration in expressing, executing, and settling preferences. Its core concept is the preference—a signed message by users expressing goals, enabling simple transfers or complex sequences across multiple blockchains. Solvers compete to provide the best execution, including capturing MEV and delivering decentralized order flow value.
Essential is developing a suite of products driving a shift in the blockchain ecosystem from value extraction to intent fulfillment. They are creating a domain-specific language (DSL) for expressing intents, an intent-oriented account abstraction standard for Ethereum, and a modular intent layer. The DSL enables standardized intent expression and optimized solving, enhancing composability and developer experience for intent-based applications. The intent-oriented 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 pure-intent architecture, 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.
CoW Protocol builds a network for traders and solvers, enabling trustless and efficient peer-to-peer trading. CoW Protocol uniquely positions itself as a native transaction infrastructure for discrete-time settlement layers (like Ethereum) by adopting batch auctions as a core concept, offering users fair and accessible trading. Trades can be settled directly via underlying on-chain AMMs or through DEX aggregators, depending on which pool/path offers the best price. Thus, it is essentially a DEX aggregator for DEX aggregators. CoW Protocol achieves batch auctions through Coincidence of Wants (CoWs) to maximize liquidity and leverages all available on-chain liquidity when needed. The protocol continuously runs batch auctions as solvers—parties responsible for finding optimal batch settlements—compete to solve them.
Overview of Intent Experiment Projects
The illustration below provides a non-exhaustive overview of intent experiment projects. However, it must be acknowledged that some overlap may exist between categories, and this representation is simplified. Notable examples of intent-specific applications currently attracting significant attention include 1inch Fusion and UniswapX. Given that this field is young and rapidly evolving, this landscape could change dramatically within just a few months.
Conclusion
For end users, the current transaction-based approach in Web3 has proven to be complex and time-consuming. It involves specifying execution paths across various infrastructures, resulting in frustrating user experiences and vulnerability to 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 come with limitations—especially in a multi-chain world.
Building an intent layer for a fully intent-centric world poses significant challenges, as we must overcome the complexity of current systems and create a user-friendly, efficient, and decentralized infrastructure for expressing and executing intents. Therefore, we still have a long way to go before realizing this paradigm. However, several projects are actively working toward this goal, and we expect many more to emerge in the future.
As intent adoption grows—driven by ERC-4337—users may increasingly shift toward alternative mempools. Careful governance will be crucial to prevent centralization risks and the rise of rent-seeking intermediaries.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@bastian_wetzel
