Figure 1: When submitting a transaction, the user specifies the exact computation path. When submitting an intent, the user specifies a goal and some constraints, and the matching process decides the computational path to take.
Importantly, many intents can be included in a single transaction, allowing overlapping intents to be matched, increasing gas and economic efficiency, e.g. in an Order-book maintained by a builder, two orders can cancel each other out before entering the market. Other applications include cross-domain intents—signing a single message, rather than multiple transactions on different domains—using different replay resistance schemes, and more flexible user gas payments, such as allowing third parties to sponsor gas or pay for gas in different Token payment.
past and future are intentions
The intent has been created to outsource the complexity of interacting with the blockchain, while allowing users to maintain custody of their assets and cryptographic identities.
You may notice that many of these ideas correspond to systems that have been in operation for many years:
- Limit order: 100X can be debited from my account if I receive at least 200Y.
- CowSwap-style auctions: Same as above, but rely on a third party or mechanism to match many orders to maximize execution quality.
- Gas Sponsorship: Gas is paid in USDC instead of ETH . This intent can only be fulfilled with a matching intent that pays a fee to ETH .
- Authorization: Only allow interaction with certain accounts in certain pre-authorized ways. An intent can only be fulfilled if the resulting transaction obeys the access control list specified in the intent.
- Transaction Batching: Allows batching of intents to improve efficiency and reduce gas fees.
- Aggregators: operate using only the "best" price/yield. This intent can be achieved by proving that aggregation of multiple places is performed and the best path is taken.
Going forward, intent is being reinvigorated in the context of Cross-chain MEVs (such as SUAVE), ERC4337-style account abstractions, and even Seaport orders! While ERC4337 is moving full speed ahead, other novel applications such as cross-domain intents still require further research. Further discussion of intents and their applications can be found in this talk.
Crucially, in all intent-based applications old and new, there needs to be at least one other party that understands the intent, is motivated to execute it, and is able to execute the intent in a timely manner. Who these parties are, how execution takes place, and what are their motivations are questions that must be asked to determine the effectiveness, trust assumptions, and wider implications of intent-driven systems.
The middleman and its mempool
The most obvious channel is the Ethereum mempool. Unfortunately, the current design does not support intent propagation. Concerns about DoS attacks may mean that general support for fully general intent 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 presents an additional barrier to adoption intentions.
In the absence of an Ethereum mempool, intent system designers now face some design issues. A high-level decision is whether to propagate the intent to a permissioned set, or to provide it in a permissionless manner so that either party can execute the intent.
Figure 2: Intents flow from users to permissioned/permissionless and public/private intent pools, converted by matchmakers to transactions, and finally into public mempools or directly on-chain via MEV boost-style auctions
Permissionless memory pools
One design that one might strive for is a decentralized API that allows intent to be propagated across nodes in the system, providing executors with permissionless access. This has been done before. For example, in the 0x protocol, relayers chat limit orders among themselves and place them on-chain when there is a match. This idea was also explored in the context of a shared ERC4337 mempool to combat centralization and censorship risks. However, the design of such a permissionless "intent pool" faces some significant challenges:
- DoS resistance: it may be necessary to limit the functionality of intents to avoid attack vectors (see ER C4337 proposal for further discussion)
- Spreading Incentives: Fulfilling intent is a lucrative activity for many applications. Therefore, nodes operating the intent pool have an incentive not to propagate intents to reduce contention when executing intents.
- MEV: Intents rely on the good behavior of off-chain actors to improve execution quality, which can be difficult when using public, permissionless intent pools. If poor execution is profitable, permissionless intent pools are likely to lead to that outcome. This is similar to Ethereum mempools today and is expected to become a common problem related to DeFi. A possible path forward here could be permissionless but encrypted intent pools.
Licensed "memory pool"
Trusted centralized APIs are more resistant to DoS attacks and do not need to propagate intent. Trust models also provide some footing for MEV problems. As long as the trust assumption holds, the quality of execution should be guaranteed. Trusted intermediaries may also have a reputation associated with them, which provides them with an incentive to execute well. Therefore, permissioned intent pools are attractive to intent-based application developers in the short term. However, we are all well aware that the strong trust assumption is flawed and somewhat antithetical to much of the ethos of blockchains. These issues are discussed below.
hybrid solution
Some solutions are mixtures of the above. For example, there can be permission to propagate, but no permission to execute (assuming the trust assumption holds), and 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 counterparties may need to distinguish between better and worse counterparties (eg, the other party that accepts a trade at a favorable price). Design flows typically include a trusted party that receives intents (or transactions) from users and facilitates auctions on behalf of users. Participating in auctions (sometimes) does not require permission.
These types of designs have their own drawbacks and are likely to be concerned by many permission intent pools, but there are some important distinctions that will become apparent later.
Bottom line: intent-based applications don't just involve new message formats for interacting with smart contracts, they also involve propagation and adversary discovery mechanisms in the form of alternative mempools. Designing an intent discovery and matching mechanism that is incentive-compatible and at the same time decentralized is non-trivial.
Where can go wrong?
While intents are an exciting new transaction paradigm, their widespread adoption could mean accelerating a larger trend of shifting user activity to other mempools. If not managed properly, this shift could lead to centralization and entrenching of rent-seeking middlemen.
order flow
Migrating from the public mempool could centralize Ethereum's block production if intent execution is allowed, and the permission set is not chosen carefully.
Migrating from the public mempool could centralize block production in Ethereum if intent execution is permissioned, but the permission set is not chosen carefully.
The vast majority of block production on Ethereum currently occurs via MEV-Boost, an off-protocol implementation of proposer-builder separation (PBS), and the current roadmap gives no indication that this interface will Change soon. PBS relies on the existence of a competitive market for block builders to direct MEV to the validator set. A major problem with PBS is that block builders gain exclusive access to the raw materials needed to produce valuable blocks — transactions and intent, aka “order flow.” In PBS parlance, permissioned access to intents is known as Exclusive Order Flow (EOF). As discussed in this paper, an EOF in the hands of the wrong party threatens the market structure on which PBS relies, as the exclusivity of order flow implies a moat against competitive forces.
Block builders (or collaborating entities) that control the majority of Ethereum’s order flow will be able to produce the majority of Mainnet blocks, opening an avenue for censorship. Since the network relies on competition among builders to pass value to validators (or be burned in the future), the dominance of a single builder will constitute a transfer of value from Ethereum to builders. Rent-seeking and censorship are of course important threats to the protocol.
trust
Since many solutions require trust in an intermediary, the development of new intent-based architectures is hampered by high barriers to entry, meaning lower rates of innovation and competition to ensure quality of execution.
In the worst case, users find themselves in a position where only one party executes the intent, such as the monopoly block builder in the previous section. In such a world, monopoly block builders would be able to extract rents, and any new proposals for how to handle intent would be rejected if not adopted by builders. Individual users lose negotiating power in the face of a monopoly—an effect that is exacerbated when users intend to give extra degrees of freedom to intermediaries.
Unfortunately, market stagnation due to centralized infrastructure does not include concerns about a market for builders. Even for non-block building businesses, a high barrier to entry can put middlemen in an advantageous position, as they face little competition. For example, consider the current state of the order flow auction market. A few entities like Flashbots and CoWswap receive most of the orders flowing to OFA. Order flow is distributed in large part because these entities have been around for years, or are associated with reputable entities, meaning they have managed to gain some level of public trust. If a new OFA design tries to enter the market, whoever is running 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. This need to earn trust certainly poses a significant 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 where permissioned, trusted mempools may contain a small number of powerful participants, thereby harming the best interests of users.
The EIP4337 intent format provides another example of a mechanism that is possible. Consider a world where trusted architectures are in place to support 4337 intents. If another intent format was proposed, it might serve other use cases like cross-origin functionality, but established trusted intermediaries don't adopt this new format (after all, it doesn't get much adoption and competes with their business model ), implementations of the new format will need to establish trust in the new entity. Once again, we find ourselves in a situation where innovation and challenging the status quo meet barriers to entry based on trust.
Opacity
Since many intent architectures require users to relinquish some control over their on-chain assets, and permissioned mempools imply a degree of impermeability from the outside, we run the risk of building an opaque system in which what users expect Or whether it is met is unclear, and threats to the ecosystem remain undetected.
The above sections deal with the risks that power imbalances in order flow markets pose to users and protocols. A related problem is that the ecosystem of middleware and mempools developed between users and the blockchain becomes opaque even to keen observers. This problem applies especially to intent-based applications that attempt to allow users to outsource important decisions such as order routing.
Situations where MEV negatively impacts user execution are often due to transactions giving up a high degree of freedom to their executors (e.g. slippage limits). So it's not a huge leap in logic to assert that intent-based applications that give up greater degrees of freedom should more carefully design their systems to execute. The worst outcome in this regard is that using an intent-based application requires signing a vanishing intent (into a dark forest, if you like), which is then somehow implemented as a transaction without it being clear how or by whom Created. Of course, the ability to monitor such ecosystems is also related to concerns about EOF and trust-based defenses. If this ecosystem is murky to the most keen observers, how is the Ethereum community supposed to monitor threats to the health of its block production ecosystem?
mitigate risk
The Ethereum mempool is limited. For some applications this is due to its lack of privacy (sandwiched in the middle), 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 bind, as they must find some way to connect users to the blockchain while avoiding the aforementioned dangers.
When examining the above questions, we can infer certain properties of ideal systems. Such a system should be
Permissionless so anyone can match and execute intents without sacrificing too much execution quality
Generic so that deploying new applications does not require creating new memory pools,
Transparent so that the process of reporting intent execution is publicly reported where privacy guarantees allow, and provides data for performing quality audits.
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 anytime soon. Therefore, different solutions make their own tradeoffs that may best serve different applications. While mechanisms like crlists arose in response to many of the same problems surrounding transaction-based applications, and may not be applicable to intent, a gadget that allows users to fall back to transactions whenever possible would do well to ameliorate the worst Case. Likewise, applications wishing to start an intent pool, if not permissioned, do well to seek commonality, and if they do, choose intermediaries carefully.
Broadly speaking, we ask intent-based application designers to fully consider the off-chain impact of their applications, because these may touch the wider community, not just their user base, and we ask the wider community to closely Focus on the off-chain ecosystem around Ethereum.
in conclusion
The adoption of intents represents a shift from an imperative to a declarative paradigm, which promises to significantly improve user experience and efficiency losses due to MEV leaks. The need for these applications is clear, and many intent-based applications have been in widespread use for many years.
The increasing intent to adopt, driven by ERC4337, may accelerate the transfer of Ethereum mempools to new venues. While this shift is reasonable and inevitable, intent-based application designers have good reason to carefully design the off-chain components of their systems when developing a robust infrastructure.
There is still a lot of research and engineering to be done in this nascent transactional paradigm and in areas we did not cover in this paper, such as designing an intent expression language that allows privacy. If you find this or other intent-related research topics interesting, please contact 0xquintus georgios@paradigm.xyz.
Many thanks to Dan Robinson, Charlie Noyes, Matt Huang, John gu, Xinyuan Sun, and Elijah Fox for their feedback on this article, and Achal Srinivasan for designing the graphics.
