SevenX Ventures: Decoding "INTENTS", How to Revolutionize Web3 User Experience and Order Flow Patterns

Source: SevenX Ventures

Author: Grace

This article is an original work by the SevenX research team, intended for communication and learning purposes only, and does not constitute any investment advice. If you need to cite it, please indicate the source.

The original English report was published on the SevenX Mirror platform in August 2023. For more Chinese investment research content, please follow the WeChat public account [SevenXVentures].

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

As Web3 technology gradually moves towards mainstream applications, it is crucial to ensure that users can autonomously navigate the complexities of Web3. Unlike the early days of blockchain, users no longer need to decipher intricate technical details; the future trend is to provide a user experience that guides and empowers users to interact seamlessly with decentralized systems. Drawing from the development trajectory of Web2, user needs are becoming increasingly richly expressed through search engines and chatbots like ChatGPT. Web3 must offer an easy-to-use yet powerful user experience.

Intent-driven interactions become the foundation of a user-friendly Web3 experience. While there are various definitions of intent, I prefer to categorize intent into the following three groups of keywords:

• Results over paths: Users only need to express what they want without worrying about how to achieve the results.

• Conditional authorization over code authorization: When users sign blockchain transactions, they authorize the transaction code to execute arbitrary computations that modify the state of the blockchain. In contrast, when users approve an intent, they are authorizing the release of their assets and tips only after ensuring that the desired results have been achieved (similar to cash on delivery in online shopping).

• Competitive solvers over trusted dapps: In a transaction-dominated world, users interact with the dapps of their choice, which act as service providers to deliver the expected results, often long-standing mainstream dapps like Uniswap. In an intent-driven world, known or unknown off-chain and on-chain solvers compete to fulfill user intents and earn rewards. From an economic perspective, the more intense the competition, the higher the efficiency.

In summary, users can express their intents clearly and directly; platforms can leverage solvers and executors to find the best execution paths to achieve user goals. Just as in Web2, where black boxes work behind the scenes to optimize outcomes, Web3 executors can utilize algorithms and automated processes to handle the complexities of execution, ensuring that users efficiently obtain the desired results and are rewarded.

By prioritizing user experience and focusing on expressing intents, Web3 can usher in a new era where the power and potential of decentralized systems are accessible to everyone. The future of Web3 lies in democratizing access, simplifying interactions, and guiding and liberating users through a decentralized landscape to achieve a seamless user experience.

Exploring Different Types of Intent Implementations

Intents can be categorized into different types based on their generality, as shown in the diagram below:

In fact, a wide variety of intents are ubiquitous, as blockchain code = a degree of automation = extracts a certain complexity and returns the desired results to users. However, we hope to have the most general intents in the future; AA+ specific intent applications are not enough because they cannot operate across domains and cannot scale as effectively as more permissive intents.

To understand how intents operate, we can analyze the currently available solutions, from specific intent applications to general intent infrastructures like Anoma and SUAVE. This analysis will primarily be divided into five parts, focusing on different questions:

• Intent expression and authorization: How do users input their intents? What types and levels of intents can users express? What kind of authorization do users provide?

• Candidate solvers: Are they permissioned or permissionless? Is there a high standard to become a solver? Are there different types of solvers focused on other specific domains?

• Solving process: What are the main avenues for solving problems? What determines that an intent has been completed?

• Solver selection: What are the rules for selecting a winner from several candidate solvers? Is it winner-takes-all or a discrete competition model?

• Verification and settlement: How is it verified that the solver has completed the task? How is settlement handled between users and solvers?

Below is a comprehensive overview of current solutions. For more detailed information, please delve into the content below.

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 interface, 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 with the trading token instead of using ETH for gas fees, and there are no costs if the trade is not executed.

Candidate Solvers

• In the case of 1inch Fusion, solvers are resolvers that operate in a permissionless manner. They need to register, undergo KYC verification, and maintain sufficient balances to cover order fees.

• Cow Swap's solvers are either whitelisted by creating million-dollar binding pools (USDC & Cow) or included in the Cow DAO binding pool or Gnosis DAO binding pool, and are whitelisted by Cow DAO based on DAO standards.

Solving Process

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

• Additionally, solvers can directly explore other potential on-chain automated market makers (AMMs) like Uniswap or utilize DEX aggregation platforms like 1inch to discover optimal prices and paths.

Solver Selection

• In Cow Swap, traders execute trades at the best prices determined by any external solvers utilizing batch auctions, maximizing traders' profits. The solver providing the optimal solution will be selected.

• In contrast, the competition for resolvers in 1inch Fusion is more restricted and is related to the staking of 1inch tokens using a Dutch auction.

Verification and Settlement

• The verification and settlement process occurs after the solver executes the trade or limit order. Solvers can utilize ERC 20 approvals granted to settlement contracts to transfer tokens on behalf of users. The settlement contract verifies the user's intent signature and ensures that the execution meets the specified limit price and quantity. This verification confirms that the intended trade or limit order has been successfully completed.

• Once verified, the settlement contract can appropriately allocate funds to the solvers and users involved in the trade.

Recently, Cow Swap announced the launch of Cow Swap Hooks, which enable more general swap intents to be executed through custom-coded DeFi operations that can be executed directly before and/or after trades. It is exciting to see Uniswap v4 and Cow Swap moving towards more general intent activities, bringing us a new world of DeFi intents!

UniswapX (Swap Intents)

The new features of UniswapX can be divided into two main parts: signing orders through a Dutch auction mechanism and cross-chain swaps.

Orders signed through Dutch auctions are similar to limit order intents in 1inch Fusion and Cow Swap, but there are differences in intent expression and authorization, candidate solvers, solver selection, and verification and settlement.

Intent Expression and Authorization

• Users have more freedom to define parameters (which may also introduce more complexity), including the decay function of the auction, the initial Dutch order price, etc.

Candidate Solvers

• By default, it operates in a permissionless mode, but users can also set it to a permissioned mode.

Solver Selection

• The execution price of Dutch orders depends on their block time. For swappers, the initial price estimate of the order is better than the current market price; for example, if the current market price is 1,000 USDC per ETH, the starting price of a sell order might be 1,050 USDC per ETH, and then the order price gradually decays until it reaches the minimum price acceptable to the swapper, such as 995 USDC per ETH. To profit, fillers are incentivized to complete the order quickly; otherwise, they risk missing the order, allowing other fillers willing to accept smaller profits to benefit.

• UniswapX also supports RFQ (Request for Quote), allowing orders to specify a filler who gains exclusive rights to submit the order within a short time for setting the initial Dutch auction price. In this case, the selection process is almost the same as the auction method of 1inch Fusion.

• Compared to the independent auctions of UniswapX and 1inch, Cow Swap is more like a batch auction that can merge orders and match CoW.

Verification and Settlement

• Cross-chain swaps can be achieved through a similar process, with the main difference being the verification and settlement for multi-domain swaps: solvers need to deposit more bond assets on the original chain to ensure security and enable optimistic cross-chain protocols; an additional settlement oracle is needed to provide data for the verification contracts on the original chain; and UniswapX needs to deploy corresponding settlement and verification contracts in different domains.

Account Abstraction (Wallet Layer Intent)

Intent Expression and Authorization

• The process begins when the wallet owner wants to perform a specific action, typically generating a user operation (userop) through a 4337 wallet interface to express their intent.

• Off-chain, the wallet owner can request a bundler to handle the userop on their behalf, but must authorize limited control based on the intent. For example, the wallet owner can authorize the private key for main account transactions but can only use the hub contract of Dapp XYZ.

Candidate Solvers

• In the AA framework, bundler services are viewed as public goods. Most bundlers are open-source, making them non-exclusive and non-competitive; any RPC endpoint can replicate the open-source code and operate as a bundler. Even if a bundler RPC endpoint wants to charge for its services, it can do so through API keys while maintaining the non-exclusivity of the bundler as a public good.

• The two main types of bundlers include those specifically built for wallets that meet the basic needs of wallets and permissionless, modular bundlers that provide third-party infrastructure services.

Solving Process

• Bundlers simulate the wallet's validateOp method on the userop to determine whether to accept or reject it off-chain, and then send the transaction to the entry point of the AA system to invoke the handleOp method. This process also includes bundling multiple user operations together to optimize gas fees and extract MEV.

• The entry point contract pushes the operations on-chain, and chain nodes verify the operations and reach consensus.

Solver Selection

• The selection of solvers in AA depends on various factors. The wallet used by the account owner may provide bundler services or use third-party infrastructure, and users may switch RPC endpoints to choose their preferred bundler. In this case, the success rate and reputation of the bundler may influence the selection of solvers.

Verification and Settlement

• The entry point of the AA system verifies and processes on-chain operations, ensuring that the userop meets the requirements and security checks before executing the desired operations. Once the operation is successfully executed, the entry point refunds ETH from the wallet's deposit to the bundler. This refund mechanism compensates the bundler for the work done and its prepayment.

Essential (Intent-Centric Account Abstraction Standards)

Currently, Essential is still in its early stages, and some descriptions and designs may evolve over time. In the short term, it will be an asset-based intent standard similar to the ERC-4337 model but supporting broader intents and equipped with a convenient infrastructure. In the long term, it will also provide a modular intent layer and a new constraint-based language that frees itself from the constraints of Ethereum architecture to execute better intents.

Intent Expression and Authorization

• Dapps or wallets adopting the Essential standard can provide users with relevant intent-supported services and eliminate potential complexities, allowing users to interact with the interface and authorize. Intents can be expressed using the Essential standard in the short term and can be expressed more generally using its new constraint-based language in the long term. It is compatible with EVM chains without the need to bridge funds.

Candidate Solvers

• Essential supports code-expressed intents, and various solvers can join the Essential network to address corresponding types of intents, such as Cow Swap solvers for swap intents or builders monitoring and executing chain state-related intents.

• A network of solvers will monitor and strive to fulfill these intents. Essentials is considering existing solvers or bundlers from CoW protocol or 4337, MEV seekers, and market makers.

Solving Process

• Solvers clarify the constraint environment they are solving and then attempt to resolve these constraint-based intents both off-chain and on-chain.

Solver Selection

• The selection process is more like a Dutch auction, where users specify constraints, and solvers decide when to enter based on the size of the extractable value. The first solver to enter and resolve the intent will be the selected solver and may be the best solution the market can bear at that time.

Verification and Settlement

• Verification and settlement are triggered by solvers invoking specific on-chain smart contracts to verify and split fees. There will be a core contract to which all solutions and intents will be submitted, and it can be extended using the Essential standard.

Flashbots SUAVE (Multi-Domain Block-Related Intent)

Compared to the way smart contracts solve intents in previous examples, SUAVE adopts a dedicated chain for settlement, which also serves as a messaging layer. Unlike account abstraction (AA) and specific intent applications, SUAVE's multi-chain capability introduces an additional step of bridging funds to the SUAVE chain, enabling more cost-effective and privacy-enabled transactions.

SUAVE has just announced the launch of MEVM, a powerful modified version of the Ethereum Virtual Machine (EVM) that includes new precompiled contracts for executing miner extractable value (MEV) related use cases. Through MEVM, the SUAVE chain will effectively serve participants related to MEV, such as seekers, developers, and others looking to capture MEV.

Intent Expression and Authorization:

• SUAVE users express their intents in SUAVE by writing EVM code. This code outlines their desired outcomes and functionalities by defining a list of contracts that allow access to user confidential data. There may be some templates available suitable for ordinary users.

• Through MEVM, developers can deploy different types of smart contracts for specific MEV applications (e.g., OFA, block building, etc.) or deploy new types of DEX on SUAVE for other users to call.

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

Candidate Solvers

• The main participants acting as solvers in SUAVE may be seekers and builders. Seekers and other solvers are responsible for exploring and discovering potential solutions to meet user intents, while builders focus on implementing these solutions. They work together to build a robust ecosystem for solving user-expressed intents. To meet different domain-related intents, there may be many solvers with specialized skills in different domains to support various virtual machines (VMs).

Solving Process

• Solvers perform trusted and private off-chain computations, which can be used through special precompiles for smart contracts on SUAVE within a TEE environment. Solvers work together to construct blocks containing a set of intents. The goal of block building is to aggregate and organize these intents into valuable blocks that can then be proposed to the network.

Solver Selection

• In SUAVE, solver selection follows two main approaches. First, the solver that completes the expected task first is typically chosen. This improves the efficiency and timeliness of delivering solutions. Alternatively, an order flow auction mechanism can be implemented, where solvers bid to users, returning part of the order flow value to them.

Verification and Settlement

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

Anoma (General Intent of Anoma Protocol)

Anoma is a general architecture similar to Cosmos, preparing to launch the first layer proof-of-stake (PoS) chain supporting IBC. It combines intent-centric design with isomorphic protocols supported by the Anoma virtual machine (VM), while also providing heterogeneous security features (different Anoma protocols have different consensus mechanisms).

Intent Expression and Authorization

• Users express their intents by interacting with Anoma DApps, defining the final state or attributes that should be present.

Candidate Solvers

• Anoma welcomes various types of solvers, each focusing on different types of applications. These solvers monitor the memory pools that align with their interests and goals. Depending on their specific focus, they may observe all intents or a subset of intents.

Solving Process

• Solvers run solving algorithms, leveraging their expertise in fungible token (FT) trading or calculating rolling states, among other areas. Solvers are also responsible for matching intents. They receive intents and generate partially or fully matching trades. Solvers determine when to match, the fee standards for partial resolutions, and how to handle excess portions. Once a solver forms a fully balanced trade, they submit it to the memory pool nodes of the Anoma ecosystem.

Solver Selection

• The selection of solvers may be influenced by their ability to efficiently and timely complete tasks, following a first-come, first-served principle, where the first solver to complete the task is chosen.

Verification and Settlement

• Validators from different Anoma protocols run the Anoma virtual machine (VM) to complete the execution and verification of intents. The Anoma VM ensures the integrity and validity of intent execution by checking that all relevant validity predicates (declarative smart contracts) are satisfied. The allocation of funds and rewards to solvers is based on the results of the Anoma VM executing and verifying intents.

How Intent Will Transform Order Flow Models

In the current state of transaction order flow, users must navigate execution paths themselves, resulting in relatively simple transaction order flows.

However, envision a future where the Web3 ecosystem adopts an intent-centric approach, where the flow of intents may become more complex. In this new paradigm, users can freely express their intents and delegate complexity to new roles—solvers.

Before diving deeper, I would like to summarize two trends in the realm of intents: first, major DApps focusing on specific types of intents, such as Uniswap and Cow Swap, are expanding intent capabilities by introducing solvers themselves. This means they are collaborating with roles (solvers) focused on solving specific problems to provide broader services. Second, there are more general intents, which require relatively new architectures, including new intent languages, new virtual machines, and so on. Projects like Essential, Flashbots, and Anoma are working towards this direction. This means that new technologies and tools need to be developed to meet more general intents and accommodate different types of needs.

In this context, different types of intents may be handled by specific platforms or protocols. For example, trading intents can be handled by UniswapX and Cow Swap; intents with single-domain and wallet-related characteristics can be managed by account abstraction (AA) wallets or DApps and wallets compatible with Essential; while platforms like SUAVE and Anoma may handle more general and multi-domain intents.

In this new world, the order flow of intents may follow more complex paths. Let’s explore a possible order flow:

• Users express intents, deposit funds, and authorize

  Intents are highly expressive; ordinary users may need help translating their intents into code. This can be achieved by dapps/wallets providing user-friendly interfaces to extract this part, or there may be an aggregator offering a universal interface to express any intent, perhaps aided by AI-powered Google search.

• Intents are sent to relevant intent memory pools

  Note that Anoma can have multiple memory pools serving different types of intents, trusted by different DApps or protocols.

• Solvers perform off-chain simulations and compete to resolve intents

  In the SUAVE ecosystem, solvers possess both solving capabilities and block-building capabilities. Some intents involve solving cross-chain tasks by building blocks, such as cross-chain MEV operations. Skilled block builders have an advantage in constructing 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 more on specific types of solvers rather than broad block-building capabilities.

  In the AA ecosystem, bundlers perform simulations and bundling tasks. The bundled intents can then be sent to public memory pools for seekers to unbundle and potentially perform front-running, or directly sent to trusted builders. In the early stages, small bundles may be more effective as they can be privately sent to trusted builders to avoid potential losses. As 4337 wallets and other participants with sufficient order flow enter the market, they can operate as bundlers like seekers.

• Verification of intent completion

  Currently, there are various verification methods, each with its own set of trade-offs. Using smart contracts for verification, while reliable, often lacks scalability, as different intents require specific verification logic and code; relying on oracles for verification introduces risks associated with oracles but offers the advantage of seamless integration with multiple chains; utilizing the Anoma virtual machine requires intent applications to adopt the Anoma framework but provides the capability to verify various intents.

  In summary, in an intent-centric world, order flow differs from a transaction-centric world: users sign and authorize transactions vs. users have more choices to express their intents; a single memory pool for different purposes vs. multiple memory pools; Dapps responsible for execution vs. a new role of solvers choosing to join and solving problems competitively; settlement one by one across different chains vs. multiple chains settling together (new cross-domain execution).

The Ripple Effect of Intent on the Web3 World

An intent-based world encompasses a multitude of Web3 participants. Next, we can take a rough look at the current landscape of intents. Please note that this is just an overview. As intents gradually evolve, more participants will enter this new world. For example, shared sequencers like Astria and Espresso can provide users with faster pre-confirmations in multi-domain intent execution.

Upstream

Chains

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

• Anoma's structured chains support new virtual machines that can efficiently and universally address intent verification issues.

• L2 or more scalable chains are suitable for executing low-cost computations related to intent logic expression, verification, and settlement, as the entire process requires substantial computational resources due to the expressiveness of intents themselves.

Privacy

• Privacy is crucial in the intent domain, as it can prevent malicious MEV issues like front-running and allow more order flow value to be bid back to users/dapps. Moreover, including privacy features can support intents that require stronger privacy protection.

• SUAVE adopts SGX as a short-term solution, while Anoma supports zero-knowledge proofs (ZK) and distributed key generation (DKG) encryption.

Oracles

• Oracles now have an additional function: assisting in verifying the implementation status of intents.

Intent-Related Standards

• General standards help reduce fragmentation issues arising from different types of intents; solvers can more easily integrate various applications supporting intents; dapps and developers can more easily scale to intent systems. Intents can also avoid the need to rebuild public intent infrastructure.

Midstream (Potential Solvers)

Specific types of solvers (such as routers from CoW Swap and 1inch), as well as market makers, have accumulated vast liquidity networks and advanced routing algorithms that outperform other solvers and may receive part of exclusive orders directly from swappers.

Builders: Builders play a crucial role as solvers, especially in the final settlement process involving different chains. Experienced builders can easily fulfill this role.

Seekers: Seekers possess expertise in routing and advanced algorithms, making them highly valuable in solving intents related to finding optimal solutions or acquiring liquidity.

Downstream

Intents have a broad impact on various dapps—enhancing user-friendliness; enabling mass adoption; increasing multi-party participation brings more off-chain components, improving efficiency and flexibility; dapps can integrate more complex functionalities through intent solvers to provide more features and characteristics.

For example, in DeFi, intents can be executed by leveraging third parties (solvers) to simulate atomicity in cross-chain environments. Solvers bear the risk of failure, thus opening up new realms of cross-domain DeFi.

Additionally, more interactions and user directives can facilitate the development of complex dapps. For instance, in GameFi, users now have more gameplay options:

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

• Supporting 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, players can perform DeFi-like financial operations within the game and earn economic rewards.

Conclusion

In summarizing this article, I noticed a striking similarity between the concepts of intents and rollups: off-chain execution and on-chain final settlement and verification. With the explosive growth of the rollup ecosystem, we are now witnessing the explosive growth of intents, with dapps becoming increasingly expressive, and many projects developing specific intent languages and standards.

However, I would like to draw attention to the potential centralization issues that intents may bring. As we have seen in cases of private memory pools and private order flows, players capable of handling complex user intents and providing more efficient, user-friendly experiences may stand out, attracting more private intent order flows, leading to better execution attracting more order flows.

Moreover, how intent players effectively enable solvers to realize intents for users is also a practical issue. For instance, in the case of current small AA transactions, packers or builders may lack sufficient motivation to invest extra time and effort to provide new services. More expressive intents may also face this issue.

In summary, the intent domain holds immense potential and transformative power, and we must find a path forward that balances innovation, decentralization, and user empowerment. Let us embrace this exciting journey and work together to unleash the full potential of intents!