Author: Quintus Kilbourn, Georgios Konstantopoulos, Paradigm; Translation: Golden Finance 0xxz
introduction
Recently, the discussion around “intents” and their applications has become a hot topic in the Ethereum community.
If a transaction explicitly refers to “how” an action should be performed, then intents refer to “what” the intended outcome of that action should be. If a transaction says “do A first, then do B, pay exactly C to get X,” then intents say “I want X, and I’m willing to pay at most C.”
This declarative paradigm unlocks exciting user experience and efficiency improvements. Through intents, users are able to simply express a desired outcome while outsourcing the best task of achieving that outcome to an experienced third party. The concept of intents contrasts with today's imperative transactional paradigm, where every parameter is explicitly specified by the user.
While the promise of these improvements provides much-needed steps for the ecosystem, the intent-based design on Ethereum may also have significant impacts on off-chain infrastructure. In particular, there are important connections to MEV-related activities and market control. This post aims to provide a brief definition of intents and their benefits, an exploration of the risks involved in their implementation, and some discussion of potential mitigations.
What are intents?
The current standard way for users to interact with Ethereum is to craft and sign a transaction, a specifically formatted message that provides all the necessary information for the Ethereum Virtual Machine (EVM) to execute state transitions. However, creating transactions can be a complex affair. Creating transactions requires reasoning about details such as a vast network of smart contracts and random number management, while holding specific assets to pay gas fees. This complexity leads to suboptimal user experiences and reduced efficiency as users are forced to make decisions without adequate access to information or complex execution strategies.
Intents are designed to relieve users of these burdens. Informally, intents sign a set of declarative constraints that allow users to outsource transaction creation to a third party without giving up full control over the transaction party.
In the standard transaction-based flow, transaction signatures allow the verifier to follow precisely one computation path for a specific state, while hints incentivize the verifier to do so. Intents, on the other hand, do not explicitly specify a computation path that must be taken, but rather allow any computation path that satisfies certain constraints. By signing and sharing intents, users effectively grant the recipient the authority to choose a computation path on their behalf (see figure below). This distinction allows for a slightly more strict definition of intents as signed messages that allow a set of state transitions from a given starting state, with a special case being transactions that allow unique transitions. Having said that, we will continue to distinguish "intents" from transactions.
Figure 1: When submitting a transaction, the user specifies the exact computation path. When submitting intents, the user specifies the target and some constraints, and the matching process determines the computation path to take.
Importantly, many intents can be included in a single transaction, allowing matching of overlapping intents, increasing gas and economic efficiency, such as in an order book maintained by builders where two orders can cancel each other out before entering the market. Other applications include cross-domain intents - signing a single message instead of multiple transactions on different domains - using different replay resistance schemes, and more flexible user gas payments, such as allowing 3rd parties to sponsor gas or pay in different tokens.
The past and future of intents
Intents have been created to outsource the complexity of interacting with the blockchain while allowing users to maintain custody of their assets and crypto identities.
You may notice that many of these ideas correspond to systems that have been running for many years:
Limit order: If I receive at least 200 Y, 100 X may be withdrawn from my account.
CowSwap-style Auctions: Same as above, but relying on a third party or mechanism to match many orders to maximize execution quality.
Gas sponsorship: gas is paid in USDC instead of ETH. Intents can only be fulfilled by matching intents, and fees are paid in ETH.
Delegation: Allows interaction with certain accounts only in certain pre-authorized ways. Intents can be fulfilled only if the resulting transaction adheres to the access control list specified in the intent.
Batch transactions: Allows intents to be batched to improve gas efficiency.
Aggregator: Operates only with the “best” price/revenue. This intent can be achieved by proving that aggregation of multiple venues was performed and the best path was taken.
Looking ahead, intents are seeing a renaissance in the context of cross-chain MEV (e.g. SUAVE), ERC4337-style account abstractions, and even Seaport orders! While ERC4337 is moving full steam ahead, other novel applications like cross-domain intents require further research.
It is critical that in all intents-based applications, old and new, there is at least one other party that understands the intent, has the motivation to execute it, and is able to execute it in a timely manner. Questions about who these parties are, how they execute, and what their motivations are must be asked to determine the efficacy, trust assumptions, and broader implications of intent-driven systems.
The middleman and its memory pool
The most obvious channel for intents to get into the hands of middlemen is the Ethereum mempool. Unfortunately, the current design does not support the propagation of intents. Concerns about DoS attacks may mean that universal support for fully general intents in the Ethereum mempool is impossible even in the long run. As we will see below, the open and permissionless nature of the Ethereum mempool creates additional barriers to the adoption of intents.
In the absence of an Ethereum mempool, intents system designers now face a number of design issues. A high-level decision is whether to propagate intents to a permissioned set or to provide them in a permissionless manner so that any party can execute the intent.
Figure 2: Intents flow from users to permissioned/permissionless and public/private intents pools, are converted into transactions by intermediaries, and ultimately enter the public memory pool or go directly on-chain via MEV Boost-style auctions.
Permissionless mempool
One design one might strive for is a decentralized API that allows intents to be propagated across nodes in the system, providing permissionless access for executors. This has been done before. For example, limit orders are gossiped between 0x protocol relayers and placed on-chain when matched. This idea is also being explored in the context of shared ERC4337 mempools to combat centralization and censorship risks. However, the design of such a permissionless “intent pool” faces some significant challenges:
Anti-DoS: It may be necessary to limit the functionality of intents to avoid attacks.
Propagation incentives: For many applications, executing intents is a profitable activity. Therefore, nodes operating the intent pool have an incentive not to propagate in order to reduce contention when executing intents.
MEV: Intents rely on good behavior of off-chain participants to improve execution quality, which may be difficult with public, permissionless intent pools. If bad execution is profitable, then permissionless intent pools are likely to lead to that outcome. This is similar to being stuck in the Ethereum mempool today, and is expected to become a common problem for DeFi-related intents. A possible path forward may be permissionless but encrypted intent pools.
Permitted “memory pool”
Trusted centralized APIs are more resistant to DoS and do not require intents to be propagated. The trusted model also provides some foothold for the MEV problem. As long as the trust assumption holds, the quality of execution should be guaranteed. Trustworthy intermediaries may also have a reputation associated with them, providing some incentive to provide good execution. Because of this, permissioned intent pools are attractive to intent-based application developers in the short term. However, as we are all aware, strong trust assumptions are flawed and somewhat antithetical to much of the blockchain ethos. These issues will be touched upon below.
Hybrid Solutions
Some solutions are a hybrid of the above. For example, one can have permissioned propagation but permissionless execution (assuming the trust assumption holds), or vice versa. A common example of a hybrid solution is an order flow auction.
The high-level idea behind these designs is that users who need a counterparty may need to distinguish between better and worse counterparties (e.g., the other party who accepts the trade at a favorable price). The design process usually includes a trusted party that receives the user's intent (or trade) and facilitates the auction on their behalf. Participation in the auction is (sometimes) permissionless.
These types of designs have their own drawbacks and may be subject to many of the concerns surrounding permission intent pools, but there are some important distinctions that will become apparent later.
Bottom line: intent-based applications involve not only new message formats for interacting with smart contracts, they also involve alternative propagation and counterparty discovery mechanisms in the form of mempools. Designing an intent discovery and matching mechanism that is incentive-compatible and at the same time decentralized is not trivial.
What could go wrong?
While intents are an exciting new transaction paradigm, their widespread adoption could mean that a larger trend of user activity shifting toward alternative mempools is accelerating. If not managed properly, this shift could lead to the centralization and entrenchment of rent-seeking middlemen.
Order Flow
If intent execution is permissioned but the permission set is not carefully chosen, migrating away from the public mempool could lead to centralization of Ethereum block production.
The vast majority of block production on Ethereum is currently conducted via MEV-Boost, an out-of-protocol implementation of Proposer-Builder Separation (PBS), and the current roadmap shows no signs that this interface will change anytime soon. PBS relies on the existence of a competitive market of block builders to direct MEV to the validator set. A major problem in PBS is the ability for block builders to gain exclusive access to the raw materials needed to produce valuable blocks - transactions and intents, also known as "order flow." In the language of PBS, permissioned access to intents would be referred to as "exclusive order flow" (EOF). As discussed in this article, EOF in the wrong hands threatens the market structure that PBS relies on, because exclusivity in order flow represents a moat against competing forces.
A block builder (or cooperative entity) that controls the majority of Ethereum’s order flow will be able to produce the majority of mainnet blocks, opening a vector for censorship. Since the network relies on competition between builders to pass value to validators (or be destroyed in the future), the dominance of a single builder will constitute a transfer of value from Ethereum to builders. Rent-seeking and censorship are undoubtedly important threats to the protocol.
trust
The development of new intent-based architectures is hampered by high barriers to entry as many solutions require trust in intermediaries, meaning lower rates of innovation and competition to ensure quality of execution.
In the worst case, users can find themselves in a position where only one party can enforce intents, such as the block-building monopolist in the previous section. In such a world, the block-building monopolist will be able to extract rents, and any new proposals for how to handle intents will be rejected if the builders do not adopt them. Faced with a monopolist, individual users lose bargaining power—an effect that is exacerbated when users use intents to provide additional degrees of freedom to middlemen.
Unfortunately, concerns about the builder market are not included in the market stagnation caused by centralized infrastructure. Even for non-blockchain building businesses, high barriers to entry put middlemen in an advantageous position because they face little competition. For example, consider the current state of the order flow auction market. A few entities such as Flashbots and CoWswap receive the majority of order flow sent to OFAs. The distribution of order flow is largely because these entities have been around for many years or are associated with reputable entities, which means that they have successfully gained a certain level of public trust. If a new OFA design attempts to enter the market, whoever is operating the new OFA will have to spend a lot of time convincing users and wallets that they are reputable and will not abuse their power. The necessity of this trust-winning exercise undoubtedly constitutes a substantial barrier to entry.
The order flow auction market has only recently begun to gain traction, and it remains to be seen how competition will develop, but the market does provide an illustrative example of a situation in which a permissioned, trusted mempool could serve to enshrine a small number of powerful actors, to the detriment of the best interests of users.
The EIP4337 intent format provides another example of where we might have a mechanism for adoption. Consider a world where a trusted architecture is already in place to support 4337 intents. If another intent format is proposed — perhaps serving additional use cases like cross-domain functionality — but the established trusted intermediaries do not adopt this new format (after all, it doesn’t have much adoption and competes with their business model), implementation of the new format requires building trust in the new entity. Again, we find ourselves in a situation where we can innovate and challenge the status quo, but encounter barriers to entry based on trust.
Opacity
Since many intents architectures require users to relinquish some control over their on-chain assets, and permissioned mempools imply a degree of external impenetrability, we run the risk of building an opaque system where it is unclear how or if user expectations are being met, and threaten the ecosystem to remain undiscovered.
The above section addresses the risks to users and protocols posed by power imbalances in the order flow market. A related concern is that the ecosystem of middleware and memory pools that have evolved between users and blockchains has become opaque even to astute observers. This concern is particularly relevant to intent-based applications that seek to allow users to outsource important decisions such as order routing.
The cases where MEV negatively impacts user execution are generally due to executors giving up a high degree of freedom in transactions (e.g. slippage limits). It is therefore not much of a leap in logic to assert that intent-based applications that give up greater freedom should design their execution systems more carefully. The worst outcome in this regard is a world in which using an intent-based application requires signing an intent that disappears (into the dark forest, if you will) and then is somehow implemented as a transaction, but it is unclear how or by whom the transaction was created. Of course, the ability to monitor such an ecosystem is also related to concerns about EOF and trust-based defenses.
Mitigating Risks
The Ethereum mempool is limited. For some applications, this is due to its lack of privacy (the sandwich), and for others, it is due to its inability to support a wider range of message formats. This puts wallet and application developers in a difficult position, as they must find some way to connect users to the blockchain while avoiding the dangers mentioned above.
When examining the above questions, we can infer certain properties of an ideal system. Such a system should be permissionless, so that anyone can match and execute intents without sacrificing too much execution quality; general, so that deploying new applications does not require setting up new memory pools; transparent, so that the process of executing intents is publicly reported and data is provided for execution quality audits when privacy guarantees allow.
While teams like Flashbots and Anoma are working on general solutions that meet the above requirements by combining privacy and permissionlessness, the ideal system may not be ready any time soon. As such, different solutions making their own tradeoffs may best serve different applications. While mechanisms like crlists, which emerged in response to many of the same issues surrounding transaction-based applications, may not work well with intents, gadgets that allow users to fall back to transactions when possible may well improve the worst-case scenario. Similarly, applications that wish to start a pool of intents would be best served to seek generality when permissionless, and to choose middlemen with caution when permissioned.
More broadly, we ask designers of intent-based applications to thoroughly consider the off-chain impacts of their applications, as these may touch the broader community beyond just their user base, and we ask the broader community to pay close attention to the off-chain ecosystem surrounding Ethereum.
in conclusion
The adoption of intents represents a shift from the imperative paradigm to the declarative paradigm, which is expected to significantly improve the user experience and efficiency losses due to MEV. The need for these applications is clear, and many intent-based applications have been in widespread use for many years.
The growing adoption of intents, driven by ERC4337, will likely accelerate the migration from the Ethereum mempool to new venues. While this move is logical and inevitable, designers of intent-based applications have good reasons to carefully design the off-chain components of their systems while developing a robust infrastructure.
There is still a great deal of research and engineering to be done in this nascent transaction paradigm and in areas we have not covered in this article, such as designing a language for expressing intents that allows for privacy.
Many thanks to Dan Robinson, Charlie Noyes, Matt Huang, John Guibas, Xinyuan Sun, and Elijah Fox for their feedback on this article, and to Achal Srinivasan for the slide design.
