In recent times, there have been discussions in the Ethereum community about Intent and its applications. Transaction refers to how a particular action is performed, while Intent refers to the desired outcome of that action or something else. This article aims to provide a brief introduction to the principles of Intent, its current applications, potential risks, and mitigation methods.
If the instruction for a Transaction is:
"Perform operation A, then perform operation B, then make payment to C to obtain D."
The corresponding Intent would be:
"I have the ability to make the payment and I want to obtain D."
A protocol centered around Intent can significantly improve user experience and efficiency. Transactions require users to specify each parameter themselves, which can be cumbersome. In contrast, using Intent, users can simply express their desired outcome and outsource the task of achieving the best implementation result to a reputable third party.
While Intent offers more possibilities for the ecosystem, Ethereum's on-chain design based on Intent may also have significant implications for off-chain infrastructure. There is an important connection with activities and market controls related to MEV (Miner Extractable Value).
How Intent Works
Currently, the standard method for users to interact with Ethereum is to create and sign transactions and specific formats of information that provide all the necessary information for EVM (Ethereum Virtual Machine) to execute state transitions. However, creating a transaction can involve quite complex operations. Creating a transaction requires knowledge about smart contracts, details such as nonce management, and holding specific assets to pay for gas fees. The complexity results in poor user experience and reduced efficiency as users need to make decisions in situations where they lack sufficient information or involve complex execution strategies.
The goal of Intent is to alleviate the burden on users. Intent allows users to outsource transaction creation to third parties by signing a set of descriptive constraints, without giving away complete control.
In the process of standard transaction-based flows, when validators are incentivized to validate, transaction signatures allow validators to accurately follow the computational paths for specific states. In contrast, Intent does not specify the exact computational paths that must be taken, but instead allows for any operation that satisfies specific constraint conditions. By signing and sharing Intents, users effectively grant recipients the authority to choose the computational paths on their behalf (as shown in the diagram below). It is worth noting that a single transaction can include multiple Intents, enabling matching overlapping Intents, saving gas fees, and improving economic efficiency. Furthermore, users can also pay gas fees more flexibly, such as allowing third parties to sponsor gas or make payments with other tokens.
As shown in the diagram, when submitting a transaction, the user specifies the exact computational path; when submitting an Intent, the user specifies the target and some constraint conditions, and it is determined by Matchmaking which computational path to take.
Current Applications of Intent
Creating Intents allows for the outsourcing of complex matters related to blockchain interactions, while allowing users to retain custody of their assets and cryptographic identities. In fact, many concepts regarding Intent correspond to systems that have been operating for several years, such as the following scenarios:
Restrictive orders: If a user receives at least 200 B tokens, they can withdraw 100 A tokens from their account.
Cowswap-style auctions: Similar to restrictive orders, but relying on third parties or mechanisms to match multiple orders for maximum execution quality.
Gas sponsorship: Users can choose to pay transaction fees in USDC instead of ETH, provided that there is USDC in their account to cover the gas fees.
Delegated authorization: Only allowing interaction with specific accounts in certain pre-authorized ways. Intent can only be achieved when the final transaction follows the access control list specified in the Intent.
Merging transaction processing: Allows for the merging processing of multiple Intents to improve gas efficiency.
Aggregators: Operating only with the best price/yield, by aggregating and taking the optimal path to execute multiple scenarios as proof of Intent.
Currently, Intent has new applications in cross-chain MEV (such as SUAVE), ERC 4337 account abstraction, and Seaport order scenarios. While ERC 4337 is developing, other new applications (such as cross-domain Intent) are also entering the exploration stage.
In all Intent-based applications, there needs to be at least one group that understands Intent and is incentivized to execute it promptly. As for who plays this role, how it is executed, and the incentives involved, further exploration and practice are needed to determine the effectiveness, trustworthiness, and other impacts of Intent-driven systems.
Intermediaries and Mempool
The most obvious way to involve interested intermediaries in Intent is through Ethereum's Mempool. However, the current design of the Mempool does not support the dissemination of Intent. In the long run, considering the vulnerability to DOS attacks, the possibility of widespread support for propagating Intent in the Ethereum Mempool is very low. It can be said that the openness and permissionless nature of the Ethereum Mempool pose barriers to the adoption of Intent.
In the absence of Ethereum's Mempool, Intent system designers face some challenges. The current dilemma is whether to propagate Intent to permissioned parties or in a permissionless manner so that any party can execute Intent.
As shown in the figure, Intent flows from users to permissioned/permissionless public/private Intentpool, then gets transformed into transactions through a matchmaker, and finally gets placed in the public Mempool or directly displayed on-chain through MEV Boost type auctions.
Permissionless Mempool
One design being attempted is a decentralized API that allows nodes in the system to broadcast Intent via gossip, thus providing permissionless access for executors.
For example, in the 0x protocol relayer, mutual restricted orders are broadcasted via gossip and chained when a match is found. This approach is also being explored in the context of the shared ERC-4337 Mempool to counter centralization and censorship risks. However, this permissionless design of Intentpool also faces the following challenges:
DoS resistance: Developers may need to restrict the functionality of Intent to avoid potential DoS attacks.
Propagation incentives: For many applications, executing Intent is a profitable activity. Therefore, theoretically, the nodes operating Intentpool have an incentive not to propagate Intent to reduce competition in executing Intent.
MEV: Since the execution quality of Intent depends on the good behavior of off-chain participants, there are some difficulties in using a public permissionless Intentpool. If execution is profitable, permissionless Intentpool may attempt to front-run users. This is similar to the "sandwich attacks" in the current Ethereum Mempool, and it would be a common problem for Defi-related Intents. A possible improvement could be creating a permissionless Intentpool that undergoes encrypted processing.
Permissioned Mempool
A trusted centralized API has stronger resistance to DoS attacks and does not require Intent propagation. This trust model provides a basis for addressing MEV concerns. As long as the trust assumption holds, execution quality can be ensured. Trusted intermediaries may also have reputations associated with them, providing incentives to perform operations diligently.
Therefore, permissioned IntentPool is attractive to developers of Intent-based applications in the short term. However, the strong trust assumption inherently has flaws and somewhat contradicts the original spirit of blockchain.
Hybrid Solution
There are also hybrid solutions that combine the above two cases. For example, there is a situation where the propagation process is permissioned, but the execution is permissionless, and vice versa. A common example of a hybrid solution is order flow auctions.
This type of design approach involves the need for users of trading counterparties to differentiate between better and worse trading counterparties in order to trade at more favorable prices. The design process typically involves a trusted party, who obtains the Intent (or trade) from the user and facilitates the auction on behalf of the user. Participation in the auction is permissionless. There are also drawbacks to this type of design, as they are likely to be subject to various interferences in the licensed Intentpool.
The bottom line of this solution is that Intent-based applications involve not only a new message format that interacts with smart contracts, but also the need for propagation and counterpart discovery mechanisms in the form of an alternative mempool. Currently, the most critical aspect is to design a compatible incentive mechanism that simultaneously maintains decentralized Intent discovery and matching.
Risks and Mitigation
While Intent is an exciting new trading paradigm, its widespread adoption also means a trend towards greater user activity shifting to alternative mempools. If mismanaged, this transition could harm Ethereum's decentralization and lead to excessive power in trusted parties. The potential risks include:
Order Flow: If Intent execution is permissioned but users are careless in their choices, causing migration from the public mempool, Ethereum block production may become centralized.
Trust: As many solutions require trust in intermediaries, high entry barriers hinder the development of new architectures based on Intent, reducing innovation and competition.
Transparency: Since many Intent architectures require users to compromise some control over their chain assets and licensed mempools, there is a certain degree of opacity externally. Therefore, there are unclear answers to how user expectations are met and whether there are undiscovered ecosystem threats. The middleware and mempool ecosystems that develop between users and the blockchain also become less transparent.
So, how can we mitigate these risks? We know that the space in Ethereum mempool is limited. For some applications, the risk arises from their lack of privacy, which prevents them from supporting more extensive message formats. This puts wallet and application developers in a dilemma as they must find a way for users to connect to the blockchain while avoiding the aforementioned risks.
An ideal system should be permissionless so that anyone can match and execute intent without sacrificing too much execution quality. The system should be generic so that new applications can be deployed without the need to establish a new mempool. The system should be transparent so that the process of executing intent can be publicly reported, and data for auditing execution quality can be provided when privacy guarantees allow.
Although teams like FlashBots and Anoma are working hard to meet the requirements of the above general solutions by combining privacy and permissionless, it is difficult to create such a perfect system in the near future. Therefore, users need to weigh and choose different solutions for different applications. Similarly, applications that initiate Intentpool need to seek universality without permission and choose intermediaries carefully when permission is required.
Designers of Intent-based applications need to consider the off-chain implications of their applications comprehensively, as they not only concern their user base, but also involve a broader community, which requires a broader community to pay close attention to the off-chain ecosystem around Ethereum.
Summary
Due to the apparent market demand for Intent applications, many Intent-based applications have been widely used for several years. More and more Intent adoption driven in part by ERC 4337 may accelerate the transition from the Ethereum Mempool to new venues. Adoption of Intent represents a shift for users from a "forced operation" paradigm to a "descriptive" paradigm, which is expected to greatly improve user experience and efficiency.
