Taking Cowswap, Uniswap, Anoma, and other examples as a demonstration, this article provides a detailed explanation of the basic principles of optimizing the trading experience.

This article explains the principles of optimizing the trading experience using examples like Cowswap, Uniswap, and Anoma.

Original Title: An Incomplete Primer on Intents

Original Author: 0xemperor.eth

Translation: Qianwen, ChainCatcher

In recent research and discussions in the field of cryptography, intents have become popular, and various protocols are using this concept, such as Anoma, Essential, and other protocols that draw on this concept.

• friend.tech’s explosion reveals Does the phenomenon-level SocialFi application come from the native encryption or rely on Web3?
• Hainan issues a red-headed document to cut across to NFT digital collections.
• Viewpoint First Principles Thinking in the Blockchain Industry

This article aims to provide a preliminary introduction to various viewpoints and finally introduce the presentation of intent resolution architecture when expressing intent in natural language. If the concept of intent can succeed, it is expected to completely change application architecture at various levels.

What is Intent?

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

In the article “Intent-Based Architecture and Its Risks,” the definition of intent is: Intent is a set of declarative constraints that allow users to outsource transaction creation to third parties without giving up full control over the transaction parties.

In a podcast, Chris Goes from Anoma defined it from two aspects: Intent refers to “trusted commitments to certain system state preferences” and “trusted commitments to information flow restrictions.”

One intuitive way to understand intent is that it basically represents the expected result. When you express an intent, you are simply defining the result you want, not the process of achieving the goal.

For example, if you want to exchange Tether (USDT) for ETH, you don’t need to manage the entire process yourself—selecting an exchange, establishing an account/signing a transaction, handling transfers (or cleaning up cryptocurrency dust in your wallet), etc. You just need to submit an intent document stating that you want to exchange 1 ETH for 2000 USDT. Another entity (called Solver) will accept your intent and find a way to implement it. The Solver will handle the messy details and strive to optimize the best outcome for you.

The key is that intent focuses on the result rather than the process. Users define the desired result, and others implement it through the process. Intent allows you to specify the result without worrying about the steps, greatly simplifying the transaction process used by most users in cryptocurrencies.

A higher-level idea is that users can define what they want without specifying which contracts they want to start trading with (we can call it a computation path or a simple trading path). Users can also indicate their preference for certain paths or contracts, thereby restricting them.

Use Cases

Cowswap

Cowswap uses batch auctions as its core price discovery mechanism. Cowswap does not execute transactions immediately like AMMs, but aggregates orders off-chain and settles them in batches. This allows for a unified settlement price for all transactions in a batch, eliminating the issues of front-running and other problems commonly seen in immediate execution modes. Batch auctions also enable the settlement of many transactions at the same time, optimizing gas fees.Solvers openly compete with each other and submit order settlement solutions to ensure that the parties to each batch of transactions maximize their benefits. The best solution determines the final unified price. Overall, batch auctions achieve fairness, efficiency, and MEV protection, which immediate execution modes cannot achieve.

One key innovation of Cowswap’s batch auction mode is the ability to find coincidences of wants (CoW) between orders. CoW is the direct peer-to-peer settlement between transactions with reciprocal needs. This liquidity sharing means that there is no need for external liquidity providers to facilitate these transactions. CoW can also include multiple assets in a circular transaction. By maximizing CoW, batch auctions can achieve more liquidity than isolated liquidity pools. Settlement will utilize CoW whenever possible, with the remaining portion executed through on-chain liquidity. By combining batch auctions with CoW liquidity sharing, traders can benefit from better pricing and execution.

The Cowswap model is similar to the intent model, where users express their trading intentions in the form of limit orders. These intentions are input into the order book, and the Solver matches them in the form of circular transactions or routes them through AMM (Automated Market Maker) (where users only specify the price without specifying the calculation path or the specific location they want to execute).

Uniswap X

The Uniswap X paper proposes a decentralized trading protocol that uses signed off-chain orders and settles them on-chain through Dutch auctions. Users sign orders specifying input/output tokens, quantities, price limits, and other parameters. 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 inquiry system. Users can inquire with the Filler network and provide a brief exclusive period for the best quote to incentivize honest pricing, after which the orders enter a public Dutch auction.

Similarities between Uniswap X and Cowswap

• Both use signed off-chain orders and settle them in batches on-chain, which can save gas fees compared to on-chain orders.
• Both aim to facilitate competition among liquidity providers to find the best execution prices (liquidity providers are called Solvers in Cowswap and Fillers in Uniswap X).
• Cowswap emphasizes using CoW to drive direct peer-to-peer transactions, while Uniswap X focuses more on integrating off-chain and on-chain sources of liquidity.
• The RFQ (Request for Quote) system and signing pattern (users expressing their intentions and having others fill the orders) in Uniswap X are similar to the intent architecture.

Formal Definition of Intent

Users only need to express their intent, such as “I want to swap X asset for Y asset,” and the Solver will determine how to achieve that intent in the best way and handle all blockchain-related details behind the scenes. The Solver provides proof of intent achieved, which can participate in auction mechanisms to achieve 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 set of supported “start” states.
• E represents the set of supported “end” states.
• T is a set of preferred transaction sequences.
• The state transition function s: Q×T → T moves from the initial state to the end state through a series of transactions t.

If an intent starts with transaction sequence t ∈ T from state q0 ∈ B and ends in state qn ∈ E, the intent is considered fulfilled.

Intent Clearing: If there is a non-empty intersection between the sets B, E, and T, a group of intents can be cleared to allow the creation of a meta-intent t’ using these intersections.

As mentioned earlier, intents are issued by users and then resolved by Solvers; regardless of how they are represented, intents are optimization problems for Solvers. In simple terms, a user may present an intent such as “I want to buy BTC worth 4 ETH”, and the Solver would typically find a place to fill or exchange this order. But intents go beyond that; they also allow for additional constraints such as “lowest possible slippage” and “no trading on DEX that prohibits US users”, which become extra constraints that Solvers must keep in mind.

Challenges include:

• The need to simplify intent expressions.
• Specific intents may have an impact on user welfare, such as zero slippage in DEX.
• Execution tracking may need to be focused on due to risks or legal reasons.

The goal is to strike a balance between capturing user intent preferences clearly and considering computational efficiency and user experience.

Lagrangian interpretation of intent search is also mentioned here.

For me, the expression of intent looks like a Markov Decision Process. However, in a Markov Decision Process, state transitions are random, while this would be a deterministic MDP with absolute state transition values, which can be solved using value iteration, policy iteration, or MCTS (Monte Carlo Tree Search) (the latter also used to solve the Go portion of AlphaGo).

Intents can enhance user experience

Intents may be the next stage of development for on-chain user experience. Currently, on-chain user experience revolves mainly around the transaction level, where users sign on each transaction, which is also part of the operation. Therefore, each step on-chain is expressed through transactions.In simple terms, an intent is a meta-transaction where activities are expressed at a very abstract level, and the Solver tries its best to fulfill the user’s intent requirements. This may include buying some ETH at the price of X, wanting to get the best possible trade, which can be done in the form of a single large swap trade on Uniswap on Ethereum, or in a roll-up by splitting and then buying ETH (also considering fees).

Currently, a simple swap trade from USDC to ETH involves the user approving token allowances, approving token types, and then approving the trade. In an intent-driven world, users can abstract away from these details and simply execute the desired operation. In web design, there is an unofficial rule that no action should require more than three clicks; currently, if a user wants to make a swap trade, they have to select tokens simultaneously, perhaps adjust slippage and trade, which may not seem like much work for one trade, but it becomes cumbersome with multiple repetitions, leading to a frustrating user experience.

Unibot has presented a pattern for intent-based architecture in a very basic way. It eliminates the complex parts of transactions and provides traders with a simple and user-friendly experience, but it also has some limitations on potential flexibility. Despite the claimed risks in key handling that may lead to attacks, it still has a stable user base with tax fees, indicating that there are opportunities to be explored in user experience in the cryptocurrency world.

Conversational intent flow

In the intent-centric blockchain world, how should AI be involved? The concept of intent recognition has existed in the field of natural language processing for decades and has been extensively researched in conversations. For example, suppose a user visits a travel website and interacts with a chatbot; initially, they may want to book a flight or check a booking or status, and then the user will provide various details. If it is booking a flight, the user needs to provide the destination, time, date, and the interested ticket class; in some cases, the user may also need to choose an airport. In this example, the user’s intention is the intent of the conversation, and the various details provided by the user are the slots to be filled for achieving this intention.

Annotated conversation status in the conversation

Another example of intent recognition and slot filling is when you intend to play a song, various slots related to the song will appear in the sentence, such as the song name and the singer.

In the world of conversations, intent classification and slot filling are very complex problems because your conversation may span multiple turns, sometimes with global intents and local intents, and you have to track numerous states. Whenever you use Siri and 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? When we transition from a transaction-centric world to an intent-centric world, the discussion about how to go from intent to transaction details has not yet emerged in the mainstream.There is no interface between the intent pool and the memory pool. Accessing on-chain models and using them for intent recognition and slot filling provides a natural language interface to the intent pool and Solver (in my opinion, this is the most natural interface).

The general idea is to access a set of models on-chain and translate each intent into a DSL (domain-specific language); this DSL will include core intents (buy, sell, bridge, borrow/lend), as well as other details such as address, size, slippage preference, etc. (depending on the intent type). The global DSL allows anyone to deploy models and simplify intents into specific DSLs. In the case of multiple such models, the model voted in the model collection will be used.

The availability of on-chain models helps us develop this interface securely and verifiably, and the computational proof for each intention/solution can be proven. In some cases, capturing the results of the majority vote of various models can help us gain a deeper understanding of how intentions are selected, and in some individual cases, it can even help the Solver to better solve these intentions.

The on-chain model used here can be a standard deep learning model, such as BERT, which is specifically trained for this purpose, or a large language model used for inference in a collection. This detail may depend on different participants or Solvers. In the case of encrypted intention pools, homomorphic encryption or private inference methods need to be used to ensure data privacy while still being able to compute on it. A proof can be published on the model’s chain by the validators every epoch or every few epochs. Validators can be humans or another model, and they can issue statements about the validity of the model. Whether the model can accurately process intentions or not, this part of the process can ensure the consideration of the model’s lifecycle. Sometimes, when the validator is a mature participant, they may discover defects in the model, which can be quickly addressed and replaced with an updated model.

As shown in the diagram below, for the action/idea of “purchasing with stablecoins and dust in my wallet”, once it enters the intention pool, it will be processed by various models and parsed into a DSL that includes various details such as intentions, sub-actions, and details to be filled in. The parsing of the DSL can be as detailed as possible or as abstract as possible; the intention dialogue may last for several rounds as the threshold for dust needs 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 intention-solving model

Another DSL Architecture – Essential

The account abstraction turns all accounts into smart contracts, separating accounts from signers in Ethereum. This allows accounts to have different authorization logic customized according to user needs. However, achieving complete account abstraction requires significant adjustments to the core protocol of Ethereum.

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 the alternate memory pool and bundled by “bundlers” into transactions that call the EntryPoint smart contract.

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

The intent allows users to specify an expected result instead of a specific operation. Then, the Solver helps users achieve this result in the best way possible. However, the current implementation has limitations, exhibiting centralization, lack of composability, and insufficient competition among Solvers.

A proposed EIP plan by Essential aims to change this situation. By abstracting accounts through measures like EIP 4337, it is possible to achieve contract-based accounts instead of traditional Externally Owned Accounts (EOA). This allows users to submit general intents without the need for simple transactions. Intents represent the desired results 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 to constantly upgrade smart contract wallets. Users sign “user intents” to specify which “intent standard” contract should handle the intent. These intents are submitted to the EntryPoint contract, which handles signature verification similar to EIP 4337. The user intent memory pool coexists with the ERC 4337 memory pool, and Solvers handle intents.

User intent under ERC-4337 account abstraction

Anoma

Anoma is an intent-centered architecture that builds the infrastructure layer based on programming intents rather than transactions. Intents are partially state changes that express user preferences, rather than complete state-changing transactions. This intent-centered design achieves decentralized discovery and resolution of transaction counterparts. Anoma is attempting to transition from a declarative paradigm to an imperative paradigm.

Excerpt from Adrian Brink's speech on intent-centered applications

Users broadcast intents, which are propagated in the intent gossip network. Different nodes can specifically propagate certain intents based on their computational resources and the types of intents they want to serve. Solvers observe intents and attempt to combine compatible intents into valid transactions that can be settled on-chain. Transactions are submitted to the encrypted memory pool using threshold encryption, preventing frontrunning. Anoma also has a partial intent model that allows intent composition.

Chris's speech on intent x Rollup - Anoma partial intent model

Anoma’s focus on privacy is on “user-level choice,” allowing users to flexibly disclose their intent information and choose which parts to disclose.

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

The architecture has both homogeneous protocols and heterogeneous security models. It can be deployed as an independent blockchain or used as a ZK roll-up or decentralized order book to achieve decentralized distribution of applications on Ethereum. Users with different security requirements can use the same protocol and make security trade-offs according to their needs.

Compared to transaction-centric patterns, Anoma makes it easier to build decentralized applications. It intends to support new applications such as running rollups, multi-token trading, and private DAOs. In short, Anoma provides a flexible modular architecture that meets the requirements of modern decentralized applications. It focuses on intent rather than transactions, solving the problems of counterparty discovery and coordination while protecting privacy.

Anoma has a unique design concept, treating intent as “information flow” and “restricted/privacy-enabled information flow,” and making architectural and design choices based on this. This also illustrates the fact that Anoma’s intent composition model brings about a broad intent model, which may be technically challenging to solve under privacy constraints because trade-offs in efficiency restrict the amount of information that can be kept confidential.

Summary

Intent is currently a very interesting area in the field of cryptographic technology, both in terms of research and engineering.

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

• Formal definition of intent
• What does an intent-centric application architecture look like, apart from DEX?
• When solving any optimization problem, the design trade-off between privacy and utility requires obtaining as much information as possible. If intent with privacy is to be achieved, a certain amount of information must be disclosed to solve the intent problem.
• What is the basic knowledge required to solve intent problems?
• If the path to acquiring other knowledge needs to be cut off, what trade-offs do you have to make?
• How to express the trade-off between privacy and efficiency in a general way.

A general intent may be too extensive to solve, and for a large state space like Ethereum, it can become an unsolvable problem. This suggests that it is best to have some constraints when solving intent problems, and there should also be limitations when attempting to combine intents (when there are common intents). In my opinion, a intent-centric architecture will be application-oriented in nature.

Although these are research problems, the design choices for implementing intent will also generate various engineering problems. It may lead to excessive reliance on (licensed) intermediaries, which may result in infrastructure being concentrated in different stacks (in the case of UniswapX, 77% of trading volume is off-chain inventory filling). It also consolidates the status of trusted intermediaries, increases the barriers to participation, and stifles innovation, as already demonstrated in MEV. Any design of an intent protocol must strike a balance between permissionlessness, privacy, transparency, and decentralization.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!