With Intent to Scale
Thematic Analysis #12
The traditional construction of Ethereum transactions has often been a bottleneck to the scalability and usability of crypto, constraining UX significantly and limiting the expressiveness of users. However, a transformative shift is underway with the rise of intents-based architecture, which promises to simplify UX and make the use of digital assets more intuitive and accessible. Protocols like CoW Swap, Anoma, SUAVE, Essential, and Across are leading the charge, each contributing unique approaches to streamline and enhance user interactions. The integration of natural language processing within the intents framework represents the holy grail of intents, aiming to bridge the gap between complex blockchain operations and everyday language, ultimately democratising access to and usability of blockchain technology for all types of users.
This article will delve into innovations within the intents space, and explore how the emergence of intents-based architecture is laying the foundation for a more user-friendly and intuitive blockchain ecosystem.
Let’s dive in!
With Intent to Scale
Introduction 👋
This is the twelfth article in Genesis Block’s Thematic Analysis series. In this series, we talk about broader trends and emerging concepts in the crypto space, looking towards the future and analysing how Web3 is evolving in real-time.
This article explores the world of intents and how intent-based architectures and markets are set to transform crypto UX and take it to the next level, i.e., one where we can finally get onto the path to ‘onboarding a billion users’.
Glossary 🔖
As with my pieces on Zero-Knowledge Proofs and EigenLayer, this article is slightly technical, and it’ll be helpful to level-set on terminology and concepts first:
Ethereum Virtual Machine (EVM)
The Ethereum Virtual Machine (EVM) is a core component of the Ethereum blockchain, acting as a global, decentralised computer that executes and manages the operations of smart contracts. Essentially, the EVM allows for the execution of code in a secure and isolated environment, ensuring that programs run exactly as programmed without any possibility of downtime, censorship, fraud, or third-party interference.
State Transition
A state transition is the process by which the blockchain's current state (which includes all existing information such as account balances, smart contract code, etc.) is updated to a new state following the execution of transactions (a change to this existing information). This involves validating and applying changes proposed by transactions, such as transfers of crypto or execution of smart contracts, to the blockchain's ledger.
Transactions
Transactions are messages in a specific format that provide all the necessary information for the EVM to execute a state transition.
Execution Path of a Transaction
The sequence of steps that a transaction undergoes from its initiation to its final inclusion in the blockchain.
Maximal Extractable Value (MEV)
Maximal Extractable Value (MEV) on Ethereum refers to the potential profit that miners or validators can achieve by manipulating the order, inclusion, or exclusion of transactions within a block they produce. This manipulation allows them to capitalize on opportunities such as arbitrage or front-running. You can learn about MEV in-depth in our article here.
MEV Searcher
MEV Searchers on Ethereum are individuals or entities that use specialized software to detect and exploit opportunities for profit by manipulating the order of transactions in a blockchain block.
Gossip Network
A gossip network is a P2P communication method used by nodes within a blockchain network to quickly and efficiently share and disseminate information like transactions or block data with each other. This ensures that all nodes in the network stay updated and in sync, similar to how gossip spreads among people in a social network.
Slot Filling
Slot filling in the context of natural language processing (NLP) is a task where specific pieces of information, known as slots, are extracted from user utterances. This process is crucial for understanding and responding to user intents in applications such as voice-activated assistants, customer service bots, and other interactive systems. Slots typically represent essential data that the system needs to perform actions or generate responses based on the user's request. As an example:
Query: What flights are available from Mumbai to London on the morning of Tuesday 14th May?
Intent: flight information
Slots: from_city: Mumbai; to_city: London; depart_date: 14th May; depart_time: morning
Domain-Specific Language (DSL)
A domain-specific language (DSL) is a type of computer language that is tailored to address problems and tasks within a specific domain. DSLs focus on a narrow set of problems, making it easier for users to work within that specific area.
How Do Ethereum Transactions Work Today? ⚙️
Users usually sign and initiate transactions from their wallet, where the execution path contains the contract being called and the actions being taken. The transaction then goes into the public mempool (i.e., queue of transactions ordered by fees paid to include that transaction in the blockchain), and the exact execution path of the transaction depends on the order in which transactions get executed.
Once a transaction is selected for execution, it passes a message to a smart contract that holds a piece of code and storage. The contract takes the message as an input and executes the code step-by-step. As the state on that smart contract changes, either another smart contract is called, or the execution ends if the transaction has terminated, or it runs out of gas. Ethereum transactions arbitrarily transition the state depending on the execution path, which means that the system can perform a wide range of computations and updates to its state, based on the conditions and rules defined within the smart contracts.
The issue with Ethereum transactions today is that creating a transaction on Ethereum is quite complex, requires a developer to reason about a huge number of smart contracts and granular details, and requires the user to hold a specific asset to pay gas fees. This complexity results in a degraded UX and reduced efficiency since users cannot readily access sophisticated execution strategies. Also, a transaction refers to ‘how’ an action must be performed, rather than directly outlining ‘what’ the desired outcome of that action should be. This causes a lot more hoops to be jumped through – for example, if a user says, ‘swap 3,000 USDC for 1 ETH’, then the transaction interprets it as ‘I want to exchange 3,000 USDC for exactly 1 ETH’, i.e., ‘do A, then B, then C, and then pay exactly 3,000 USDC to get 1 ETH back’. This is a lot more hoops than simply saying ‘I want 1 ETH and I am willing to pay up to 3,000 USDC for it’. While the former method specifies a specific computational path to be taken and allows for only one specific state transition to take place, the latter enables the use of any computational path if certain constraints are met and allows for any set of state transitions to take place to achieve the action.
Transactions, therefore, are not very expressive. They do not let the user apply any constraints like, for instance, ‘transact only on DEXs which require KYC’ or ‘ensure as low slippage as possible’. This leads to a limited UX and is the root cause of many of the complaints we have seen around crypto being confusing and difficult to use. A system where a user simply says, ‘I want A, B, and C at a max price of D, E, and F, respectively, keeping in mind constraints G and H’ and clicks ‘submit’ will unlock a much more intuitive UX (and UI) for crypto and reduce the barriers to entry for both casual and professional users.
This is what intents enable.
How Do Intents Work? 🦾
Intents enable users to express a desired outcome and outsource the task of finding the best way to achieve that outcome to sophisticated third-parties called ‘solvers’ that compete to execute the intents. Once an intent is submitted by a user via a wallet, the transaction is either sent to the mempool or directly to block builders to include in the block for faster execution. In the mempool, MEV searchers scan for the intents and look for the optimal route for intents to be executed and earn themselves the highest profit possible. The searchers either choose to solve the transactions themselves or sell the information to solvers. Usually, MEV searchers both discover opportunities and act as solvers. Solvers compete against each other to find the best transaction execution, i.e., the cheapest and quickest solution to their intents, and the solver that wins earns a fee. Solvers aggregate multiple intents into bundles to enable them to be executed in a single transaction and forward the bundles to block builders, who then select bundles, package them into blocks, and send them to validators for inclusion on-chain.
It would be easiest for intents to get propagated to MEV searchers or solvers via the Ethereum mempool; however, the current mempool design does not support this and therefore alternate solutions for the propagation of intents need to be found. Some designs are:
Permissionless Mempools: A decentralised API that enables intents to be gossiped (i.e., communicated P2P) across nodes, allowing any node to execute the intent. However, it is tricky to execute such ‘permissionless intent pools’ in practice, primarily due to game theory. Nodes operating these intent pools have an incentive to not propagate in order to reduce competition for executing the intent, since executing an intent is a profitable activity. By not sharing the intent with other nodes, minimising competition, and increasing their own chance of capturing the profit, this could lead to centralisation in the intent system and to worse outcomes for users due to lower competition.
Permissioned Mempools: Using a trusted, centralised API where the intents are all shared among a group of trusted nodes. These nodes have reputations to uphold and will have the incentive to provide the best execution possible. However, this again could lead to centralisation in the intent system and lower competition.
Hybrid Model: Have permissioned propagation (i.e., go through a centralised API to share intents), but all nodes can then compete to execute the intent.
The ideal intent system would be permissionless, where any node can execute intents without trading off on the quality of execution; general, where new mempools do not need to be created every time a new application is deployed; and transparent, where the process by which intents are executed is public and the quality of execution can be audited in the open.
Use Cases 💼
Given how transformative intents will be in transforming crypto UX, the potential use cases are vast:
Auctions
Market makers or sophisticated users can place expressive bids based on their unique needs. For example, they can place a bid to buy items A and B at $12 for the package, but only at $5 each individually since they are complements; or buy as much USDC possible with 1 ETH; or sell at most 5 units of item A, pricing it differently for various counterparties.
P2P Lending
A lender can specify the type of collateral they will accept (e.g., only US t-bill products), Loan to Value (LTV), Liquidation Threshold (LT), and borrow rate, and be matched with appropriate borrowers.
Crowdfunding
For example commit to fund a project if it only receives investment from ‘wallet X’, or it has already received investments of, at minimum, 50k USDC, or in GitCoin Grants where users can pre-commit to donating to the winning projects at the start of the round.
Range Orders
Buy a token only when it is within a specific price range.
Private OTC Sale
Have a private intent where I am willing to sell my assets to anyone willing to pay above market price. The counterparty may have a private intent to buy the asset at a price slightly above market price if liquidity for the asset is thin in the DEX. Given both intents are private, they can be matched privately and filled automatically without adversely impacting market liquidity.
Multi-Chain Trades
If a user wants to buy an NFT on Solana but pay in ETH on Arbitrum. Intents allow for transactions from any chain.
Portfolio Construction & Optimisation
If a user wants to optimise yield from the least risky Actively Validated Services (AVS), with ratings drawn from an AVS rating system akin to Rated Network or in a TradFi context, Moody’s or S&P. The intent could specify the creation of a portfolio with a specific Sharpe ratio and the execution would involve buying various AVS tokens and bundling them up that meet the portfolio requirements.
Risk-Reduction
Sell a token if a certain condition has been reached, e.g., a stablecoin is 0.2% below peg.
Security Screening
Only allow interactions with smart contracts that have on-chain proofs of being audited by two security auditors on a whitelist of ‘reputable audit firms’.
The Ideal Intent System: Intents with Natural Language 🗣️
At the moment, intents are only expressed through more traditional interfaces, such as the one below from UniswapX:
However, this interface is not necessarily the most intuitive. It would be much easier to simply write, ChatGPT-style, ‘I want to buy 0.5 ETH when, at maximum, 1 ETH is worth 3,000 USDC. Buy the ETH only from Uniswap, Curve, or Balancer’. Broadly, this can be done by accessing a set of natural language models on-chain for intent recognition and slot filling. These models would reduce every intent to a Domain-Specific Language (DSL), which includes the core intents like ‘buy’, ‘sell’, ‘bridge’, ‘send’, ‘borrow’, ‘lend’ (i.e., actions) and has other slots which provide context like ‘address’, ‘size’, ‘slippage’, ‘wallet address’, ‘chain_name’, ‘time_limit’, etc. Once an intent has been expressed, for example, ‘buy as much ETH as you can with 3,000 USDC in the next 6 hours’, it goes into the pool of intents, passes through the natural language models, and is then resolved to a DSL with details like the intent, sub-actions, and slots needing to be filled. Solvers then operate as usual when picking up the intent from the pool. How this works in practice can be seen in the below diagram from this article:
The below tweet also shows how an eventual NLP-based intent system could potentially work:
Intents in Practice 🌏
To begin with, the below intent-focused landscape from 0xRainandCoffee is a good overview of the ecosystem today:
The ecosystem consists of various types of protocols:
We’ll take a walk through some of the most prominent intent-based protocols in the market today.
CoW Swap
CoW Swap is a DEX that uses a unique ‘batch auction’ mechanism for price finding, rather than the current immediate execution model used by traditional AMMs. Batch auctions aggregate orders off-chain and settle them in batches, which allows for the establishment of uniform clearing prices across all trades in a batch. This enables gas price optimisation through the settlement of multiple trades simultaneously, and also eliminates issues like front-running. There is open competition amongst solvers to submit the best execution, most efficient order settlement solutions, which is ultimately better for users.
CoW Swap is called CoW Swap since it finds ‘coincidences of wants’ among orders. Coincidences of wants are direct P2P settlements; for example, let’s say Person A wants to swap AAVE for USDC; Person B wants to swap USDC for ETH; and Person C wants to swap ETH for AAVE. In this scenario, CoW Swap’s solvers would identify this ‘ring trade’ and facilitate the exchanges directly among the traders without needing external liquidity from AMMs, optimising the use of on-chain liquidity and reducing transaction cost. Moreover, given that ring trades and batch auctions involve multiple assets in trades, the batch auctions can access more liquidity than isolated pools on AMMs. Solvers can then use on-chain AMMs or aggregators like 1inch to find the best execution route.
CoW Swap has recently introduced a feature called CoW Hooks, which allow for the execution of additional custom-coded actions either before or after trades, enabling more complex transaction sequences, like combining token swaps with other DeFi operations like staking or bridging, all within a single transaction. Traders authorize these actions through off-chain messages or transactions, paying fees in the traded tokens instead of ETH for gas, which adds to CoW Swap’s cost-efficiency and user-friendliness.
Anoma
Anoma is an intent-centric architecture in which users submit intents that are propagated across an intent gossip network. Solvers observe the intents from the gossip network and aim to combine relevant intents into transactions that can then be settled on-chain. The transactions are submitted to an encrypted mempool using threshold cryptography to avoid any issues with front-running. Anoma’s intents are signed off-chain messages that authorise multiple future states. So, if a user signs an intent saying ‘I want to exchange 1 ETH for 3,000 USDC’, according to Anoma the user is actually saying ‘I want 1 ETH less and at least 3,000 USDC more and I don’t care what route is taken to make that happen’.
Anoma’s intent gossip network is ‘path-authenticated’. In practice, let’s say Solver A spots two intents, one aiming to exchange 1 ETH for 3,000 USDC and the other aiming to exchange 1,500 USDC for 0.5 ETH. These are not fully balanced, i.e., combining both intents will not lead to both intents being fulfilled. Solver A can choose to wait for new intents to come in to form a full solution, but this is risky because if Solver B finds the full solution, A will lose out on fees. Path authentication enables Solver A to do as much of the work that is possible at that moment in time and prove their effort to the network. They can come up with a partial solution which leaves 0.5 ETH to be exchanged for 1,500 USDC, put a partial (50%) claim on the fees, sign a message to prove their work, and pass the partial solution to other nodes for them to continue the solving process. In this system, solvers no longer need to spend computational resources without a guarantee of getting paid. Once a full solution has been found, transactions are verified to be settled on-chain.
The Anoma architecture is generalisable and any chain can implement it. A chain implementing the Anoma architecture is called a ‘fractal instance’ of Anoma, and all of these chains share a certain set of standards. Slightly confusingly, one of the fractal instances is being built by the Anoma team as an IBC-enabled L1 Proof of Stake chain and is called…Anoma. The below diagram may make this a little clearer:
As the number of fractal instances grow, so does Anoma’s scalability, since all fractal instances share Anoma’s intent gossip network. Therefore, more and more intents get gossiped, providing a larger surface area for compatible intents that can be balanced at the first go. This increases the rate at which intents get executed and therefore further improves UX.
SUAVE MEVM
Flashbots is best known for its MEV-Boost solution, which mitigates the negative externalities of MEV on Ethereum by enabling validators to access a competitive block-building market. Flashbots is now building SUAVE (Single Unifying Auction for Value Expression), which aims to further decentralise the MEV supply chain via mechanisms like privacy-aware order-flow auctions and decentralised block building. SUAVE’s development also includes the MEVM, which is a specialised version of the EVM that enables MEV applications to be created as smart contracts. The MEVM has 3 components:
Universal Preference Environment, a chain and mempool which enables the creation and aggregation of intents across chains;
Optimal Execution Market, where solvers compete to provide best execution;
Decentralised Network of Block Builders who merge intents into blocks.
SUAVE uses a dedicated chain for settlement and as a messaging layer. MEVM works in the following way:
Users submit intents by writing EVM-compatible code on the SUAVE platform.
Users bridge funds to the SUAVE chain in order to benefit from cost-efficiency and enhanced privacy.
Solvers (usually MEV searchers and builders) devise optimal execution strategies that maximise value for users. They participate in a competitive process similar to a Dutch auction where they propose solutions based on user constraints.
The solver that first identifies a viable solution is selected and then executes the intent by coordinating the execution across the relevant blockchains. To facilitate transactions across different blockchains, solvers may use bridging services or cross-chain communication tools.
Oracles and SUAVE validators then validate the transaction; oracles provide the data confirming that the transaction has been executed correctly, while validators record the transaction on the SUAVE blockchain.
The benefits of SUAVE MEVM are that solvers inherently possess both solving and block building capabilities, which speeds up the process of the intent getting fulfilled. Moreover, having all contracts that solvers need to interact with on the SUAVE chain increases cost and fulfilment efficiency. Bridging funds to the SUAVE chain also enables users to participate in cross-chain MEV applications. One issue with SUAVE could be the requirement to bridge funds to the SUAVE chain, which adds friction to the user experience. Abstracting this away during the intent-writing process is crucial to ensure that the only action the user takes is to write the intent. The good news is that Flashbots is exploring techniques to minimise bridging funds, potentially via only major searchers or builders needing to maintain a balance on the SUAVE chain, ideally only enough for working capital.
UniswapX
The core feature of UniswapX is the Dutch auction it utilises to determine trade prices. The order executes at a price that depends on the time of its inclusion in a block and starts at a price estimated to be better for a swapper than the current market price, and then decays until it hits the worst price a swapper would accept. UniswapX’s solving process, validation, and settlement is similar to that of CoW Swap.
Solvers are incentivised to fill orders as soon as it is profitable for them to do so. For example, if the current market price is 3,000 USDC per 1 ETH, a sell order would start at 3,100 USDC per ETH, and then decay to, let’s say 2,950 USDC per ETH until a solver accepts the order. UniswapX is a very flexible system – users have the freedom to define parameters like the initial Dutch order price and the decay function, and can also enable orders to specify solvers that receive the exclusive right to fill the order.
The solver who wins the Dutch auction commits to filling the order and has to deliver the specified number of tokens within a fixed amount of time. If the solver does so, the transaction is settled, and the solver receives a fee for their efforts. If the solver does not deliver the assets, they are penalised and the user’s trade is sent to the Uniswap DEX for fulfilment (i.e., via liquidity pools).
Essential
The multiple solutions tackling intents today do not have a standard mechanism for expressing and composing intents. Having a standardised format for both, creating intents and reasoning about them, enables the wider propagation of intents and makes it easier for developers to start building intent-based systems. Essential is building a universal DSL for intents that is optimised for solving, i.e., solvers can reason about intents using the same language they are written in. Essential has proposed ERC-7521, a standard that supports generalised intents for smart contract wallets. Intents are signed as messages that are verified on-chain and then gossiped in their own mempool.
Essential’s protocol is tailor-made to ingest only intents, and users cannot submit transactions. Rather, the protocol enables intents to be solved in batches, and each new block is just a solution to a batch of intents. All intents are routed through the exact same solver network, which gives them the maximum possible information and control over how to solve that batch of intents. They can therefore leverage multiple liquidity venues, identify coincidences of wants amongst the intents, and optimise for the best user outcomes.
Essential has also developed the Asset Based Intent Standard, which makes it simpler to express intents that cover actions like token swaps or portfolio rebalances, but also more granular constraints, such as a user wanting to buy an on-chain collectible by paying in SOL but using USDC for gas. This makes it much more straightforward for developers to start solving for all kinds of intents and increases the scalability of the intent ecosystem.
Across Protocol
Across is a bridge that, due to its intent-based architecture, provides a significantly cheaper (up to 75%) and faster (up to 90%) experience than most other bridges on the market. Across has 25-30% market share within the third-party bridging market and 10% of the overall bridging market.
Across works by aggregating liquidity in a main pool on Ethereum. Relayers across multiple chains front liquidity to users (i.e., relayers make the payment to users on the destination chain) and are reimbursed via the main liquidity pool on Ethereum. Across uses UMA’s optimistic oracle (i.e., an oracle network that assumes that data proposed by users is accepted as true unless disputed within a specific timeframe) to identify the amount to reimburse. Batching enables greater capital efficiency, faster bridging speeds, and lower gas fees. Reimbursing all relayers from one pool also enables Across to avoid setting up liquidity pools on multiple chains and incentivising and paying liquidity providers for all of them. Using UMA’s optimistic oracle also enables lower source and destination gas fees compared to its competitors, since Across does not need to rely on expensive on-chain validations. Moreover, batching all gas fee reimbursements by bridging funds in larger transactions saves costs for users.
Across charges 10-15bp of total fees, which is entirely passed on to liquidity providers and relayers. If Across decides to capture a percentage of the total fees (say 1/3rd), it can put in place a solid monetisation strategy that can be passed on to the Across DAO and token holders. Across’ capital efficiency can be demonstrated by each dollar of TVL in Across being turned over 70-80x annually.
All in all, Across is a great example of how intent-based systems are much more efficient, cheap, and user-friendly than the systems we have in place today.
Risks and Challenges ⛔️
One of the biggest risks associated with intents is that decision-making is outsourced to third-party block builders and solvers. Users need to place trust in these entities, and it is critical to ensure that execution of intents is not covered by a small, centralised, oligopolistic group. If this ends up happening, this group could control terms and prices, censor transactions, prioritise some intents at the expense of others, etc. This could lead to continuously decreasing competition and higher costs for users. Unfortunately, data from a research paper led by Tarun Chitra from Gauntlet shows that some of this may already be happening. For example, on UniswapX, the top 3 solvers already account for ~79% of daily volume transacted, while the number of entrants into the auction has reduced significantly, with only 12 unique addresses participating in the auction as solvers in January 2024, down from a peak of 2,000. A caveat is that in these early days, the solver role is permissioned by Uniswap Labs, but the steep drop from 2,000 to 12 indicates high barriers to entry and sustained competition within UniswapX.
A second key challenge is that new security threats may arise from intent-based architectures. For example, a user may accidentally grant access to their accounts to malicious solvers, or leak personally identifiable, private data to them that may cause privacy issues. Moreover, widespread adoption of intents could lead to user activity shifting to a number of alternative mempools, and if these are not scrutinised diligently, could risk centralisation and adverse impacts on users due to high fees. There are too many mempools and middlewares being built currently which may lead to a more opaque and indecipherable system.
It is also crucial to ensure that access to intents and order flow is socialised and democratised over a critical mass of block builders and is not concentrated in the hands of one or two builders. If one or two builders gain access to a critical mass of order flow, they could be in a position to censor transactions or extract high fees. In the worst case, if there is a monopolistic block builder, they can extract rent and reject any new proposal for how intents should be processed, stalling traction and leading to an unhappy stalemate for users.
Lastly, a niche risk may be if the execution trace of a transaction may be required for legal or regulatory reasons. If a user submits an intent and a solver executes the transaction on their behalf, there is no proof of the user submitting that transaction. However, this is an issue with all transactions conducted via account abstraction as well, so this may be a wider problem that the ecosystem may need to tackle if it comes up.
Closing Thoughts ⌛
The introduction of intents has the potential to transform crypto UX and make it much simpler for existing and new users to engage with the blockchain landscape. The demand for these types of applications is clear, but it is critical for the space to evolve in a democratised, decentralised manner and, at all costs, avoid the centralisation of power in the hands of a few actors. Any intent protocol that wins out should provide a balance between privacy, decentralisation, and transparency, all the while enabling as much efficiency and improved UX as possible.
Bibliography 📖
Decoding Intents: Revolutionizing Web3 User Experience and Orderflow in Blockchain
Introducing ERC-7521: Generalized Intents for Smart Contract Wallets
Disclaimer
This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the article authors and do not represent those of people, institutions or organizations that those authors may or may not be associated with in professional or personal capacity, unless explicitly stated. All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual.
👇🏽 please hit the ♥️ button below if you enjoyed this post.