Breaking down intents

Intents are the things before a transaction.

It’ll make sense in a bit.

An intent is a desired state change specified by the user. An intent-based system abstracts the complexities of a typical transaction and focuses on what the user’s outcome is, whereas a transaction specifies how that outcome is achieved. Practically everything can be considered an intent since a user is always expressing their goal when interacting with a dApp — the key difference is how that user’s objective is captured and executed. Intents eventually get converted into transactions, but only after they are processed by an intent-based system designed for that purpose.

Intents Vs. Transactions

• Transactions are explicitly defined, making them imperative- meaning that every function for how to execute the transaction in the virtual machine is already defined (example: swap 1 ETH for 2,000 USDC using Uniswap ETH-USDC pool on Ethereum with ETH as the gas fee).
• Intents on the other hand specify the state change, but not how to get there, making them declarative. (eg: change the state of my account from 1 ETH to at least 2,000 USDC – basically, swap 1 ETH for >= 2,000 USDC)

Let’s say you have USDC but would like to get Aave’s interest-bearing ETH (asETH). Normally, there are a few steps involved. You would have to:

• get ETH for gas if you don’t already have (several steps in itself)
• approve USDC to swap
• swap USDC for ETH
• swap ETH to WETH
• deposit WETH into aave

Using something like portals, you could simply swap your USDC directly for asETH by signing 1 intent. In the background, portals figure out the most optimal route, abstract the gas cost, and return asETH in your wallet. The path is figured out by the portal solvers.

We can break down the system into 2 core components:

1. Intent capture: This refers to how the user’s objective is interpreted by the system. Most intent-based systems use their own framework or domain-specific language (DSL) which is interpreted by the algorithm that figures out how to fulfill the intent (also known as solvers). Front ends are also part of the intent capture process, they help guide the user in generating the intent. Front ends like UniswapX, CoW swap, and others capture the user’s intent and then pass it along for execution.
2. Intent execution: The intent is captured in the form of call data and then broken up into logic modules which the algorithm (solvers) can process. The term solver is broadly used to represent any system that can fulfill a user’s intent. An algorithm as simple as a market maker could be considered a solver in an order book-type dex. The main point here is that solvers can do 2 things: 1) interpret and break down the intent into precise, executable logic and 2) that logic becomes a series of transactions that can be executed by the solver.

Intents have been around for quite some time but only became a buzzword earlier this year. Some have called it programable quotes, RFQ systems, coincidences of wants, and so forth. These have slightly nuanced definitions but ultimately optimize for the same thing: efficiently fulfilling users’ intentions. They solve for 2 things:

• User experience: The ability to conduct what was once a complex transaction in a simplified manner.
• Better counterparty & price discovery: The ability to get the most bang for your buck

Is it overhyped? Perhaps a tad bit, but for good reasons. Intents would allow us to achieve the user experience and liquidity of centralized systems in a relatively decentralized environment.

Intent Capture

In the initial stages, Intents are simply data and not transactions, therefore, a system needs to understand how to interpret that data. Most intent infrastructures such as Anoma and Essentials have developed their own DSL (domain-specific language) and others have proposed frameworks and standards to foster more composability across defi.

The drawback with DSLs is that a developer would need to reconfigure their entire system to integrate something like an anoma or essential on top of spending time understanding how that DSL works. Safe to say, this is not developer-friendly.

Other projects like BananaHQ & Router Protocol use an LLM-based model trained on vast data to interpret the intents and pass them along.

The BananaHQ team has also proposed a structure for better intent capture in the EVM called Abstracted Transaction Objects (ATOs). ATOs capture information relevant to a specific operation. Solvers then use this information to create optimized transactions tailored to the operation’s requirements.

There are also few EIPs highlighted by 0xRainandCoffee in a recent thread that may become more useful as we move towards an intent future.

For example, EIP-712 essentially allows us to have clear structure data when signing a message as opposed to just seeing bytestrings.

Intent Execution

Solvers are the algorithms that execute the intents, but there are still a few parties involved to ensure the intent is fulfilled. These parties can be the same entities although they are different algorithms or systems.

An intent is executed by the following systems working together:

• Application/Prompter: This is the system or front end that captures the intent
• Resolvers: This system breaks down an intent before the data is passed along to the solver
• Solvers: They create the transaction logic flow. Solvers can execute the transactions as well, provided they can tap into liquidity.
• Fillers/takers: This party provides liquidity for the intent. Market makers are fillers (they can also be solvers too!)
• Searchers: These are algorithms that are constantly on the hunt for MEV-extracting opportunities

Solvers

Since many things can be a solver and a solver does most of the computation for figuring out the path, we broadly use the term solver to mean the thing that fulfills the intent.

One confusing thing is when someone refers to a dapp as a solver. You might hear, “LI.FI is a solver, so is 1inch” – this is true because both LI.FI and 1inch have algorithms that are constantly looking for the optimal route once you plug in your intent. In the image below, you see the routes are presented, in this case, Circle CCTP, allbridge, and others are the fillers.

Generalized Solvers

Generalized solvers are purely algorithm that focuses on routing and executing the transactions. Solvers such as sea solver, rizzsolver, and others capture intents from an intent meme pool. As solvers mature, teams are designing creative API solutions to help Dapps abstract away complexity for users at every stage, and focus on delivering what the user wants with fewer surprises. A perfect example of this is the Portals.fi API, which allows users to “one-click” Zap to enter any Dapp. Yearn Fianance enabled Portals Zaps, and now their users can enter any Yearn position in a single click. Other similar API-based generalized solvers include Enso Finance and Propeller Heads.

Intent adapters

In the recent paper published by Router Protocol, they introduce the concept of intent adapters that would enable better execution and composability of intents. Intent Adapters are smart contracts that are pivotal for abstracting complex actions of dapps and enabling streamlined interactions, whether on a single dapp or across multiple dapps. Adapters are essentially the executors of the transactions derived from intents. They specialize in specific tasks such as bridging, swapping, staking, etc. on a single protocol or across myriad ones. Adapters give rise to a highly modular solution where developers can build upon existing adapters to accomplish more sophisticated transactions.

Example:

Staking 1000 USDC in staking PlatformA can be broken down into:

• Receive Funds
• Swap for the asset to be Staked
• Bridge to chain
• Stake on A

Each of these transactions interpreted from a vague intent is performed by an adapter specializing in the task of bridging, swapping, or staking.

Adapters themselves aren’t solvers, but instead, they are what solvers would use. The solver is what is threading these micro transactions together creating viable paths and then composing call data for the same using different adapters.

The past, present, and future of intents

Intents have been around for quite some time but it didn’t have the marketing finesse that VCs (sorry), marketing, and BD folks have added to it. CoW swap has had its version of intents implemented via batch auctions, 1inch fusion with dutch auctions, and so forth. Some other interesting early adopters of intent-based systems include:

• Across — Users submit cross-chain swap requests on the source chain, Solvers (also known as Relayers in this system) compete with each other to fill this order, and the winning Relayer successfully fronts capital to the user on the destination chain in exchange for user funds + fee.
• Connext — Users submit cross-chain swap requests on the source chain, Solvers (Routers) compete to fulfill the order on the destination chain by fronting the transaction funds on the destination chain.
• Squid – Users submit cross-chain swap requests on the source chain, Solvers (Relayers) compete to quickly fulfil the order on the destination chain by fronting capital from their own inventory.
• Debridge DLN – Users submit cross-chain swap requests on the source chain, Solvers (Takers) compete to fulfill the order on the destination chain by fronting the capital in exchange for a fee.

Where do we go from here?

Imagine a world where you submit an intent to arbitrage various liquidity pools across multiple chains while only having USDC on a single chain. Though we may be a bit away from that, the development and advancement at the infrastructure layer is promising to enable this. As these intent infrastructures mature, dApps will inevitably want to optimize for efficiency and better price execution to compete. We’ve already seen this with the introduction of UniswapX and others alike. As we move towards an intent-centric future, most existing intent infra protocols may need to be rethought to optimize for integration friendliness and composability which could unlock a new paradigm of price and trade discovery across defi.

The ecosystem

Special thanks to Arjun from LI.FI as well as members of the Portals and Router Protocol team for their assistance in putting this article together.

About Bankless Ventures

Bankless Ventures is a $40M early-stage Web3 Venture fund launched in 2023 to empower pioneers to explore the frontier of Web3.

If you want to invest in the Bankless Ventures fund, you can submit an interest form as a Limited Partner (LP):

https://docs.google.com/forms/d/e/1FAIpQLSd4CX1mmR3FBDhkxrky4QKNwvKbfBcTERMgKYZgfYE6nnD0Vw/viewform?ref=bankless.ghost.io

If you’re a startup that wants to be reviewed by our investment team, show us what you’re building here.

https://docs.google.com/forms/d/e/1FAIpQLSfSt0qkdfDMIWMJ2ZEsyfSDeKh4acon5JLzESs6MiGHmQeyjg/viewform?ref=bankless.ghost.io

Disclosure

The views expressed here are those of Bankless Ventures, LLC (“Bankless Ventures”) personnel quoted and are not the views of Bankless Ventures affiliates. Certain information contained here has been obtained from third-party sources, including from portfolio companies of funds managed by Bankless Ventures. While taken from sources believed to be reliable, Bankless Ventures has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; Bankless Ventures has not reviewed such advertisements and does not endorse any advertising content contained therein.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by Bankless Ventures. (An offering to invest in a Bankless Ventures fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by Bankless Ventures, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others.

Disclaimer：

1. This article is reprinted from [bankless.ventures]. All copyrights belong to the original author [KIMBERLY ADAMS]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.