Skip to main content
An order (intent) describes what the user wants: input assets, desired outputs, settlement parameters, and deadlines. On every chain, the recommended path is the same: request a V1 quote, then sign and send the ready-made open transaction it returns. Off-chain submission via the order server exists for EVM gasless flows. Calls on delivery are available where the destination settler supports them — on EVM, not on Solana.

Order Structure

LI.FI intents use the OIF StandardOrder, which supports single-chain inputs and multi-chain outputs.

Field Reference

Output Fields


Choosing a Resource Lock

Resource locks determine how user funds are held while the solver fills the order. If you’re adding LI.FI Intents alongside other bridges, Simple Escrow is recommended. If you’re building a resource-lock-first application, consider The Compact. See Escrow Deposit Methods for the ways funds can be deposited.
The deployed InputSettlerCompact contract has not yet been updated to the current version of the protocol. Its address will be published once the updated deployment is live — use Simple Escrow in the meantime, or contact LI.FI if you are building a Compact integration.
On Tron and Solana, only escrow is available — there is no Compact or resource-lock flow on either chain.

Submitting an Order

Each V1 quote returns order.openIntentTx — an origin-chain transaction that opens the order. Opening on-chain is the broadcast: the input settler emits an open event, the order server ingests it, and solvers pick the order up. There is no separate submission call. The transaction’s shape and the steps before sending differ per chain.

Opening on EVM

openIntentTx carries the input settler address (to), hex calldata (data), and a gas estimate (gasRequired). Before sending, satisfy every entry in order.checks.allowances — each item asserts the user holds and has approved at least required of token for spender (direct ERC-20 approval or Permit2):

Opening on Tron

On Tron, openIntentTx.data is full ABI calldata (selector + arguments), not a ready-to-broadcast transaction. Approve the TRC-20 input first, then wrap the calldata in a TriggerSmartContract envelope with TronWeb; feeLimit is a cap on energy spend in SUN, not an estimate:
Details on address conversion and the TVM envelope are in Tron vs EVM.

Opening on Solana

On Solana, openIntentTx.data is a serialized transaction template. Before signing, replace its dummy blockhash and rebuild its message with the compute-unit limit returned in openIntentTx.computeUnitsRequired:
The current template has no address lookup tables, so it can be decompiled without supplying lookup-table accounts. If that changes, resolve every lookup table and pass it to TransactionMessage.decompile before rebuilding. In a dApp, use your wallet adapter’s signTransaction instead of a Keypair. The open instruction escrows the input tokens and emits an OpenEvent; the order server ingests that event and distributes the order to solvers. There is no approval pre-step: checks.allowances is always [] because the SPL transfer happens inside the open instruction.
Store secrets like USER_SECRET_KEY in environment variables — never hardcode them or expose them in browser code.

Off-Chain Submission (Gasless and Compact)

Use POST /orders/submit only when your integration needs off-chain order submission — gasless escrow or signed Compact claims, both EVM-only. It does not accept Tron or Solana orders. If you used a quote from the order server, include the quoteId for preferential processing.
The response includes the full order, associated quote (if any), and a meta object with orderIdentifier and onChainOrderId for tracking.
This is a reference template. CatalystCompactOrder submissions require a sponsor signature or Compact registration tx hash. Always validate on order-dev.li.fi before mainnet rollout.

On-Chain vs Off-Chain Orders

The order server is a convenience layer, not a requirement for on-chain orders. All on-chain intents can be submitted without it. Some solvers detect on-chain intents independently.

Calls on Delivery

Each MandateOutput supports a call field for calldata executed on the destination chain after token delivery. The recipient receives tokens first, then the output settler calls outputFilled(bytes32 token, uint256 amount, bytes executionData) on the recipient contract. When using calls on delivery:
  • For each output, the output settler delivers the tokens before it runs the call
  • If the call fails, the entire intent cannot be filled
  • The recipient must be a contract that implements outputFilled, not an EOA
  • For multi-chain outputs, only the first output should include calldata
For arbitrary contract calls, use a batching contract or Single-Call Architecture (SCA) wrapper since the call is wrapped in outputFilled. Contact LI.FI if you need an SCA implementation.
Calls on delivery are not supported on Solana. Orders with Solana outputs must leave the callback field empty; the output settler rejects fills otherwise.

Intent Validation

Before submitting, validate your order against these rules.

Security

  1. Check that the oracle network is secure enough for the value of the intent
  2. All oracles (input and output) should belong to the same network
  3. Multi-output orders can be vulnerable to DoS by filling only the first output. Make the first output the most valuable.
  4. Calls from the output settler cannot be trusted for authentication since anyone can fill outputs
  5. Set user as the intended refund recipient, not the intent issuer or relay address.
Ensure that the refund recipient can properly receive and handle funds. Using an address that cannot accept tokens (e.g. a contract without a receive function, or the wrong chain address) will lose the funds permanently.

Correctness

  1. Use known, reliable tokens, settlement contracts, and oracles
  2. Use the fewest tokens possible. Low-value or obscure tokens make a fill less likely.
  3. Leave enough time between fillDeadline and expires for messaging delays
  4. Ensure the nonce is unique. Escrow requires user uniqueness, while The Compact requires allocator uniqueness.
  5. For The Compact, ensure all inputs share the same allocator and the resource lock expiry is after the intent expiry

Next Steps

Track Order Status

Monitor order progress and handle terminal states

Request a Quote

Fetch solver pricing before constructing an order

Settlement

Escrow and Compact registration details

Oracle Systems

Oracle networks and verification