Skip to main content
Most routing asks you to describe how a transfer should happen and then hands back an estimate of what will arrive. An intent inverts that. You state what has to arrive, a solver commits to delivering it, and the path becomes their problem.

​
What this changes for your product

Quote the number you'll deliver

Fix the output amount and the response tells you what the payer must spend. No range on the screen, no difference to absorb.

A short failure surface

Orders that don’t fill refund automatically, and status resolves into a small set of states rather than an open-ended one.

Execution stops being your configuration

Bridge selection and liquidity depth move behind the solver’s commitment instead of becoming settings you own and failures you explain.

A solver network you can describe to compliance

Solvers are onboarded through business verification and screening rather than joining anonymously.
A routed transfer producing an estimated output against an intent order where the output is fixed and a solver commits to filling it

A route returns an estimate. An order returns a commitment.

​
Why the usual approach stalls

Estimates break products that make promises. A product that quotes a customer a number and then delivers a slightly different one has two options, both bad: show the customer a range, or absorb the difference. Range-quoting erodes trust on every screen it appears on. Absorbing the difference works until volume makes it the largest line in the cost base. Underneath sits a control problem. Traditional routing exposes the mechanics of execution, which means your product inherits them. Bridge selection, liquidity depth, and the slippage tolerance protecting the trade all become configuration you own and therefore failures you explain. Every new chain widens that surface, and none of it is what your customers are buying.

​
An order, not a route

LI.FI Intents runs a solver marketplace behind a single quote request. You describe the inputs you’re spending and the outputs you want delivered, competing solvers return quotes, and the winning one carries a transaction that opens the order on-chain. From there the solver’s job is to fill it on the terms they quoted.

Exact output

Fix the amount that has to arrive and leave the input open. The shape of every flow where the destination figure is a commitment: settling an invoice, repaying a position, meeting a contract’s expected amount.

Exact input

Fix what’s being spent and let the solver determine the output. The common mode where the spend is what’s fixed.
Failure has a defined shape rather than an open one. An order that doesn’t fill refunds automatically, and the status endpoint reports a small set of states covering signed, delivered, settled, and refunded, so the state machine your product builds against is short enough to reason about.
Quotes carry a validity window. They’re priced to be opened now rather than cached and replayed later.

​
The parts that are policy, not plumbing

Two capabilities matter for regulated products and are easy to miss because they look like configuration. Solvers on the network are onboarded through business verification and screening, which is the difference between an execution network you can describe to a compliance function and one you can’t. And a quote request can be restricted to named solver addresses, which turns solver selection into something you set by jurisdiction or by partnership.
Restriction is a genuine trade-off rather than a free setting. Narrowing the solver set narrows the pool competing for your order, which reduces fill reliability and can widen pricing. Restrict deliberately, for a reason you could defend.
Coverage differs by chain in ways worth checking before a design commits to them. Off-chain order submission, where the user never sends a transaction, is available on EVM chains and not on Solana or Tron, where an order is always opened on-chain by someone who signs. Resource-lock settlement is likewise EVM-only. A product designed around a fully gasless open needs a different flow on the chains that don’t offer one.

​
What to decide before launch

Most products have both. The ones that pick a single mode for the whole surface usually picked the one that suited the first feature they built.
The protocol resolves a failed order by returning the funds. Whether that reads as cancelled, returned, or try again is a product decision, and the wrong word arrives at the worst moment.
If it exists for a compliance reason, that reason should survive being asked about. If it exists because restriction felt safer, it’s costing fill reliability for nothing.
A quote that ages out between the screen and the confirmation is an ordinary occurrence, not an error. Products that treat it as an error teach customers to distrust the number.

​
Where to start

Request one quote in exact-output mode for a route your product already runs, and compare the input it asks for against what your current path actually costs to deliver the same amount. That single comparison usually settles the question faster than an architecture discussion.

Intents quickstart

From the first request through to settlement.

Request a quote

Swap modes, solver restriction, and per-chain address formats.

Track status

The status values and how to poll them.

Architecture overview

Input settlement, output settlement, and oracle validation.

Talk to the LI.FI team

Bring the flows where the delivered amount is the contract. We scope which settlement path and which chains fit.