In-depth Intent Narrative (I): The Current and Future State of Intent in Web3

Original authors: Mike Calvanese, Brink

Compiled by: Deep Tide TechFlow

This article is the first part of a three-part series written by Mike Calvanese and the Brink team about intent narratives.

Intent narratives are rapidly gaining traction. They are one of the many user experience improvements achieved through account abstraction, another hot topic discussed by Vitalik at EthCC. Intent allows users to define the outcomes they expect to achieve on-chain and outsource the work of achieving those outcomes to third-party solvers, who interact directly with the network and protocols on behalf of the users. Ultimately, this layer of abstraction will make Web3 applications feel like regular applications. It reduces the current technical learning curve and will help us attract millions of new users.

The shift towards the intent paradigm means that future users will not need to worry about technical tasks such as submitting transactions, using ETH to pay gas fees, mitigating MEV on AMMs by setting slippage limits, aggregating token swaps for optimal path routing, or cross-chain asset transfers between networks.

A simple way to understand intent is to view it as expressing what the user wants to happen in a declarative form, rather than detailing how things should happen in imperative steps.

Current Intents

Intent is not a new concept. Before the emergence of Uniswap and AMMs, Ethereum projects like EtherDelta and 0x provided intent-based order books. NFT marketplaces have been using signed intents for NFT listings and bids for years. New systems like CoW Swap and Uniswap X now provide more advanced intent-based infrastructure for ERC20 limit orders. From the current situation, the term "intent" may seem synonymous with "limit order," as the widely supported intent in today's Web3 is simply "I want X, and I am willing to pay Y."

The intent architecture for limit orders is typically simple and focused on a single purpose: the intent to exchange at a better price. Users sign their limit order intents, and solvers look for paths to "fill" the signed intents, which can use AMMs, other liquidity sources, or, in some cases, other intents. Solvers are incentivized to perform pathfinding because they can retain any excess profits once the user's intent is fulfilled.

Many systems have been built to support the use case of limit orders, but as more advanced intent-based tools are developed, we will begin to see more generalized architectures to support more powerful use cases.

Examples of generalized intent systems include Anoma and Flashbots SUAVE, which are actively being developed. They will provide an intent propagation layer where users can broadcast signed intents to propagation nodes. These will be chains of specific intents that facilitate the connection between users signing intents and solvers executing intents across different networks.

Another example is Brink, a solution for creating composable intents. Brink allows users and developers to build, sign, and solve intents across multiple EVM-compatible networks based on conditional states.

The Future of Intents

Let’s explore how Web3 intents can evolve beyond simple limit orders. Here are some new concepts:

• Conditional Intents: Execute an action when one or more conditions are met.
• Continuous Intents: Express a need for repetitive actions.
• Multi-step Intents: Open one or more new intents after one intent is resolved.
• Intent Graphs: Paths formed by a set of related intents.

Conditional Intents

Current Web3 applications only have one type of conditional intent: limit orders. In the future, we will have intents that can combine any number of conditions with any state, leading to any action.

If you are a Web3 user, you have likely made many conditional decisions in the past. These decisions can be expressed as intents, signed, and delegated to third-party solvers. Here are some examples:

• Price Threshold: "If the A/B price drops below X, swap B for A." In traditional finance, this is known as a "stop-loss."

• Governance Decision: "If a governance proposal I do not support passes, sell token A."

• Wallet Balance: "If my hot wallet's ETH is insufficient, transfer more ETH from my cold wallet to my hot wallet."

• Time/Block: "If more than X blocks have been mined, transfer ETH to a recipient address."

All of these can be signed as a single intent. Once the conditions are met, the solver will monitor these intents and act on behalf of the user. If the user signs these conditions as part of the intent, the solver will prove the conditions through some on-chain state checks.

Intents can contain any number of conditions. For example:

• "When 1) the ETH price is below $1750, 2) the average DAI yield for borrowing ETH is high, and 3) a whale wallet I am watching has purchased at least 10 ETH in the past 24 hours, I want to buy 2 ETH with DAI."

Users will be able to express their willingness to buy, sell, stake, transfer, or cross-chain assets when any number of complex state conditions are met. All of this can be done with a single signed intent.

Continuous Intents

Intents will provide a way to execute continuous operations independent of the protocol. While current intents typically involve a single signature corresponding to a single operation (limit orders), we will soon see the emergence of continuous intents.

Users today perform continuous operations by depositing funds into protocols or exchanges. Here are some examples:

• Dollar-Cost Averaging: "Every month, buy ETH at market price with DAI." Users typically use centralized exchanges like Coinbase to accomplish this.

• Yield Compounding (also known as Re-staking): "Withdraw rewards from token A, swap for token B, and re-stake." This is a cumbersome process involving multiple transactions and interactions with various DeFi protocols.

• Hot Wallet Replenishment: "I have a cold wallet with 50 ETH. Whenever my hot wallet's ETH balance is below X, transfer Y ETH from my cold wallet to my hot wallet." This also requires many separate transactions.

• Payment Streams: "Transfer X USDC to a recipient address every two weeks." Streaming payment applications support this, but require users to deposit assets into a smart contract.

• Market Making: Based on AMM, LP positions essentially follow an infinite loop of two reverse swaps: "If the A/B price exceeds X, swap A for B; if the A/B price falls below X, swap B for A."

From these examples, it is clear that current continuous operations require users to deposit funds into specific protocols and submit many transactions. With intents, users can express their desired continuous operations with a single signature.

Dollar-cost averaging is a perfect example. A user intending to dollar-cost average (repeatedly buy or sell over time) can express it as a signed intent, allowing for a price provided by a non-manipulable ETH/DAI TWAP oracle, swapping 1 ETH for DAI every 50,000 blocks (approximately once a week on the Ethereum mainnet) with a fee of 1% (0.01 ETH). The solver will monitor this intent and check the following:

1. Does the user's account have 1 ETH to swap?
2. Have 50,000 blocks been mined since the last swap?
3. Is 1% (0.01 ETH) enough to cover the gas fees for the swap?
4. After the solver pays the gas fees, is there enough ETH left to cover the solver's operational costs, which may include the risk of rollbacks after losing PGA (Priority Gas Auction) or any other fees? Is the potential profit worth it for the solver?

If all these checks pass, the solver will send a transaction to fulfill the user's intent to swap ETH → DAI. As long as the user's account has enough ETH, a single signed intent for "cost averaging" can be monitored by the solver and generate a series of continuous transactions. Users can get what they want without directly interacting with the EVM network or specific protocols.

Using intents for market making is another example of a continuous and potentially infinite action that can be delegated to solvers. A user wanting to market make ETH/DAI can create an intent that allows for DAI → ETH swaps at a price of 1,800 ETH/DAI or lower, and ETH → DAI swaps at a price of 2,000 ETH/DAI or higher. Through this intent, the user attempts to lock in a profit of 200 DAI while the market fluctuates between the prices of 1,800 and 2,000 ETH/DAI.

Think of it as two inverted limit orders, where one opens when the other is filled, and vice versa. The user can sign a single intent to swap at each price point. As long as the market continues to fluctuate between these price points, the solver can theoretically fill an infinite number of these orders without any action required from the user.

Multi-step Intents

Intents can consist of multiple steps. These intents can be viewed as state machines, where each transaction transitions from the previous state to a new state. The new state we transition to depends on the conditions defined by the previous state.

A simple example of multi-step intents is the classic trading finance (trad-fi) Bracket Order. Their complexity can vary, but simple versions are typically found in trading finance applications. With the composability of Web3 and multi-step intents, we can create very powerful Bracket Orders.

A Web3 Bracket Order intent can be expressed as follows: "I want 1 ETH and am willing to pay 1,800 DAI. Once I pay 1,800 DAI and have 1 ETH, I am willing to hold this 1 ETH until I can sell it for 2,000 DAI. If the ETH/DAI price drops below 1,620 DAI, I want to minimize my losses by selling this 1 ETH, in which case I will accept 1,600 DAI and pay the solver a fee of 20 DAI. If I still hold this 1 ETH when [random governance proposal] passes, I want to sell this 1 ETH at any price given by the ETH/DAI market and give 10% of the sale proceeds to the solver."

This is a relatively simple three-step order with some conditional triggers, but as you can imagine, these types of orders can become much more complex.

Intent Graphs

The relationships between user intents can form intent graphs. These graphs represent groupings of conditions and actions defined by the user that lead to swaps, asset transfers, or other on-chain operations. All previous intent examples are essentially names for specific graphical arrangements.

Just as limit order books represent the current state of market liquidity, intent graphs can represent not only the current state but also the conditions of liquidity under many different potential future states.

Consider an example: in a fictional market, users trade XYZ and ETH, expressing intents to buy and sell XYZ under various conditions, such as governance proposal outcomes, specific block mining, increases and decreases in market prices, or whether other intents have been fulfilled.

Conclusion

Intents are making progress, with new developments emerging every day. Here are some useful resources:

• Interpreting Intents: Revolutionizing Web3 User Experience and Order Flow in Blockchain;

• Intent-based Architecture and Its Risks;

• SUAVE, Anoma, Shared Sorters, and Super Builders.