An intent is a signed statement of the outcome a user wants, such as receiving a token on another chain, rather than a step-by-step transaction. Intent-based architecture hands the job of finding and carrying out a route to third parties, usually called solvers or fillers. Chain abstraction is the broader goal of hiding which chain an action happens on. Intents are one way to deliver it: the user states the result, and the solver deals with the chains, routes, and gas underneath.
Last updated: October 5, 2026.
What is an intent in blockchain?
A regular transaction spells out exactly what to do: which contract to call, with which inputs, on which chain. If the user wants a result that spans several chains, they usually have to sign and pay for each step themselves.
An intent describes the result instead. It sets constraints, such as what the user gives up, the minimum they accept, and a deadline, and leaves the path open. The user signs the intent once, and solvers that can satisfy those constraints compete to fill it, within whatever rules the system sets for who can take part.
How does intent-based architecture work?
Most intent systems follow the same pattern.
- Express. The user signs an intent with their constraints, often through an application interface.
- Compete. Solvers see the intent and decide whether they can fill it at the stated terms. Some systems run an auction to pick one.
- Fill. The chosen solver delivers the outcome, often by paying the user on the destination chain from its own funds first.
- Settle. The solver is repaid, typically from funds the user locked when signing, once the system confirms that the fill happened.
The settle step is where chains have to agree on what happened. The source chain needs a reliable way to learn that the fill happened on the destination before it releases funds, which is a job for cross-chain messaging or another verification method.
How do intents relate to chain abstraction?
Chain abstraction is a user experience goal. Intents are a design pattern that can serve that goal. The two sit at different layers of the same stack.
| Layer | Question it answers | Who handles it |
|---|---|---|
| Chain abstraction | Does the user need to pick a chain? | The application and wallet |
| Intent-based routing | How is the requested outcome reached? | Solvers that fill the request |
| Cross-chain messaging | How does one chain learn what happened on another? | The messaging and verification layer |
An application can offer chain abstraction without intents, for example by routing every request through a fixed path. Intents can also be used on a single chain. The chain abstraction overview covers the other parts of that stack.
What are the trade-offs of intents?
Intents shift work from the user to solvers. The user signs less and sees fewer steps, but whether a request gets filled depends on solvers being willing to take it at those terms. Solvers also need funds ready on the destination chain, and those funds have to be rebalanced across chains over time. The final settlement is only as reliable as the method the system uses to confirm that a fill happened.
FAQ
Is an intent the same as a transaction?
No. A transaction is a set of instructions that a chain executes as written. An intent is a set of conditions, and a solver chooses the transactions that meet them.
Do intents replace bridges?
No. Solvers still move value between chains to rebalance their funds, and settlement still needs a way to confirm events on another chain. The cross-chain transfers vs swaps overview explains how those movements differ.
Are intents only used for swaps?
No. Any outcome that can be written as constraints can be an intent, including cross-chain transfers and deposits.
Build across chains
For cross-chain messaging concepts and integration paths, start with the LayerZero developer resources.