Introduction

Intent-centric networks are a new branch of infrastructure focused on altering the way global state is updated on transaction-based distributed state machines such as Ethereum. At its core, Ethereums fundamental innovation was Turing-complete programmatic settlement expanding on the limited scripting offered by the Bitcoin protocol UTXO settlement model. Parties and counter-parties could now interact without the need of an intermediary by leveraging smart contracts for deterministic settlement logic that mediated the transaction under the programmed settlement conditions. Programmatic settlement despite its immense merit has resulted in a suboptimal UX for the average user requiring users to validate transactions ensuring the parameters result in their desired action. This has resulted in undesired outcomes such as asset theft and in many cases suboptimal execution for their desired behaviour.

Intents offer a new alternative to update global state without the need for end users to verify every transaction parameter before executing a state transition. Instead, Intents only require users to specify what they want to accomplish under a set of conditions and the transaction building is outsourced to sophisticated entities known as solvers who find the most optimal execution path for the users intended action. We believe that intent-centric protocols set the foundations for improving end user UX when performing actions on-chain, significantly reduce the occurrence of asset theft, provides the infrastructure for superior on-chain execution especially when it comes to trading specific actions and overall reduces the mental overhead needed for the average user when interacting with Web3 applications.

Below we will outline the difference between the transaction-based model and the intent-based model, the purpose of solvers in intent-based networks, how applications can leverage intents to improve the end user experience and the underlying architecture of intent-centric protocols such as Anoma and Essential.

Distributed State Machines & The Transaction-based Model

The Ethereum Network at its core is a distributed state machine. The state is global and represents all of the information associated with externally owned accounts (EOAs) controlled by Individuals and contract accounts (autonomous deterministic smart contracts to mediate settlement logic). The global state of Ethereum is updated by users broadcasting transactions via the peer-to-peer (P2P) Network, processing the state transition using the Ethereum Virtual Machine (EVM) and achieving finality by including the transaction in the latest block.

Transactions on Ethereum specify a party, counter-party and data to describe the parameters associated with the settlement logic. To illustrate this, let’s take a look at a transaction object of the simplest form on Ethereum. A user sending ETH to another EOA:

{
  from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
  to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
  gasLimit: "21000",
  maxFeePerGas: "300",
  maxPriorityFeePerGas: "10",
  nonce: "17",
  value: "27000000000"
}

In the transaction object above, the ‘from’ attribute represents the party and the ‘to’ attribute represents the counter-party respectively. In terms of settlement, the ‘value’ attribute specifies the value of ETH to be settled. In more complicated transactions where Individuals interact with smart contracts, an input data field is present that specifies the smart contract function to be called with its associated arguments. This field outlines the transaction settlement logic inputted to the smart contract. The smart contract then mediates the settlement on the users behalf. To summarise, the transaction-based model of Ethereum requires users to specify their counter-party and the relevant settlement data required to achieve the desired post-state.

Transactions vs Intents

Now that we have recapped the fundamental process of state transitions, we can now clearly define the difference between transactions and intents. The goal of transactions and intents is to update the global state of Ethereum but the difference is how they update the global state. Transactions specify the execution path needed to achieve the desired post-state. Intents specify the desired post-state without expressing the path defining how to achieve it. To explain this in laymen’s terms:

’Intents are what users want to do and transactions are how to get there’

Illustration showing how intents abstract away counter-party discovery.

The best way to think about the difference between transactions and intents is counter-party discovery. In a transaction based model, counter-parties are specified explicitly in terms of what account (EOA or SC) the party is interacting with and under what settlement conditions. In an Intent-based model, the counter-party is not defined and is instead outsourced to entities known as ‘solvers’ who then discover and select the most optimal counter-party given the users required settlement conditions.

Illustration showing a transaction-based execution path and an intent-based execution path.

The simplest example of this is a user wanting to swap X amount of an ERC20 token to ETH. In this example, the user has two choices for their desired action:

Directly interact with the Uniswap V3 front-end that matches the party with the liquidity provider counter-parties in the Uniswap liquidity pool. User has to verify the transaction and sign it for execution.

Utilise an Intent-centric DEX such as CowSwap which will compute execution outcomes on all relevant DEXs finding the most optimal execution path for the user that adheres to their defined limit price and slippage tolerance. User only has to sign for execution and does not need to verify.

We can immediately see the benefits in terms of UX for the end user when expressing intents versus validating and signing transactions. Counter-party discovery is seamless, validation of the path to get to the desired post-state is redundant for the end user and malicious computational paths that could result in fraud are largely negated. To summarise, Intents differ from transactions via their outsourcing of the execution path to achieve the desire post-state under signed conditions set by the end user.

Solvers & Counter-party Discovery

Solvers at their core are the entities who construct the most optimal execution path for users intents. They facilitate the process of counter-party discovery and matching to execute the intent under the specified conditions signed by the user. Solvers then build transactions using the intent and the selected execution path in order to update the state on the transaction-based distributed state machine. There are parallels to be drawn from intent-based networks and market auction theory that underpins the functioning of financial markets.

Auction market theory states that market participants are engaging in a continuous auction process declaring bids/asks for an asset and the sum of the actions by those participants finds the assets fair market price. Central limit order books (CLOBs) are the best known architecture to facilitate the auction market process. Limit orders are resting liquidity where traders signal their intent to purchase or sell an asset as a specified limit price. The CLOB matching engine then matches a party and counter-party at that specified limit price and the trade is executed.

As you can see the market auction process is market participants submitting their intents to the exchanges matching engine. Solvers very much behave like a matching engine on-chain but they are not limited to the information of a single orderbook. Instead, they aggregate all of the real-time data for liquidity pools present on multiple execution layers and off-chain liquidity via their own inventory or connected OTC desks. DEXs have slowly begun to move in the direction of intent-based designs and we believe this trend is set to continue resulting in significantly improved end user experience, the most efficient price execution and end user MEV protection from malicious forms of DEX native MEV.

Cowswap

CowSwap is a pioneer in intent-based DeFi infrastructure and it’s incorrect to refer to CowSwap only as a DEX aggregator. In our view, CowSwap is the 2nd generation of Decentralised Exchanges with it’s novel peer-to-peer matching and its mandatory MEV protection. To understand CowSwap and intents its best to outline the entire user flow when executing an asset swap:

The execution flow of the Cowswap intent-based batch auction coincidence-of-wants matchmaking.

Users submit their intents that are collected off-chain in a batch style auction. Users sign their intent to swap asset X to asset Y at a specified limit price and slippage conditions.

CowSwap solvers compete to find coincidence-of-wants in the batch auction. Meaning if a users swap intent overlaps with another users swap intent then a peer-to-peer swap will be executed instead of taking liquidity from an AMM liquidity pool. This greatly improves price execution.
Excess unmatched liquidity in a batch auction then seeks liquidity utilising the CowSwap routing algorithm to seeks best execution across integrated DEXs and DEX aggregators.

CowSwap solvers compete against each other to find as many coincidence-of-wants in a batch auction to provide users with the best possible price execution. Users outsource the execution path for seeking liquidity to settle their swap to the solvers of the network. As we can see, CowSwap is providing the best price execution for DEX traders, abstracting away the complexity of optimal counter-party discovery and also provides protection against malicious forms of DEX MEV such as front-running and sandwich attacks.

UniswapX

UniswapX is another recent innovation in DEXs transitioning from a transaction-based model to an intent-based model. The innovation in DEX design has accelerated since the inception of Uniswap V2 resulting in substantially more liquidity pools across multiple trading avenues plus liquidity fragmentation is set to further increase as more rollups are deployed on Ethereum.

In terms of functionality, UniswapX is outsourcing the routing between traders and liquidity providers to external parties which we can call solvers. UniswapX is offering superior pricing for traders, gas-free swaps, MEV protection, no gas costs on failed transactions and eventually gas free cross-chain swaps. Essentially, the routing process is going to be completely abstracted away for end users.

We can envision a world where traditional financial institutions enter the DeFi application layer as solvers providing the most optimal routing algorithms and also providing off-chain liquidity via their own inventory similar to the operations of an OTC desk. We believe this is a natural path forward given the continued fragmentation of liquidity between DEXs and execution layers.

Intent-centric Network Architecture

Intent-centric protocols such as Anoma and Essential are separate networks that live outside the base security layer responsible for transaction settlement. They are designed to batch users intents on a per block basis allowing solvers to create the execution path for that blocks set of intents. The transactions submitted by solvers on the users behalf are then verified on the underlying layer-1 or rollup.

An Intent-based network interacting with a transaction-based settlement layer.

Intent-centric protocols have a P2P network for intent gossiping which serves as a mechanism to pool together user submitted intents. Solvers serve as entities who are searching for overlapping intents by monitoring the pool of intents created by the intent gossip nodes. The methodology these matchmakers employ is entirely flexible. Solvers are also in competition with one another which is an important incentive design aligned with further improving the matchmaking between overlapping intents submitted by users. Large language models (LLMs) trained on datasets consisting of a large bodies of transactions could be leveraged by matchmakers in which human readable intents are submitted to the LLM that then constructs the relevant transaction under the context of real-time data available to solvers.

The design space of intents is much broader than the application specific swap intents used for counter-party discovery in DEXs as demonstrated by CowSwap and UniswapX. Intents can be used to automate on-chain actions after a specific data driven event is triggered that then satisfies the users intent conditions. For example a prop fund only wants to execute a TWAP algorithm given a certain % deviation from the daily mean reversion value of an asset currently exclusive to DEX trading venues.
Another example be a time-based event, in which solvers are granted permission to transfer all users assets within a wallet to a back-up wallet if there are no executed transactions in 365 days acting as a mechanism for asset recovery. The use cases of intents has a vast design space that is yet to be explored beyond the swap specific intents. Therefore, it’s important to ask who is building intent-centric infrastructure. Let’s explore below.

Anoma

Anoma is an intent-centric network focused on building standardised infrastructure for intent expression, counter-party discovery, solvers and intent-centric settlement. The protocol architecture is designed around two fundamental principles:

Intent-centricity: Anoma’s architecture is centred around programmatic Intents where end users sign off-chain messages declaring what action they want to accomplish. Intents are a declarative paradigm in which end users can interact with a protocol, specify what they want to execute without understanding the entire execution flow.
Homogeneous architecture & Heterogenous security: TCP/IP defines layers of the internet protocol in a standardised format but leaves to the users who they want to connect to and what data they want to entrust to them. Anoma like TCP/IP defines a standardised intent-centric architecture for counter-party discovery, solving and settlement. Whilst allowing end users to choose who they want to interact with and the information they want to exchange under the definitions of a standardised protocol.

Fractal Instances of Anoma connected to the global instance that underpins the homogenous architecture & heterogenous security design principle.

Anoma at it’s core is a peer-to-peer (P2P) network of nodes that participate in gossiping intents, searching for solutions and voting in consensus. The intent gossip layer acts as a mechanism to disseminate intents between nodes so that solvers have all of the available information to construct the most optimal execution paths for each intent via implemented solver algorithms. The Anoma protocol can be thought more like a framework than a standalone blockchain; where there can be several ‘Anoma Instances’ as a layer-1 or a layer-2 that shares the same standardised protocol rules.

The important fact in which Anoma differentiates itself from standard monolithic layer-1’s is that counter-party discovery is built directly into the protocol via the solvers who act as transaction builders for the anoma intents. The gossiping of intents spans between Anoma instances creating a sort of global intent layer between the fractal instances.

Lifecycle of intents in the Anoma system.

The Anoma architecture is also designed to provide privacy for user interactions via shielded intents subject to the preferences on the end user. For example, an early fractal instance of the Anoma protocol focused on asset-agnostic shielding via a MASP circuit so assets can be shared within the same anonymity set. Solvers also encrypt transactions before submitting them to the mempool via a distributed key generation and threshold public key encryption scheme known as Ferveo. In laymen’s terms this mean the transaction data is shielded from block builders eliminating front-running or any form of transaction censorship.

Essential

Essential is another intent-centric network with a different approach to Anoma specifically when it comes to standardised intent expression and natively allowing EVM-based networks to seamlessly integrate with intents via Account Abstraction. In order to understand the differences in more detail, let’s break down the core innovations behind Essential:

DSL for Intent Expression: DSL or Universal domain-specific language is a constraint-based programming language that standardises the format in which intents can be expressed. In order to achieve ecosystem-wide composability for intent-based applications, DSL provides a universal way to construct intents for application level developers and to allow solvers to reason about intents in the language that they are expressed in.
Intent-centric Account Abstraction: Essential are introducing a new EIP for intent-centric account abstraction in order for solvers to have permission from the end user to execute on-chain operations on a users behalf. This will allows users to enjoy the benefits of intents and avoid the complexities of transaction-based systems when interacting with an EVM blockchain.
Modular Intent Architecture: Essential is building a modular architecture design so they can focus on certain aspects of the stack when optimising intent-based execution. Essential is an intent-only protocol meaning it only accepts intents so solvers can reason more effectively when searching for overlapping intents, ensuring that orderflow aggregation remains transparent and ensuring solvers are incentivised to return value back to users instead of extracting it for themselves.

PropellerHeads

PropellerHeads is focused on protecting end users from malicious DEX native MEV and offering the best possible execution for on-chain swaps. In order to reduce complexity of optimal on-chain execution for the end user, PropellerHeads is embracing an intent-centric approach outsourcing execution path selection to their own solver all of which can be accessed via the PropellerSDK.

The PropellerSDK offers two products being the Solver API to provide best in class swap execution from aggregated liquidity sources and a Private RPC endpoint to protect end users from malicious MEV such as sandwich attacks and front-running.

Behind the Solver API is a liquidity network which has access to block-by-block information on liquidity pools from major DEXs, market makers, cross-chain liquidity sources, outstanding limit-order books and OTC traders. This is the information backbone to construct the most optimal execution path for a users swap focused intent. The Propellerheads solver also searches for coincidence-of-wants between intent batches for P2P matching plus sophisticated routing algorithms to search for optimal trade routes.

The PropellerRPC is an RPC endpoint that allows users to submit on-chain swaps whilst protecting them from malicious forms of DEX native MEV. It does this by submitting orders to all available builders and monitoring builders for malicious behaviour. If malicious behaviour is detected then builders are automatically blacklisted.

A New Era for Programmatic Settlement

Fraud Prevention

The application layer of distributed state machines is plagued with fraud and asset theft. Why does this happen? In reality, it’s very simple to explain. End users are verifying an execution path that they think results in their desired post-state but in fact leads to an undesired post-state. In Laymen’s terms, an undesired outcome from their original intent.

The core of this problem is assuming all users have the technical competency to protect themselves against signing malicious execution paths. The reality is they do not. Therefore, abstracting away the execution path verification to more competent entities like solvers reduces the mental load users have to go through when transacting on-chain. We believe intent-centric models have the potential to mitigate a significantly large portion of fraudulent activity on-chain. In our view, this is an essential obstacle to overcome if we are to progress to the next stage of consumer adoption.

Abstracting away Execution Complexity

There are several forces which are driving fragmentation in the application layer which overtime will inevitably result in suboptimal execution for end users as the number of possible paths of execution increases. Abstracting away the execution path to solvers becomes immediately apparent when you understand the forces that drive fragmentation are only set to increase. The forces are the following:

Application-level innovation: Engineers are in constant debate over the best protocol design. Innovation in a vertical leads to multiple protocol instantiations in the same execution layer. Take for example decentralised exchanges; more DEXs means an increased number of liquidity pools in different trading avenues. As this number increases it becomes increasingly difficult for the end user to find the most optimal liquidity pool to execute their swap and achieve the best pricing.
Expansion of execution layers: As distributed state machines such as Ethereum scale, there will become an ever increasing amount of rollups on the Ethereum base layer. Many of these rollups are generalisable with multiple applications on the same execution layer such as Optimism and Arbitrum but there is also desire for application-specific rollups enable by rollup-as-a-service infrastructure. We view execution layer fragmentation over time will only continue to increase.

The Consumer Layer: Account Abstraction & Intents

As discussed above, the current consumer interface to transaction-based applications suffers from several flaws such as mental overhead associated with transaction verification and the possibility of asset theft if users verify the incorrect execution path. We believe that account abstraction coupled with intent-centric protocols such as Essential will provide the basis for the future consumer layer users will utilise when performing actions on-chain. Account abstraction has multiple benefits for the end user:

Signature Abstraction: No longer needing users to digitally sign transactions using the elliptical curve digital signature algorithm (ECDSA) from private key for every user operations. Users can instead define rules for initiating transactions.
Fee abstraction: Abstracts away the details associated with the end user paying gas for every transaction. AA can enable sponsored transactions in which another account can directly pay for a users transaction making the transaction gasless.

The next generation of the consumer layer will focus on seamless onboarding experiences without the cumbersome nature of storing private keys, abstracting away the complexities of transaction verification and signing from the end user and finally abstracting away the execution path needed to perform a desired action by using intent-centric network solvers.

Summary

To summarise the above, we are certain that fragmentation in the application layer is only set to increase with more protocol instances and an increasing number of rollup execution environments. Transaction-based state machines require mental overhead from the end user to verify transaction parameters ensuring no fraudulent execution path is being signed which can result in asset theft. Therefore, abstracting away the process of optimal execution path selection is going to become a core requirement for the next phase of consumer onboarding.

Intents at their core abstract away the complexities of execution flow when interacting with a protocol on the application layer. Solvers have the ability to protect users from fraudulent execution paths and simultaneously provide the best possible execution paths for the end user. DEXs such as CowSwap and UniswapX are already demonstrating the merit to this intent-centric approach to application development.

We believe that intent-centric networks such as Anoma and Essential offer huge promise when it comes to protecting users from malicious forms of MEV, simplifying the process of interacting with applications on the consumer level and have the potential to host a vibrant ecosystem of intent-centric applications. At Arete Research we look forward to supporting teams building toward an intent-centric future.

Intents: The Future of Programmatic Settlement