Intent System: A Potential Solution to DeFi Complexity

Before the Luna crash, I managed a stablecoin yield strategy for a friend, aiming to replicate the high yield rates of January 2020. This friend had limited knowledge of cryptocurrency, and our collaboration model involved him depositing funds into a hardware wallet, after which we held regular video conferences, and I gradually guided him through the operations.

We distribute funds across various blockchain DeFi protocols. Each meeting lasts 2-4 hours and involves a large number of operations such as approvals, transfers, exchanges, deposits, withdrawals, and claims. Funds are allocated to customized Uniswap liquidity pools, Curve lock-ups, and several other projects to maximize returns. We have used almost all mainstream cross-chain bridges, decentralized exchanges, and yield aggregators.

This process is very challenging for my friend. I need to explain each step in detail, and he needs to familiarize himself with the interfaces of various complex Decentralized Finance tools. Our communication is filled with instructions like "click here", "go there", "swap this".

Taking the exchange of USDC for FRAX/DAI liquidity provision on Polygon as an example, the entire process requires 12 transactions:

1. Exchange USDC for DAI on a DEX (2 transactions)
2. Cross-chain USDC and DAI to Polygon (4 transactions)
3. Merge USDC and DAI on a certain DEX on Polygon (4 transactions)
4. Deposit LP tokens into the yield pool (2 transactions)

This seemingly simple operation is actually very cumbersome, especially when managing a large-scale portfolio.

From a more macro perspective, all the operations we perform have a clear goal. For example, "We have USDC on Ethereum and want to provide FRAX/DAI liquidity on Polygon and stake it." This is the "content" of our operation, while the 12 specific transactions are the "how" of the operation. A series of logically clear steps are needed from the starting point to the end.

If there is a powerful trading routing algorithm, this process can be simplified to 1-2 steps. Users only need to specify the desired outcome, and the algorithm can provide the best path, even directly processing the transaction. This path mapping structure is referred to as "intention" and is part of the rapidly evolving middleware future of Ethereum.

Although there is no consensus in the industry on the definition of "intent", there are some common viewpoints. One definition is: "Intent is a signed set of declarative constraints that allows users to outsource the creation of transactions to third parties while maintaining full control over the transactions." Another definition is: "Transactions are imperative, while intents are declarative. Transactions specify how to run the EVM to produce state changes, while intents specify the desired state changes without focusing on the specific implementation process."

Both definitions emphasize the "declarative" nature of intent, which seeks external help through data sharing between the user and the "solver". Users declare the outcomes they desire, and the solver provides the means to achieve them. Unlike transactions with specific parameters, intent requires third-party mapping. Additionally, there are constraints that limit the possible set of paths, helping to narrow down the range of choices to a manageable scale.

In the case of my friend, the intent system allows us to broadcast the final goal to a group of solvers, which calculate the optimal path. We can choose the price-optimal solution and execute the trade. All intermediate steps are handled by the solvers, and the user only needs to confirm 1-2 transactions.

The basic architecture based on "intention" already exists in the EVM. When you use a decentralized exchange, it automatically finds the best trading path. For example, on certain trading platforms, after selecting to buy or sell an asset, the interface automatically finds the best liquidity pool for routing. If there is no direct trading pair, the order will go through multiple liquidity pools to achieve the best execution path, all completed in one transaction.

This trading intent on the trading platform is just a basic example. The interface helps build the logic for the exchange trade, while the intent is to share the expected outcome (to acquire the maximum amount of the target token) and constraints (to sell only a specific amount of the source token). It is up to the solver to determine the best exchange rate.

If you have used certain trading aggregators, you will see an intent system used for building exchange transactions. Users provide execution parameters and then receive a set of potential transaction relayers. Depending on the relayers, transactions may have different fees and gas costs. Ultimately, the user selects the best price/cost combination.

In addition to trading aggregators, there are several other types of "intents" on Ethereum:

1. Limit Order: Allows assets to be withdrawn from the account if conditions are met.
2. Third-party order execution based on non-DEX liquidity.
3. Gas Sponsorship: Allows the use of specific tokens to execute third-party transactions, applicable to account abstraction wallets.
4. Delegation: The whitelist belongs to this situation, checking the database before executing the transaction.
5. Transaction batch processing: Allows for batching of intentions for Gas efficiency.
6. Cross-chain exchange.

Although the types of orders are becoming increasingly diverse, the simplest way to describe the intention might be "an upgraded version of limit orders." A limit order specifies the desired price to purchase a specific quantity of an asset, and it is executed only after the other party accepts the order.

Similar to limit orders, intentions consist of two parts: the desired final state of the user and the transaction initiated by the solver. By combining these two parts, all the necessary elements for executing the transaction can be obtained.

The design method of intent architecture carries almost no risk. Firstly, solvers are motivated not to propagate intents that contain profitable MEV. In many cases, the extraction of MEV requires executing users' orders on-chain, which exposes the blockchain state, allowing extractors to profit from that state. Backrunning and sandwich trading are common examples.

The core feature of intent is data exposure. Signing an intent message indicates that the user is willing to extract MEV at the cost of convenience. Since intents cannot be directly broadcast to the Ethereum mempool, they are stored in private off-chain intent pools. These intent pools can be permissioned, permissionless, or a mix of both.

The permissionless intention pool utilizes a decentralized API, allowing nodes within the system to freely share intentions and grant executors unrestricted access. For example, certain protocol relays and proposed shared memory pools. Open memory pools are susceptible to DDOS attacks and are difficult to prevent the spread of malicious intentions.

In contrast, the permissioned intent pool uses trusted APIs, can resist DDoS attacks, and does not require intent propagation. By relying on trusted intermediaries, as long as trust is maintained, they can guarantee execution quality. However, this method still relies on a strong trust assumption, which undermines the core spirit of open blockchains.

Hybrid solutions attempt to bridge the gap between permissioned and permissionless systems. They may combine permissioned dissemination with permissionless execution, or vice versa. Certain order flow auctions use trusted parties (off-chain order matching) to operate the auctions, but participation is permissionless.

The most popular intention pools currently are centralized and permissioned, with no incentives to share information with competitors. The risk here is that one party absorbs most of the intention-based transactions and begins to introduce fees and other rent-seeking behaviors due to its monopoly position, while users with negotiating power have disappeared into the hands of exploitative intermediaries.

When considering intent as a limit order, we can compare it to the order flow payment (PFOF) from certain stock trading platforms. These platforms offer users "free" trading, based on the premise that users can sell their order flow instead of sending it to traditional exchanges. Market makers provide this payment because they can profit from the bid-ask spread of the orders. Critics argue that this practice presents a conflict of interest. While brokers are obligated to provide best execution for their clients' orders, the monetary incentives of PFOF are said to influence their decisions on where to send the orders.

The intention is a form of PFOF arbitrage, which we refer to as MEV. Arbitrage opportunities created by long-standing open orders may be more valuable than trades manually added to the Ethereum mempool, as solvers can determine the route rather than competing for pre- or post-trade MEV in a given block with sandwich trades.

Unchecked and opaque solvers are very likely to provide the worst routes, as their profit margins are inversely proportional to good execution. Users still need to choose solvers, and they can leverage this negotiating power to force solvers to bid against each other for order flow. The solver that brings the highest return to users under the constraints wins the auction.

Some protocols adopt this design, using batch auctions to find the best settlement price for traders. Orders are not executed immediately but are collected and settled in batches. The system uses public competition among solvers to match orders. Once the batch ends, these solvers submit solutions for settling the orders.

Batch auctions allow transactions within a batch to have the same price, thus eliminating the need for miners to rearrange transactions. There are no front-running or back-running. This method uses order flow auctions to ensure that traders receive the best price execution. However, there is also some MEV in these orders, as market makers must be able to perform arbitrage trades in another venue to remain profitable.

Currently, some protocols are developing intent-based infrastructure to allow for hybrid systems. Certain projects are building private mem Pools and block building networks to direct traffic to L2 and Ethereum. There are also some projects attempting to build the next generation of completely permissionless infrastructure.

Although there is still no consensus on who the intended winner is, this is a growing part of the emerging middleware layer revolution happening in the crypto space today, which is necessary for convenience. The "keep it as is" crypto UI is not user-friendly enough for broader adoption. The current intentions are often used for token swaps and order batching, but the goal is to make them applicable to completely generic data and arbitrary data.

This opens up new possibilities for building on certain emerging public chains, as all wallets may default to account abstraction. A powerful intent layer can unlock new use cases for products on these emerging public chains and simplify the applications built on them.