Taking Cowswap, Uniswap, and Anoma as examples, how can intentions be optimized to enhance the trading experience?

Original Title: An Incomplete Primer on Intents Original Author: 0xemperor.eth Compiler: Qianwen, ChainCatcher

Recently, the concept of intents has gained popularity in discussions and research within the crypto space, with various protocols leveraging this idea, such as Anoma and Essential.

This article aims to provide a preliminary introduction to various viewpoints, concluding with a presentation of how intent resolution architecture manifests when expressing intents in natural language. If the concept of intent can be successfully implemented, it has the potential to fundamentally change application architecture at all levels.

What is Intent?

Intent allows users to specify certain transaction conditions or preferences without providing precise message calls, thereby increasing flexibility and reducing on-chain complexity.

In the article "Intent-Based Architecture and Its Risks", intent is defined as: a set of declarative constraints that allows users to outsource transaction creation to third parties without relinquishing complete control over the transaction.

In a podcast episode, Chris Goes from Anoma defined it from two perspectives: intent refers to "a credible commitment to a preference for certain system states" and "a credible commitment to restrictions on information flow."

One intuitive way to understand intent is that it essentially represents the desired outcome. When you express an intent, you are merely defining the result you want, rather than the process of achieving that goal.

For example, if you want to exchange Tether (USDT) for ETH, you do not need to manage the entire process yourself—choosing an exchange, setting up an account/signing a transaction, handling transfers (or cleaning up crypto dust in your wallet), etc. You simply submit an intent document stating that you want to exchange 1 ETH for 2000 USDT. Another entity (referred to as the Solver) will accept your intent and figure out how to fulfill it. The Solver will handle the messy details, striving to optimize the best outcome for you.

The key point is that intent focuses on the outcome rather than the process. Users define the desired result, while others implement it through the process. Intent allows you to specify the outcome without worrying about the steps, significantly simplifying the transaction process that most users engage in within cryptocurrency.

A higher-level idea is that users can define what they want without specifying which contracts they wish to start trading from (which we can refer to as computational paths or simple trading paths). Users can also indicate their preferences for certain paths or contracts, thereby imposing restrictions on them.

Use Cases

Cowswap

Cowswap utilizes batch auctions as its core price discovery mechanism. Unlike AMMs, Cowswap does not execute trades immediately but aggregates orders off-chain and settles them in batches. This allows for a unified settlement price for all trades within a batch, eliminating issues like front-running that are common in immediate execution models. Batch auctions can also settle many trades simultaneously, optimizing gas fees. Solvers compete publicly to submit order settlement solutions, ensuring that the trading parties in each batch can maximize their benefits. The best solution determines the final unified price. Overall, batch auctions achieve fairness, efficiency, and MEV protection, which immediate execution models cannot.

A key innovation of Cowswap's batch auction model is the ability to find coincidences of wants (CoW) between orders. CoW is direct peer-to-peer settlement between trades with reciprocal demand. This liquidity sharing means that external liquidity providers are not needed to facilitate these trades. CoW can also include multiple assets in circular trades. By maximizing CoW, batch auctions can achieve more liquidity than isolated liquidity pools. When allowed, settlements will utilize CoW, while the remainder will be executed through on-chain liquidity. Combining batch auctions with CoW liquidity sharing can provide traders with better pricing and execution.

The Cowswap model is similar to the intent model, where users express trading intents in the form of limit orders. The trading intents are entered into the order book, and Solvers use the state of the order book to match them in circular trades or route them through AMMs (i.e., users only mention the price without specifying the computational path or the exact location they want to execute).

Uniswap X

The Uniswap X paper proposes a decentralized trading protocol that uses signed off-chain orders and settles on-chain through Dutch auctions. Users sign orders, specifying parameters such as input/output tokens, amounts, and price limits. These orders are distributed to "Fillers," who compete for the best execution price.

Uniswap X suggests setting the initial Dutch auction price through an off-chain pricing system. Users can inquire about prices from the filler network and provide a brief exclusivity period for the best quotes to incentivize honest pricing, after which the orders enter a public Dutch auction.

Similarities Between Uniswap X and Cowswap

• Both use off-chain signed orders and aggregate and settle them on-chain in batches. This can save gas fees compared to on-chain orders.
• Both aim to facilitate competition among liquidity providers to find the best execution price (liquidity providers are referred to as Solvers in Cowswap and Fillers in Uniswap X).
• Cowswap emphasizes using CoW to drive direct peer-to-peer trades, while Uniswap X focuses more on integrating off-chain and on-chain liquidity sources.
• The RFQ (Request for Quote) system and signing model in Uniswap X (where users express intent and let others fill orders) are similar to the intent architecture.

Formal Definition of Intent

Users simply express their intent, such as "I want to exchange asset X for asset Y," and the Solver will figure out how to best fulfill that intent, handling all blockchain-related details behind the scenes. The Solver provides proof that the intent has been fulfilled and can participate in mechanisms like auctions to achieve the intent in a decentralized manner.

This blog explores some definitions:
The first model: Intent i is defined as a tuple (B, E, T):

• B represents the supported set of "starting" states.
• E represents the supported set of "ending" states.
• T is a set of preferred transaction sequences.
• The state transition function s: Q×T → T moves from the starting state to the ending state through a series of transactions t.

If an intent starts from state q~0~∈B through a transaction sequence t∈T and ends at state q~n~∈E, then the intent is considered fulfilled.

Intent Clearing: If the sets B, E, and T have a non-empty intersection, a set of intents t~o~, …, t~m~ can be cleared, allowing the creation of a meta-intent t'.

As we mentioned earlier, intents are issued by users and then resolved by Solvers; regardless of how they are expressed, intents are an optimization problem for Solvers. In simple terms, a user might express an intent like "I want to buy BTC worth 4 ETH," and the Solver will typically find a place to fill or swap that order. But intents are not limited to this; they also allow constraints like "as low slippage as possible" and "do not trade on DEXs that prohibit US users" to be added, which become additional constraints that the Solver must keep in mind.

Challenges include:

• The need to simplify intent expression.
• Specific intents may impact user welfare, such as zero slippage in DEXs.
• Execution tracking may require attention due to risks or legal reasons.

The goal is to strike a balance between clearly capturing user intent preferences and the practical considerations of computational efficiency and user experience.

Here also mentions a Lagrangian interpretation of intent search.

To me, the expression of intent resembles a Markov decision process. However, the state transitions in a Markov decision process are random, while this would be a deterministic MDP with absolute state transition values, solvable through value iteration, policy iteration, or MCTS (Monte Carlo Tree Search), the latter also being used to solve parts of Go in Alphago.

Intent Can Enhance User Experience

Intent may represent the next stage in the evolution of on-chain user experience. Currently, on-chain user experience primarily revolves around the transaction level, where users sign each transaction as part of the operation. Therefore, every step on-chain is expressed through transactions. In very simple terms, intent is a meta-transaction, where the activities are expressed at a very abstract level, with the Solver striving to meet the user's intent needs. This may include buying some ETH at price X, wanting to get the best possible deal, which can be done either as a single large swap on Uniswap on Ethereum or split on a roll-up to buy ETH (also considering fees).

Currently, a simple swap from USDC to ETH involves the user approving token limits, approving token types, and then approving the transaction, whereas in an intent-centric world, the user can abstract away from these details and simply execute the desired operation. There is an unofficial rule in web design that no operation should take more than three clicks; currently, if users want to perform a swap, they must select tokens simultaneously, perhaps adjust slippage and transactions, which may not seem like much for a single transaction, but after repeated occurrences, it leads to a cumbersome user experience.

Unibot presents a very basic way of showcasing a model for intent architecture. It eliminates the complex parts of trading, providing traders with a simple and user-friendly experience, but it may impose some limitations on potential flexibility. Although the app is said to have risks related to key handling, which could lead to attacks, it still maintains a stable user base under tax conditions, indicating that opportunities for user experience in the cryptocurrency world remain to be explored.

Conversational Intent Flow

How can AI intervene in an intent-centric blockchain world? The concept of intent recognition has existed in the field of natural language processing for decades and has been extensively researched in dialogues. For example, suppose a user visits a travel website and interacts with a chatbot; they may initially want to book a flight or check a booking or status, and then provide various details. If booking a flight, the user needs to provide the destination, time, date, and the class of ticket they are interested in; in some cases, the user may also need to choose an airport. In this example, the user's purpose is the intent of the dialogue, and the various details provided by the user are the slots/details that need to be filled to achieve that intent.

Annotated dialogue state in conversation

Another example of intent recognition and slot filling is when you intend to play a song, where various slots (details) related to the song, such as the song title and artist, appear in the sentence.

In the world of dialogue, intent classification and slot filling is a very complex issue because your conversation may span multiple turns, sometimes having global and local intents, and you must track numerous states. Whenever you use Siri or Google Assistant to set an alarm or record something in your calendar or birthday, there is some degree of intent classification and slot filling behind it.

What does this have to do with blockchain? As we transition from a transaction-centric world to an intent-centric world, the interface from intent to transaction details has not yet emerged in public discussions. There is no interface between intent pools and memory pools. Accessing on-chain models and using them for intent recognition and slot filling provides a natural language interface for intent pools and Solvers (which I believe is the most natural interface).

The general idea is to access a set of models on-chain, reducing each intent to a DSL (domain-specific language); this DSL would include core intents (buy, sell, bridge, borrow/lend) and other details such as addresses, sizes, and slippage preferences (depending on the type of intent). A global DSL allows anyone to deploy models, simplifying intents into specific DSLs. In the presence of multiple such models, a voting model will be adopted from the set of models.

The availability of on-chain models helps us securely and provably develop this interface, where each intent/solution's computational proof can be verified. In some cases, capturing the results of majority voting across various models may provide insights into how intents are chosen, and in certain individual cases, it may even help Solvers better resolve these intents.

The on-chain models used here could be standard deep learning models like BERT, which are specifically trained for this purpose, or large language models used for inference in the ensemble; this detail may depend on different participants or Solvers. In the case of crypto intent pools, we need to use homomorphic encryption or private inference methods to ensure data privacy while still allowing computations. Every epoch or every few epochs, a proof can be published on-chain by the model for validators. Validators can be human or another model, issuing statements about the model's validity. Regardless of whether the model can accurately handle intents, this part of the process ensures that the model's lifecycle is considered. Sometimes, when the validator is a mature participant, they may discover flaws in the model, which can be quickly addressed and replaced with an updated model.

As shown in the figure, for the action/idea of "purchasing with the stablecoins and dust in my wallet," once it enters the intent pool, it will be processed through various models and parsed into a DSL containing various details such as intents, sub-actions, and details that need to be filled. The parsing of the DSL can be as detailed or as abstract as possible; the intent dialogue may last several turns as the dust threshold may need to be determined. Once the DSL is in place, the Solver can choose the best path to convert these balances into ETH and then pass the transaction to the memory pool.

Example of intent resolution model

Another DSL Architecture—Essential

Account abstraction turns all accounts into smart contracts, separating accounts in Ethereum from signers. This allows accounts to customize different authorization logic based on user needs. However, achieving complete account abstraction requires significant adjustments to Ethereum's core protocol.

EIP 4337 takes a different approach to achieve the benefits of account abstraction without changing the consensus layer. It introduces "user operations"—pseudo-transactions submitted to an alternative memory pool, bundled by "bundlers" into transactions calling the EntryPoint smart contract.

This enables functionalities like social recovery, paying fees with any token, and batch transactions. Developers can set up custom accounts tailored to different use cases. By avoiding protocol changes, EIP 4337 can bring these benefits to Ethereum more quickly. However, it also introduces new complexities and actors, such as bundlers and payers. The resulting dynamics between multiple memory pools, incentive mechanisms, and transparency will require careful management.

Intent allows users to specify a desired outcome rather than a specific operation. The Solver then helps users achieve this outcome in the best way. However, the current implementation has limitations, exhibiting centralization, a lack of composability, and insufficient competition among Solvers.

The EIP initiative proposed by Essential aims to change this situation. Through initiatives like EIP 4337 for account abstraction, smart contract-based accounts can be realized instead of traditional externally owned accounts (EOAs). This allows users to submit general intents without needing to submit simple transactions. Intents represent the desired outcomes of users and can be supplemented by Solvers to maximize participant satisfaction.

EIP 7521 proposes a framework to support evolving intent standards without the need for constant upgrades to smart contract wallets. Users sign "user intents," specifying which "intent standard" contract should handle that intent. These intents are submitted to the EntryPoint contract, which handles signature verification as in EIP 4337. The user intent memory pool coexists with the ERC 4337 memory pool, with Solvers processing intents.

User intent under ERC-4337 account abstraction

Anoma

Anoma is an intent-centric architecture that builds its infrastructure layer around programming intents rather than transactions. Intents are partial state changes expressing preferences signed by users, rather than complete state change transactions. This intent-centric design enables decentralized counterparty discovery and resolution. Anoma is attempting to shift from a declarative to an imperative paradigm.

Excerpt from Adrian Brink's talk on intent-centric applications

Users broadcast intents, which propagate through the intent gossip network. Different nodes can specialize in propagating certain intents based on their computational resources and the types of intents they wish to serve. Solvers observe intents and attempt to combine compatible intents into valid transactions that can be settled on-chain. Transactions are submitted to an encrypted memory pool using threshold encryption technology, preventing front-running. Anoma also has a partial intent model that allows for intent combinations.

Chris speaking on intent x Rollup - Anoma partial intent model

Anoma's focus on privacy is on "user-level choices," allowing users to flexibly disclose their intent information and choose what to reveal.

The architecture consists of multiple components. The Tiger execution engine uses ZKP and homomorphic encryption technologies to handle transparent, protected private data. Typhon is the consensus algorithm. The compiler stack includes the Juvix language, AnomaVM, and VampIR.

This architecture features homogeneous protocols and heterogeneous security models. It can be deployed as an independent blockchain or as a ZK roll-up or decentralized order book for decentralized distribution of applications on Ethereum. Users with different security needs can leverage the same protocol while making trade-offs in security based on their requirements.

Compared to transaction-centric models, Anoma makes it easier to build decentralized applications. Intents support new applications like running rollups, multi-party trading, and private DAOs. In summary, Anoma provides a flexible modular architecture that meets the demands of contemporary decentralized applications. It focuses on intents rather than transactions, addressing issues of counterparty discovery and coordination while preserving privacy.

Anoma has a unique design philosophy that views intents as "information flows" and "restricted/private information flows," informing its architectural and design choices. This also highlights the fact that Anoma's intent composition model brings about a broad intent model, which may be technically challenging to resolve under privacy constraints, as trade-offs in efficiency limit the amount of information that can be kept confidential.

Conclusion

Intent, as a research and engineering problem, is currently a very interesting area in cryptographic technology.

Open questions that need to be addressed in the field of intent include:

• What is the formal definition of intent?
• What does an intent-centric application architecture look like beyond DEXs?
• When solving any optimization problem, designing trade-offs between privacy and utility requires obtaining as much information as possible. To achieve privacy for intents, a certain amount of information must be disclosed to resolve the intent problem.
• What is the most basic knowledge required to solve intent problems?
• If you want to cut off access to other knowledge, what trade-offs must you make?
• How can this trade-off between privacy and efficiency be expressed in a general way?

General intents may be too large to solve, and for a vast state space like Ethereum, this can evolve into a difficult problem to resolve. This indicates that solving intent problems is best done with some constraints, and attempts to combine intents should also be limited (when common intents exist). In my view, general intents are extremely difficult to implement in practice, while intent-centric architectures will inherently be** application-specific.

While these are all research questions, the design choices for implementing intents will also lead to various engineering problems. It may result in over-reliance on (permissioned) intermediaries, potentially leading to infrastructure centralization across different stacks (in the case of UniswapX, 77% of trading volume is filled off-chain). It may also reinforce the position of trusted intermediaries, raising barriers to entry and stifling innovation, as seen in MEV. Any intent protocol's design must strike a balance between permissionlessness, privacy, transparency, and decentralization.