Order Structure
LI.FI intents use the OIFStandardOrder, 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.Submitting an Order
Each V1 quote returnsorder.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:
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:
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)
UsePOST /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.
meta object with orderIdentifier and onChainOrderId for tracking.
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
EachMandateOutput 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
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
- Check that the oracle network is secure enough for the value of the intent
- All oracles (input and output) should belong to the same network
- Multi-output orders can be vulnerable to DoS by filling only the first output. Make the first output the most valuable.
- Calls from the output settler cannot be trusted for authentication since anyone can fill outputs
- Set
useras the intended refund recipient, not the intent issuer or relay address.
Correctness
- Use known, reliable tokens, settlement contracts, and oracles
- Use the fewest tokens possible. Low-value or obscure tokens make a fill less likely.
- Leave enough time between
fillDeadlineandexpiresfor messaging delays - Ensure the nonce is unique. Escrow requires user uniqueness, while The Compact requires allocator uniqueness.
- 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

