SoK: Intent-Based Architecture

By: Naman Garg (2021171)
Instructor: Dr. Dhruv Kumar

Introduction

As the web3 technology moves towards wide-spread adoption, it is necessary to ensure that users are comfortably able to use the applications. To serve the next billion users it is necessary to ensure we can provide web2-like experience to the web3 users.

Enter intents - if a transaction refers to "how" an action should be performed, an intent refers to "what" the desired outcome of the action should be [1].

This declarative approach opens the door to increased efficiency and user experience. Users can simply express their desired result, leaving it to knowledgeable third parties (solvers) to figure out how to best achieve it. The imperative paradigm today, in which the user actively specifies every parameter, is in contrast.

This idea isn't particularly new. Concept of intents is in active use in the web2 domain. Think about how convenient it is to use search engines like Google: when someone searches on Google, they are not providing instructions on how to retrieve that information. All they do is convey the intention; the engine figures out the how. Similarly, Apple has also been using Intent framework.

Intents use solvers and executors to make sure the optimal execution path for user's goals while users express their intentions with clarity. Web3 executors employ algorithms and automated procedures to handle execution complexity, ensuring users efficiently achieve desired outputs and receive compensation. This is similar to web2, where algorithms operate in the background to optimise results.

What are Intents?

Let's understand intents with some examples,

Consider a metamorphic example -
Intent (declarative): I will pay $20 for a pizza at my door by 8pm
Transaction (imperative): Hop on to your scooter, go to Domino's, order item#4, and bring it. Here is your $20; 18 for pizza, and 2 for gas.

Similarly in the web3 sphere -
Intent: I desire X, in exchange for C.
Transaction: First do A, followed by B, and allocate precisely C to retrieve X.

We can see clearly, intents provide better UX!

Intents are also seen as partial transactions [3] because they represent a commitment or declaration of one's intention to engage in a transaction, but they lack the complete information or actions required for a transaction to be fully executed. The missing parts need to be provided by someone else, making intents incomplete on their own. Intents only become valid transactions when another party contributes the necessary elements to fulfill the intended transaction.

The Current State of Intents

Intents are not a new concept. In the days before Uniswap and AMM’s, Ethereum projects like EtherDelta and 0x provided intents-based order books. NFT marketplaces have used signed intents for NFT listings and offers for years. Newer systems like CoW Swap and UniswapX now provide more advanced intents-based infrastructure for ERC20 limit orders. Looking at the current landscape, the term “intents” might seem to be synonymous with “limit orders” because the only intents that are widely supported in Web3 today are “I want X and I’m willing to pay Y”.

Intent architectures for limit orders are generally simple and built for a single-purpose: the intent to swap at a better price than what the current market offers. Users sign their limit order intent and solvers look for routes to “fill” the signed intents using AMM’s, other liquidity sources, or in some cases other intents. Solvers are incentivized to find the route because they get to keep whatever extra is left over after the user’s intent is filled.

Solver Incentives

Solvers are important to all intent-centric systems. They handle the technical details of transaction issuance, navigate the complexities of swap routing and other state modifying solutions, and ultimately ensure that user intents are settled in the best way. Also solvers, on the other hand, are not peaceful beings. Solvers are in strong rivalry with one another in a totally decentralized and trustless setting. They are only motivated by the MEV profit they can derive from each goal.

To safeguard users from malicious actors, intent-centric protocols only permit solvers to function within the boundaries of what a user authorises and approves. In an ideal world, an intent-centric protocol aligns user goals with solver incentives. At scale, a protocol with well-designed solver incentives has network effects. In other words, as solver competition grows, users' outcomes improve.

Understanding Solver Incentives:

Solvers hold the key to executing transactions efficiently. However, with great power comes great responsibility, and solvers face the challenge of optimizing their strategies amidst potential pitfalls. The primary goal is to extract maximum value from executing intents while mitigating risks such as front-running and collisions.

Mitigating Front-Running Challenges:

Front-running, a common concern in decentralized systems, occurs when solvers exploit transaction information to gain an advantage. To counter this, intent protocols must incorporate protective mechanisms. Solvers, lacking such built-in safeguards, resort to strategies like submitting solutions to a private mempool or paying block builders for favorable ordering. Ideally, protocols implement mechanisms that force solvers to coordinate, eliminating the need for these suboptimal strategies.

Forcing Solver Coordination:

Solver coordination is essential for efficient intent execution. Various protocols employ strategies like round-robin solver selection, whitelists, and Order Flow Auctions (OFAs) to foster collaboration. Round-robin selection involves randomly assigning exclusive solving permissions, while whitelists restrict intent permissions to trusted solvers. OFAs, on the other hand, move solver competition off-chain by requiring bids on intents before settling.

If a permissioned solver does not follow a solution, a fallback mechanism needs to be in place like dutch auction for the intent in the case of UniswapX

Fee Escalators for Predictable Settlement:

To provide a predictable timeframe for settlement, fee escalators come into play. The concept involves increasing fees over time until solvers find the incentive to settle. UniswapX uses fee escalators to ensure a smoother settlement process, preventing the swap from getting stuck in an unfillable state.

Conditional Intents and Their Challenges:

Not all intents are created equal, and conditional intents introduce a layer of unpredictability. These intents, requiring specific state conditions for settlement, present challenges in terms of settlement time predictability. Fee escalators become crucial in providing a suitable level of guaranteed settlement.

Trade-offs: Speed vs. Price:

Intent outcome optimization often involves a trade-off between speed and price. Users, depending on their priorities, may opt for faster execution with higher fees or choose a slower settlement with lower costs. The flexibility to choose between speed and price allows users to tailor their intent strategies to specific scenarios.

Reputation-Based Incentives:

While reputation-based incentives sound promising, they pose centralization risks. Relying solely on reputation can lead to exclusive order flow, potentially centralizing the system. Formal reputation scoring and DAO governance introduce complexities, and informal reputation may emerge as users limit intents to specific solvers.

Protocol Standardization:

In the rapidly evolving solver ecosystem, standardization becomes crucial. The emergence of protocols like EIP-7521 for generalized intents and Brink's protocol for composable intents aims to create open standards. Standardized protocols enable solvers to integrate with multiple apps seamlessly, fostering a more interconnected and efficient ecosystem.

High-Level Architecture of Intents

On a high-level the architecture consists of a robust "solver" for processing the user's intent and a "smart account" for the transaction execution.

Solver's Architecture

• AI-Enhanced Resolver: a system powered by AI for solving the user's intent. This component is not necessary and can be avoided if we already have the high-level tasks that is required. This resolver translates the intent into specific actionable tasks.
• Mempool Management: Rather than traditional transactions, a dedicated mempool is designed to hold these decomposed tasks. Serving as a dynamic pool, it ensures that tasks are both accessible and prioritized, ready to be claimed by specialized solvers.
• Domain-Specific Solvers: Leveraging the mempool, domain-specialized solvers then claim their respective tasks. For instance, a swap-focused solver such as 1inch might elect a swap task, determining the best route and generating the exact transaction with parameters like ‘to’, ‘from’, and ‘calldata’. Concurrently, a bridging solver might address a bridging task, crafting a distinct transaction to execute it optimally.
• Aggregation Mechanism: Post the generation of optimal transactions by these solvers, an aggregation mechanism assumes responsibility. It orchestrates the collection, organization, and preparation of these transactions, streamlining them for efficient ecosystem execution.

The Smart Account: Execution Excellence

After processing the intent into a assembled transaction, the next step is seamless execution of the transaction using smart account. Use of smart account (ERC4337) provides various benefits some of which are -

• Provisioning user-specific wallets on emergent chains as needed.
• Enabling gasless transactions in scenarios where users are devoid of native tokens.
• Effectively batching transactions, optimizing them for efficient execution.

Role of LLMs in Crafting Intents

Large language models (LLMs) are models that translate between any type of human expression. They can be used to translate -

• Text -> Image Generation 📸
• Speech -> Text Transcription 📝
• Code Description -> Code Implementation 💻

LLMs can be seen as an interactive encyclopedia that can be interacted with to get responses which can also help us figure out what we want in addition to translating.

Discover your Intent

Discovering your intent can be challenging when navigating from vague desires to important actions like investing sensibly. This is where LLMs step in, LLMs excel at profiling your wallet by accessing public data, and offering insights into your trade history, token holdings, interests, and risk tolerance. Through clustering, LLMs identify wallets with similar behavior, providing tailored recommendations based on what these wallets do. LLMs can also outsource research tasks, gathering data from sources like Twitter or monitoring lending pool APYs, saving time and effort.

Intent to On-chain transactions

Navigating the transition from intent to on-chain transactions can be a cumbersome process. LLMs possess the capability to seamlessly translate user intent into smart contract calls, eliminating the barriers between conceptualizing desires and expressing them on-chain as transactions. Their ability to ingest both structured and unstructured data equips them to inform and refine user intents effectively.

One notable feature is the introduction of Fuzzy Intent Matching, a mechanism facilitated by LLMs to discover coincidence of wants (CoWs) more frequently. P2P trades are more efficient than peer-to-pool trades, so we should aim to find coincidence of wants (CoWs) as often as possible. By mapping expressed intents to a higher-level intent space and engaging in fuzzy matching, LLMs not only identify potential matches but also aid in intent renegotiation for more peer-to-peer matches.
Additionally, LLMs empower users to construct wide intents, incorporating a range of acceptable conditions and options, thereby enhancing the likelihood of CoWs and ultimately reducing trade costs.

Security Concerns

LLMs raise security risks due to their intrinsic mysteriousness and the difficulty in aligning their behavior with the user's objectives. Because of the opacity of LLMs, it is difficult to ensure that there are no hidden prompts, which could result in unexpected outcomes such as money being sent to a wrong location (address). Exploring formal purpose modules and secure back-translation mechanisms is critical for solving this risk, while more study is needed in this area. Furthermore, there is a concern about supplying financial infrastructure to computers that may outperform human intelligence. While resolving these problems is a matter for future talks, it highlights the importance of strong security measures and continuous research into ways to enable the safe and transparent use of LLMs in financial environments.

Comparative Analysis

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 -

Intent Protocol Overview

A general overview of how an intent app/protocol might function

Data Overview

Overview of some of the data around UniswapX and CoWswap, the ones with the most solvers active (1inch has good volume, but their fillers (solvers) are quite limited based on a number of reasons (such as stake lockup)

Use Cases

Intents have been created for the outsourcing of the complexities of interacting with the blockchain while permitting users to maintain custody of their assets and cryptographic identity.

Many of these ideas correspond to systems that have been in operation for several years and many need improvements:

• Limit Orders: Automatically execute a trade of 100 X tokens only if at least 200 Y tokens are received, ensuring precise and conditional transactions.
• Peer-to-Peer Trading: Cut out intermediaries by declaring trade intents directly, enhancing efficiency, and improving prices for both parties involved.
• Automated Trading: Implement dollar-cost averaging or portfolio rebalancing automatically, enabling hands-free management of investments.
• Gas Sponsorship: Pay transaction gas fees in USDC instead of ETH, contingent on a matching intent that covers the fees in ETH, optimizing gas efficiency.
• Conditional Trading: Automatically execute trades based on predefined market conditions, such as selling X asset when its price reaches a specified threshold.
• Security Screening: Restrict interactions to smart contracts with verified proofs from whitelisted audit teams, ensuring secure and trusted transactions.
• Low Fee Execution: Execute transactions only when gas fees are below 0.1% of the transaction value, minimizing costs and maximizing efficiency.
• Insurance: Pre-commit to pay defined amounts under specific conditions, providing financial security with verifiable terms for third-party validation.
• Deadman Switch: Enable a trusted friend to claim assets if there's no activity in the wallet for six months, adding a layer of security and inheritance planning.
• Overlapping Options: Commit to options with preferences that overlap, settling on the choice that aligns with the majority, fostering consensus in decision-making processes.

Conclusion

The adoption of intents represents a shift from an imperative to a declarative paradigm, which promises to improve UX and efficiency loss due to MEV leakage significantly. The demand for these applications is clear and many intent-based applications have been used widely for several years. There is still plenty of research and engineering to do in this nascent transacting paradigm and areas that are yet to be covered in this like mempools design.

Next steps

• There are no academic/research paper on this topic (afaik) so I would like to polish this more and getting this published. Will need help of Dhruv sir with the procedure.
• Add details about implementation.
• Extensive proofreading with focus on accuracy of details (diff resources have diff pov to some points)
• Implement a MVP/prototype.

References

1. Paradigm
2. BananaHQ
3. Propeller swaps
4. SevenX ventures
5. Brink trade
6. UniswapX
7. Anoma
8. Essential
9. CoW swap

Some diagrams/figures are taken from the referenced material