Decoding Intents: Revolutionizing Web3 User Experience and Orderflow in Blockchain

by Grace Deng , SevenX Ventures Research

Special thanks to Liesl and Simon from Essential, George from Flashbots, Anna and Alex from Cow Swap and Josh from Astria for incredibly valuable discussions, insights and feedback of this article.

Introduction

As web3 technology moves towards mass adoption, it is essential to ensure that users are able to navigate the complexities of the web3 jungle on their own. Unlike the early days of blockchain, where users had to decipher intricate technicalities, the future lies in providing a user experience that guides and empowers users to interact seamlessly with decentralized systems. Taking cues from the evolution of web2, where user needs became increasingly expressive through search engines and chatbots like ChatGPT, web3 must deliver an easy-to-use yet powerful user experience.

Intent-driven interactions become the foundation of a user-friendly web3 experience. Although there are a bunch of definitions of intents, I prefer to break down intents into 3 pairs of keywords:

• Outcome instead of path： users only need to express what they want and don't care about how the outcome is achieved

• Conditional Authorization instead of Code Authorization: when a user signs a blockchain tx, they are authorizing codes within the transaction the ability to execute arbitrary computations, modifying the state of the blockchain. In contrast, when a user approves an intent, they are authorizing releasing their assets and tips after being guaranteed that their desired outcome has been achieved (kind of like cash on delivery in online shopping)

• Competitive solver landscape instead of trusted dapps: In a tx-dominated world, users interact with the dapps they choose, and the dapps would act as the service provider to return the desired result, which is usually long-run and mainstream dapps like Uniswap. In an intent-dominated world, well-known or unknown solvers from both offchain and onchain can compete to achieve the intent for the user and get the bonus. From the principle of economy, more competition leads to more efficiency.

To sum up, users can express their intent clearly and directly; platforms can leverage solvers and executors to find the best execution path to fulfill user goals. Just as in web2, where black boxes work behind the scenes to optimize results, web3 executors can utilize algorithms and automated processes to handle the complexities of execution, ensuring that users receive the desired outcomes efficiently and get paid.

By prioritizing user experience and focusing on expressive intent, web3 can usher in a new era where the power and potential of decentralized systems are accessible to all. The future of web3 lies in democratizing access, simplifying interactions, and delivering seamless user experiences that guide and extract users from the execution complexity through the decentralized landscape.

Exploring Different Types of Intent Implementation

Various types of intents can exist based on their generalization, as shown below;

In fact, different levels of intents are everywhere because blockchain codes = sort of automation = extract away some complexity and return the desired outcome to users. However, we want the most general intent in the future, as AA+ intent-specific apps are not enough because they aren't functional in cross-domain and don't scale as effectively as intents with a more permissionless nature.

To understand how intent works, we can look at the currently available solutions, starting from intent-specific apps to general intent infrastructure like Anoma and SUAVE. The analysis would break down into 5 main parts with different questions to bear in mind:

• Intent Expression and Authorization: How do users input their intents; what type of intents and what level of intents can users express; what authorization do users give?

• Solver Candidates: Is it permissioned or permissionless? Are there high barriers to becoming a solver? Are there different types of solvers focusing on other specific areas？

• Solving Process: What's the main path to solving the solution; What determines the completion of the intents?

• Solver Selection: what's the rule for selecting the winner from several solver candidates? Will the competition pattern be winner-takes-all or discrete?

• Validation and Settlement: How to check whether the solver has completed the task? How do the settlement between users and solvers?

Here's a comprehensive overview of the current solutions. For more detailed information, delve into the remaining section.

Cow Swap 1inch fusion（limit order intent）

• Intent Expression and Authorization: 

  • Traders on the Cow Swap and 1inch Fusion platforms express their intents by interacting with the platform's interfaces, providing clear instructions for the desired trades or limit orders. 

  • In terms of authorization, traders sign off-chain messages or transactions to grant permission. They pay fees in the traded tokens instead of ETH for gas and have no cost if the trade doesn't execute.

• Solver Candidates:

  • In the case of 1inch Fusion, the solvers, known as resolvers, operate in a permissioned manner. They are required to register, undergo KYC processes, and maintain a sufficient balance to cover the order fee. 

  • On the other hand, Cow Swap's solvers are either whitelisted by creating a bonding pool of 1M$ (USDC COW) or being included in the CoW DAO bonding pool or the Gnosis DAO Bonding pool and being whitelisted by the Cow DAO based on the DAO's criteria.

• Solving Process: 

  •  Solvers evaluate the existing batch to identify any coincidence of wants (CoW) that can provide the best price for executing the trades or limit orders. They consider various factors such as liquidity, order book depth, and price slippage to ensure the best execution for the traders. 

  • Additionally, solvers may explore other underlying on-chain automated market makers (AMMs) directly, such as Uniswap, or leverage DEX aggregators like 1inch to find the most favourable prices and routes.

• Solver Selection: 

  • In Cow Swap, traders are executed at the best possible price determined by any external solvers using a batch auction, maximizing trader surplus. The solver providing the most optimal solution is selected.

  • In contrast, the resolver competition in 1inch Fusion is more restricted and related to the 1inch token staked using a Dutch auction.

• Validation and Settlement: 

  • The validation and settlement process occurs after the solvers execute the trades or limit orders. Solvers can move tokens on behalf of the users, utilizing the ERC20 approvals granted to the settlement contract. The settlement contract verifies the signature of the user's intent and ensures that the execution aligns with the specified limit price and quantity (enabled by EIP-1271). This validation confirms the successful completion of the intended trades or limit orders.

  • Once validated, the settlement contract facilitates the appropriate allocation of funds to the solvers and users involved in the transactions.

Recently, Cow Swap just announced the launch of Cow Swap Hooks, which enable the execution of more generalized swap intents by enabling custom-coded DeFi actions that execute directly before and/or after trades. It's great to see Uniswap v4 and Cow Swap are pushing their boundaries to more generalized intent activities and bringing us a new world of defi intents!

UniswapX（Swap Intents)

UniswapX's new features can be divided into 2 main parts: 

• Signed orders with a Dutch auction mechanism 

• Cross-chain Swaps

The signed orders with the Dutch auction are similar to 1inch Fusion and Cow Swap's limit order intents with the following differences:

• Intent Expression and Authorization: users have more freedom (also might bring more complexity) to define parameters, including the decay function for the auction, the initial Dutch order price, etc.

• Solver Candidates: permissionless instead of permissioned (can also be set permissioned by users); 

• Solver Selection: 

  • Dutch order which executes at a price that depends on the time of its inclusion in a block. The order starts at a price estimated to be better for the swapper than the current market price — for example, if the current market price is 1,000 USDC per ETH, a sell order may start at 1,050 USDC per ETH. The order’s price then decays until it hits the worst price the swapper would accept (e.g. 995 USDC per ETH). Fillers are incentivized to fill an order as soon as it is profitable for them to do so. If they wait too long, they risk losing the order to another filler willing to take a smaller profit.

  • UniswapX also enables including RFQ (allows orders to specify a filler that receives the exclusive right to fill the order for a brief duration) for initial Dutch price setting, in which case the selection process would be almost the same as 1inch Fusion's auction method.

  • Cow Swap is more of a batch auction compared to UniswapX and 1inch's independent auction, which enables combining orders and matching CoWs.

• Solving Process and Validation and Settlement are similar to Cow Swap and 1inch (more details are shown in the chart)

Cross-chain swaps can be achieved through similar processes with main differences in validation and settlement to enable multi-domain swaps:

• Solvers need to deposit more bond assets on the original chain to ensure safety and enable optimistic cross-chain protocols

• Needs an additional settlement oracle to feed into the origin chain's validation contract

• Needs UniswapX to deploy corresponding settle and validation contracts on different domains

Account Abstraction (Wallet-level Intent)

• Intent Expression and Authorization: 

  • The process of intent expression and authorization begins when a wallet owner wants to perform a specific action. They craft a userop, typically through a 4337 wallet interface, to express their intent. 

  • Off-chain, the wallet owner requests a bundler to handle the userop on their behalf, authorizing limited control according to the intent. For example, the wallet owner may authorize the private key to be able to transact from your main account, but ONLY with Dapp XYZ's hub contract.

• Solver Candidates:

  • Bundler services are considered public goods in the AA framework. The majority of Bundlers are open-source, which makes them non-excludable and non-competitive. Any RPC endpoint can replicate the open-source code and operate as a Bundler. Even when a Bundler RPC endpoint charges fees for its services, it can do so through API keys while still maintaining the non-excludable nature of the Bundler as a public good.

  • Two main types of bundlers: Bundler services purpose-built for wallets, catering to their basic needs third-party infrastructure providers aiming to construct permissionless and modular Bundlers 

• Solving Process: 

  • Bundlers simulate the wallet's validateOp method on the userop to determine whether to accept or reject it offchain. Then, they send the transactions to the entry point of the AA system to call the handleOp method. This process also involves bundling multiple userops together to optimize gas and extract MEV. 

  • The entry points contract would push the operation on the chain, and the chain node would validate the operation and get it into consensus.

• Solver Selection: 

  • The selection of solvers in AA depends on various factors. The wallet used by the account owner might provide bundler service or use third-party infra, and users might also switch rpc endpoint to select a favoured bundler, in which case the success rate and reputation of the bundlers may influence their selection. 

• Validation and Settlement: 

  • The AA system's entry point validates and settles the operation on-chain. It ensures that the userop meets the requirements and security checks before executing the desired action. Once the operation is successfully executed, the entry point refunds ETH to the bundler from the wallet's deposited funds. This refund mechanism compensates the bundler for their work and prepayment.

Essential（Intent-Centric Account Abstraction Standard)

*Note that the Essential is still in an early stage; part of the descriptions and designs might evolve over time. For more info, keep an eye on Essential's website: https://essential.builders/

Essential： In the short term, it would be an asset-based intent standard（similar to the erc-4337 model but enables more generalized intents) with a set of facilitated infra. In the long term, it would also provide a modular intent layer and a new constrained-based language that casts off the constraints of Ethereum architecture and provides better intent executions.

• Intent Expression and Authorization: 

  • Dapps or wallets adapting Essential standards can provide related intent-enabled service to users and extract the underlying complexity away. Users only need to interact with the interface and make authorization.

  • Intents can be expressed in Essential's standard in ST and more generally in LT using its new constrained-based language. 

  • Compatible with EVM chains and no need to bridge funds

• Solver Candidates:

  • Essential enables code-expressive intents; various kinds of solvers can join the Essential network to solve corresponding types of intents, such as Cow Swap solvers for swap intents or builders for monitoring and executing chain-state-related intents.

  • A network of solvers would monitor the intents and try to achieve them. Essentials is considering existing solvers/bundlers (e.g. from CoW Protocol or 4337), current MEV searchers and market makers.

• Solving Process: 

  • Solvers figure out the constraint environment they're solving in and then use offchain and onchain venues to try to solve these constraint-based intents

• Solver Selection: 

  • The selection process is more like a Dutch auction in which users specify the constraint while solvers decide when they jump in to satisfy the intent based on the value they can extract from the satisfaction. The first solver to jump in and solve the intent will be the selected solver and likely the best solution that the market can bear then.

• Validation and Settlement: 

  • The validation and settlement both happened by solvers triggering the specific onchain smart contract to verify and split payments. There will be a core contract to which all solutions and all intents and solutions are submitted and extensible with the Essential standards. 

Flashbots SUAVE (Multi-domain Block-related Intent)

*Note that SUAVE is still under development; part of the mechanism described below might change.

Compared to the settlement of intents through smart contracts as seen in the previous examples, SUAVE takes a specialized approach by utilizing a dedicated chain for settlement purposes, which also serves as a messaging layer.

In contrast to Account Abstraction (AA) and intent-specific applications, SUAVE introduces an additional step of bridging funds to the SUAVE chain. This step is primarily driven by SUAVE's multi-chain capability and the desire for more cost-efficient, privacy-enabled transactions. 

SUAVE just announced the launch of MEVM, a powerful modification of the EVM with new precompiles for MEV use cases. With MEVM, SUAVE chain would first efficiently serve MEV-related players like searchers, builders and other domains that want to capture MEV.

• Intent Expression and Authorization: 

  • SUAVE users express their intents in SUAVE by writing EVM codes. These codes outline the desired outcome and functionalities they wish to execute by defining a list of contracts allowing access to the user’s confidential data. There might be some usable templates for normie users.

  • With MEVM, developers can deploy different types of smart contracts for specific MEV applications (e.g. OFA, block building, etc.) or new types of DEXes on SUAVE to be called by other users.

  • Users bridge funds to the SUAVE chain and deposit tips.

• Solver Candidates:

  • The primary participants acting as solvers in SUAVE might be searchers and builders. Searchers and other solvers are responsible for exploring and discovering potential solutions to fulfil user intents, while builders focus on implementing these solutions. They work together to form a robust ecosystem that solves the intents expressed by users.

  • To fulfil different domains' block-related intents, many types of solvers skilled at different domains may exist to support different VMs.

• Solving Process: 

  • Solvers do credible and private off-chain computations that can be used in smart contracts on SUAVE through special precompiles in TEE environments.

  • Solvers collectively work on building blocks that contain a bundle of intents. The purpose of block building is to aggregate and organize the intents into valuable blocks that can be proposed to the network.

• Solver Selection: 

  • In SUAVE, the selection of solvers follows two main approaches. Firstly, solvers who complete the intended tasks first are typically chosen. This incentivizes efficiency and promptness in delivering solutions. Alternatively, an order flow auction mechanism can be implemented, where solvers bid back to users, returning part of the orderflow value to users.

• Validation and Settlement: 

  • To ensure the validity of intents and settle transactions, SUAVE employs oracles and SUAVE validators. Oracles provide external data to validate the execution of intents, while SUAVE validators validate and settle the intents on the SUAVE chain. 

Anoma (Generalized Intent for Anoma Protocols)

Anoma is a general architecture similar to Cosmos and is preparing to launch an IBC-enabled Layer 1 Proof-of-Stake (PoS) chain. It combines intent-centric design with a homogeneous protocol powered by the Anoma Virtual Machine (VM), while also offering heterogeneous security features (different Anoma protocols have different consensus mechanisms).

• Intent Expression and Authorization: 

  • Users express their intents defining the final State or the properties it should have by interacting with Anoma DApps.

• Solver Candidates:

  • Anoma welcomes a diverse range of solvers, each specializing in different types of applications. These solvers monitor the mempools that align with their interests and objectives. Depending on their specific focus, they observe either all intents or a subset of intents. 

• Solving Process: 

  • The solvers run solver algorithms that utilize their expertise in areas such as fungible token (FT) trading or computing rollup states. 

  • Matching intents is also taken care of by solvers. Solvers take intents and make partially or fully matched transactions. Solvers determine what/when to match, what to charge for partial solving, and how to deal with surplus.

  • Once a solver forms a fully balanced transaction, they submit it to a mempool node which is part of the Anoma ecosystem.

• Solver Selection: 

  • The selection can be influenced by the solver's ability to complete tasks efficiently and promptly, following a first-come, first-served approach where the solver who completes the task first is chosen.

• Validation and Settlement: 

  • Validators from different Anoma protocols run Anoma Vm to finish execution and verification of intents. The Anoma VM ensures the integrity and validity of intent execution by checking all relevant Validity Predicates (declarative smart contracts) are satisfied.

  • The distribution of funds and rewards to solvers is based on the execution and verification of intents by the Anoma VM.

How intent revolutionizes the orderflow pattern

In the current transaction orderflow state, users must navigate the execution paths themselves, resulting in a relatively simple tx orderflow (as shown in the picture)

However, envisioning a future where the web3 ecosystem embraces an intent-centric approach, the orderflow of intents could become more intricate. In this new paradigm, users would be free to express their intents and delegate the complexity to a new role called solvers.

Before diving in, I would like to summarize 2 trends in the intent world:

• Leading dapps focusing on specific types of intents like Uniswap and Cow Swap are expanding intent features by involving solvers themselves.

• For more generalized intents, we need relatively new architecture, including a new intent language, a new VM, etc. Essential, Flashbots and Anoma are working toward this direction.

In this scenario, different types of intents might be served by specific platforms or protocols. For instance, swap intents may be handled by UniswapX and Cow Swap; intents with single-domain and wallet-related features could be handled by Account Abstraction (AA) wallets or essential-compatible dapps and wallets; platforms like SUAVE and Anoma might address more generalized and multi-domain intents.

Within this new world, the orderflow of intents could follow a more complex path. Let's explore a possible orderflow:

1. User express intents, deposit funds and authorize

   1. Intents are very expressive; normie users might need help translating their intents into codes. This can be achieved by dapps/wallets extracting this part away by providing a user-friendly interface, or there might be an aggregator providing a universal interface for expressing any intents like Google search with the help of AI.

2. Intents sent to related intent mempool

   1. Note that Anoma can have several mempools serving different types of intents and trusted by different dapps or protocols.

3. Solvers simulate offchain and compete to solve the intents.

   1. In the SUAVE ecosystem, solvers possess both solving capabilities and block-building abilities. Some intents involve solving cross-chain tasks by building blocks, such as cross-chain MEV operations. Skilled block builders have an advantage in building valuable blocks and completing tasks faster. Other intents may primarily require algorithmic expertise, such as optimizing liquidity aggregation across multiple chains. These intents may rely on type-specific solvers rather than extensive block building capabilities.

   2.  In the AA ecosystem, bundlers perform simulation and bundling tasks. The bundled intents are then either sent to the public mempool for searchers to unbundle and potentially front-run, or directly sent to trusted builders. In the early stages, small-volume bundles may be more efficient to be privately sent to trusted builders to avoid potential loss. As 4337 wallets and other players with sufficient orderflow volume enter the market, they can operate as bundlers like searchers.

4. Validate the completion of intents

   1. Presently, various validation methods exist, each with its own set of trade-offs. Using smart contracts for validation, while reliable, often lacks scalability as different intents require specific validation logic and codes. 

   2. Relying on oracles for validation introduces risks associated with oracles, yet offers the advantage of seamless integration with multiple chains. 

   3. Leveraging the Anoma VM requires intent applications to adopt the Anoma framework but provides the capability to validate a wide range of intents. 

In summary, in an intent-centric world, the orderflow is different to the tx-centric world:

• Users sign and authorize tx vs Users have more options to express their intents.

• Single mempool vs Multiple mempools for different purposes exist.

• Dapps is responsible for the execution vs A new role called solvers opt-in and competes to solve the problems.

• Settle on different chains one by one vs Several chains involved can be settled together (new types of cross-domain executions)

The Ripple Effects of Intents on the Rest of the Web3 World

An intent-powered world involves a lot of web3 participants. Let's get a rough look at the intent-factory landscape. 

Note that this is just a rough landscape. As intents evolve gradually, more parties can participate in this new world. For example, shared sequencers like Astria and Espresso can give users quicker preconfirmations in terms of multi-domain intent executions.

• Upstream

  • Chains

    • New chains like SUAVE can facilitate more frequent and cost-effective intent settlement.

    • Anoma-structured chains support new virtual machines that solve the intent validation problem efficiently and generally.

    • Layer 2 or more scalable chains are suitable for performing inexpensive computations related to intent logic expression, validation, and settlement, as intents tend to be computationally intensive due to their expressive nature.

  • Privacy

    • Privacy is crucial in the intent world to prevent malicious MEV problems such as frontrunning and enables more orderflow value being bid back to users/dapps. Additionally, incorporating privacy features can support intents that require enhanced privacy.

    • SUAVE adopts SGX as a short-term solution, while Anoma supports zero-knowledge proofs (zk) and Distributed Key Generation (DKG) encryption.

  • Oracle

    • Oracles now have additional functionality: assisting in validating the fulfilment status of intents.

  • Intent-related Standard

    • A general standard helps to reduce the fragmentation problems brought by different types of intents; Solvers can find it easier to integrate with different intent-enabled apps; Dapps and developers easier to expand to intent systems; 

    • Avoid reinventing the wheels for common intent infrastructure.

• Midstream（Potential Solvers）

  • Type-specific solvers like routers for CoW Swap and 1inch, eg, Propeller Heads, and market makers have accumulated large liquidity networks and advanced routing algos, outperforming other solvers and possibly receiving part of exclusive orders directly from swappers.

  • Builders: 

    • Builders play a significant role as solvers, especially in the final settlement process involving different chains. Experienced builders can easily fulfil this responsibility.

  • Searchers: 

    • Searchers possess expertise in routing and advanced algorithms, making them valuable for solving intents related to finding optimal solutions or accessing liquidity.

• Downstream

  • Intents have a broad impact on various dapps:

    • Enhanced user-friendliness leads to mass adoption.

  • Increased involvement of multiple parties results in more off-chain components, improving efficiency and flexibility.

    • Dapps can expand to provide more functionalities and features by incorporating intent solvers to incorporate more complex functions.

    • For example, in DeFi, intents can emulate atomicity in a cross-chain environment by involving a third party, the solvers, to execute the intent. Solvers take on the risk of failure, enabling a new realm of cross-domain DeFi.

  • More interactions and user instructions lead to the development of complex dapps.

    • For example, in GameFi, users now have greater options for gameplay:

      • Customized game strategies: Intents allow players to define and execute custom game strategies. They can express their game objectives and actions in their way and have solvers execute these intents within the game. This provides players with more freedom and control.

      • Support for economic systems: Through intents, players can participate in in-game economic systems such as trading game assets, providing liquidity, or engaging in lending. By expressing their intents, they can perform financial operations similar to DeFi within the game and earn economic rewards.

Ending

As I conclude this article, I notice the striking similarity between the philosophy of intents and rollups: executing off-chain and final settlement and validation on-chain. With the explosive growth of the rollup ecosystem, we are also now witnessing the explosive growth of intents, with dapps becoming more and more expressive and many projects developing intent-specific language and standards.

However, I want to draw attention to the potential centralization issues that may arise with intents. Just as we've witnessed in the case of private mempools and private order flows, players capable of handling complex user intents and providing a more efficient and user-friendly experience may stand out and attract more private intent order flow, resulting in better execution and increased order flow.

In addition, how intent players could start to involve solvers to efficiently fulfil the intents for users is a practical problem. For example, with current low-volume AA transactions, bundlers or builders do not have enough motivation to spend additional energy and time to provide a new tranche of service. This problem could also exist for more expressive intents.

In conclusion, the world of intents holds immense potential and transformative power. We must navigate the path forward, balancing innovation, decentralization, and user empowerment. Let's embrace this exciting journey and work together to unlock the full potential of intents！

Reference