An Intent is a description of the outcome a blockchain user wants to achieve without requiring the user to specify every transaction and execution step needed to produce that result. Instead of manually defining the exact route through smart contracts, liquidity pools, bridges, or blockchain networks, the user expresses a goal and allows specialised infrastructure to determine how that goal should be fulfilled.
For example, a conventional decentralised exchange interaction may require a user to choose a network, select a liquidity source, approve a token, determine acceptable slippage, and submit the required transactions. An intent can express the same objective more directly: exchange 1 ETH for at least a specified amount of USDC under defined conditions. External participants can then compete to find an execution path satisfying those conditions.
This makes intents an alternative interaction model rather than a new type of blockchain transaction. The final result still depends on transactions, signatures, smart contracts, liquidity, and blockchain settlement. What changes is which parts of the execution process the user needs to specify personally.
Intent-based architecture is used particularly in decentralised trading, cross-chain applications, and systems that rely on solvers, fillers, or similar participants to fulfil user requests.
From Transactions to Desired Outcomes
Traditional blockchain interfaces are largely transaction-oriented. Users specify an action against a particular smart contract and then sign a transaction containing the required call data. More complicated objectives often require several separate actions.
Suppose a user owns Token A on one blockchain but wants Token B on another. A manually constructed workflow could involve swapping Token A, interacting with a bridge, waiting for cross-chain settlement, and performing another swap on the destination network.
The user’s actual objective, however, is much simpler: convert a certain amount of Token A on Chain A into at least a certain amount of Token B on Chain B.
An intent-based system separates this desired outcome from the mechanics needed to achieve it. The user defines acceptable conditions, while specialised participants search for routes that satisfy them.
This difference can be summarised as follows:
| Aspect | Transaction-Based Interaction | Intent-Based Interaction |
| User specifies | Execution action or contract call | Desired outcome |
| Route selection | Often chosen by user/interface | Can be determined by solver |
| Execution complexity | More visible to user | Abstracted from user |
| Liquidity search | Usually tied to selected route | Can compare multiple sources |
| Cross-chain actions | Often separate steps | Can be represented as one objective |
| Competition | Often between liquidity routes | Can occur between solvers |
| User’s main concern | How to execute | What result is acceptable |
Intent systems therefore shift part of the complexity from users to execution infrastructure. This can simplify interfaces while creating a new requirement: the system must ensure that third parties cannot fulfil an intent under conditions worse than those the user authorised.
What Information Can an Intent Specify?
An intent cannot simply state that a user wants “the best trade”. The desired result needs sufficiently precise constraints so that a protocol can determine whether a proposed fulfilment is acceptable.
For a token exchange, the user might specify the input asset, maximum input amount, desired output token, minimum acceptable output, destination address, and deadline. Cross-chain intents can additionally specify source and destination networks.
Other systems may define conditions around price, execution time, allowed assets, counterparties, or smart contract interactions.
Common intent parameters can include:
- assets the user is willing to provide;
- assets or state changes the user wants to receive;
- minimum output or maximum input values;
- source and destination blockchain networks;
- execution deadline or validity period;
- addresses permitted to receive the result;
- constraints limiting acceptable execution paths.
The exact format depends on the protocol. There is no single universal Intent data structure used by every blockchain application.
What matters is that the conditions are verifiable. Once execution is proposed, the system needs to determine whether the user’s requirements were actually satisfied.
Solvers and Intent Fulfilment
Intents create a market for execution. Instead of the user personally finding the route, specialised participants can search for ways to fulfil the requested outcome.
These participants are commonly called solvers, although individual protocols may use terms such as fillers, relayers, resolvers, or market makers. Their exact responsibilities differ between architectures.
A solver can examine available liquidity, prices, routes, inventory, and execution costs before deciding whether it can satisfy an intent profitably. Several solvers may compete for the same order, potentially improving the result offered to the user.
A simplified process works like this:
- The user defines an intent and signs the relevant authorisation.
- The intent becomes available to the protocol’s execution infrastructure.
- Solvers evaluate possible ways to satisfy the stated conditions.
- One or more solvers submit proposed solutions or compete through an auction mechanism.
- The protocol selects or accepts a valid solution according to its rules.
- The required transactions execute on the relevant blockchain or blockchains.
- Settlement verifies that the final outcome satisfies the user’s signed constraints.
The solver may use liquidity from decentralised exchanges, its own inventory, market makers, aggregators, or other available sources. The user does not necessarily need to know which route was ultimately selected as long as the signed outcome conditions are met.
This creates an important economic distinction. Solvers are not simply executing instructions mechanically. They can compete over how efficiently they can transform the user’s starting state into the requested result.
Intents in Decentralised Trading
Trading is one of the clearest applications for intents because users generally care more about the final exchange rate than about the exact sequence of smart contracts used to obtain it.
In a conventional DEX interface, the application often selects a route and presents it to the user before the transaction is signed. An intent-based trading system can instead allow external participants to compete to provide the required output.
This model can improve execution when solvers have access to multiple liquidity sources. A solver might combine on-chain liquidity with private inventory or other venues rather than forcing the entire trade through one automated market maker.
Intent-based systems can also reduce some forms of harmful MEV. If the user signs a minimum acceptable result rather than broadcasting a predictable swap directly into a public mempool, the execution process can avoid exposing the exact transaction in the same way as a conventional public swap.
However, intents do not eliminate MEV. Value can shift into solver auctions, order-flow markets, routing decisions, and competition between execution providers. The architecture changes where execution value is captured rather than making it disappear.
Cross-Chain Intents
Cross-chain interactions are particularly suitable for intent-based design because users often have little interest in the mechanics of bridges, intermediary assets, and destination-chain execution.
A user might simply want to exchange 1,000 USDC on one network for a specified amount of another token on a second network. The conventional workflow could require several independent transactions and exposure to different infrastructure components.
With an intent, the user can describe the desired destination state. A solver can then determine how to deliver that result, potentially using its own liquidity on the destination chain and settling the corresponding obligations separately.
Some designs therefore resemble a marketplace for cross-chain fulfilment. Rather than moving the user’s exact assets through every stage of a predefined bridge route, a solver can provide the destination assets and use the protocol’s settlement mechanism to recover value afterwards.
This can improve speed and simplify the user experience, but it introduces additional considerations around settlement security, solver liquidity, finality, and the mechanisms used to enforce successful fulfilment.
The security of a cross-chain intent system ultimately depends on its actual architecture. Expressing an outcome does not remove the security assumptions of the networks, contracts, bridges, or settlement systems involved.
What Intents Do Not Abstract Away
Intent-based applications can hide substantial execution complexity from users, but abstraction should not be confused with elimination.
Someone still needs to provide liquidity, submit transactions, pay gas, interact with smart contracts, and manage execution failures. Cross-chain systems still need a method for coordinating or settling activity across independent networks.
Users also need to understand what they are authorising. A broadly defined intent can potentially give an execution system more freedom than the user expects, particularly if constraints around assets, recipients, amounts, or contract interactions are weak.
The quality of an intent system therefore depends partly on how precisely permissions are represented. The ideal design gives solvers enough flexibility to optimise execution without giving them authority beyond what is necessary to satisfy the requested outcome.
This principle resembles other forms of programmable authorisation in crypto. Flexibility is useful when its boundaries are explicit and enforceable.
Risks and Trade-Offs of Intent-Based Systems
Moving execution decisions away from users creates new infrastructure and market dependencies. If only a small number of solvers can compete effectively, the system may become concentrated even though settlement occurs on a decentralised blockchain.
Solver competition can also depend on access to liquidity, private order flow, sophisticated routing infrastructure, and capital. Large participants may therefore have advantages that make it difficult for smaller solvers to compete.
Another concern is information leakage. Solvers need enough information to evaluate an intent, but revealing too much information before execution can create opportunities for adverse trading or MEV strategies. Protocols need to balance discoverability with protection of user order flow.
Failed fulfilment is also important. Market prices can change between intent creation and execution, destination networks can become congested, and liquidity can disappear. Intent systems therefore need clear expiration rules and mechanisms for determining when an intent can no longer be executed.
These trade-offs mean that an intent-based interface is not automatically more decentralised or secure than a transaction-based one. It primarily changes the allocation of responsibilities between the user and execution infrastructure.
Intent as a Web3 Interaction Model
The significance of intents extends beyond trading. They represent a broader shift from instructing blockchain applications how to perform every operation towards telling them what final state the user wants.
A user might want to acquire an NFT using assets held on another network, rebalance a portfolio to specified percentages, repay a lending position using several available tokens, or move assets to a network where they can earn a minimum yield. Each objective could require several transactions, yet the user’s actual preference can often be expressed much more simply.
Intent-based systems make it possible to separate these preferences from execution. Solvers and other specialised participants handle routing and transaction construction, while smart contracts and settlement mechanisms enforce the conditions the user authorised.
This model does not replace transactions or blockchains. It creates a higher-level coordination layer above them. Transactions describe concrete state-changing actions, while intents describe acceptable outcomes and leave some freedom over how those outcomes are reached.
For users, that distinction can make complex on-chain activity considerably easier to navigate. For protocols, it creates a different design challenge: execution can be flexible, but the user’s constraints must remain precise, verifiable, and protected throughout the process.