Skip to main content
LI.FI intents are a fully componentized, permissionless system without inherent trust elements, allowing integrators to mix and match components as needed. LI.FI intents use the OIF Standard Order, which defines a fully componentized, permissionless intent with single-chain inputs and multi-chain outputs. Integrators can combine components to describe their intent, such as same-chain swaps, cross-chain swaps, or external calls. The following TypeScript types define the structure of a Standard Order and its MandateOutput: 
type StandardOrder = {
	user: `0x${string}`;
	nonce: bigint;
	originChainId: bigint;
	expires: number;
	fillDeadline: number;
	inputOracle: `0x${string}`;
	inputs: [bigint, bigint][];
	outputs: MandateOutput[];
};

type MandateOutput = {
	oracle: `0x${string}`;
	settler: `0x${string}`;
	chainId: bigint;
	token: `0x${string}`;
	amount: bigint;
	recipient: `0x${string}`;
	call: `0x${string}`;
	context: `0x${string}`;
};

​
Designing an intent

When you design an intent, you specify exactly how you want the funds to be escrowed, delivered, and verified along with every other parameter that matters for you. When designing and intent, you need to design it such that it fills your desired purpose but is also fillable by solvers.

​
Input Settler

While not part of a StandardOrder each order is distributed with the context of an Input Settler. It determines how the user’s funds is held while the solver is filling and proving the intent. Read more about Input Settlers.

​
User

The user is the owner of the provided assets. If the intent is not filled, assets are refunded to this address. For a gasless intent, the user may also be the account the funds are pulled from. For some input settlers, it may be required that the user performs an action before they can receive their refund.

​
Oracle (inputOracle & outputs[].oracle)

An intent oracle is specified in 2 places: Once as the inputOracle and then in each output as outputs[].oracle. These 2 addresses needs to be of the same oracle system and understand each other. The oracle system determines when the inputs are paid to the solver; when has the solver fulfilled its job. Choosing a weak security oracle for a high value transaction may not be appropriate. Read more about Oracle Systems

​
Inputs

Input assets as [tokenIdentifier, amount] in uint256. For escrow, tokenIdentifier is the address cast to uint256 with left-padded zeros. For The Compact, it is the ERC-6909 identifier.

​
Outputs

Desired outputs, which can include multiple tokens on multiple chains or the same chain as the inputs. Each output contains:
  • oracle: See Oracle; must correspond to the network used for inputOracle.
  • settler: Contract responsible for settling the output assets. Determines how context is parsed, settlement logic, and auction type.
  • chainId: Output chain identifier.
  • token: Token identifier on the output chain.
  • amount: Output token amount.
  • recipient: Recipient of the output token and any calldata.
  • call: External calldata executed via outputFilled(bytes32 token, uint256 amount, bytes executionData). If the call fails, the entire order cannot be filled.
  • context: Settlement context encoding options for the desired settlement, including auction parameters.

​
Other parameters:

  • nonce: Ensures each order is unique. For The Compact, this is used as an allocator nonce rather than a user-specific nonce.
  • originChainId: Identifier of the chain where the intent originates.
  • expires: Deadline for submitting proof that the order has been filled. After this, the order can be refunded.
  • fillDeadline: Deadline for filling the order. This should always be before expires, as filling occurs before proof submission.
  • inputOracle: Address of the oracle network used on the origin chain. This should correspond to the oracle addresses in MandateOutput.
You need to choose your parameters carefully. They determine the security and delivery structure. Choose a valid and trusted output settler and an appropriate oracle system.

​
On-Chain vs Off-Chain Intents

Decide whether to use on-chain or off-chain intents: On-chain intents include:
  • Escrow Opened Intents
  • Registered and broadcasted Compact claims
Off-chain intents include:
  • Gasless Escrow intents
  • Signed Compact claims
The order server is a convenience and not mandatory. All on-chain intents can be submitted without it. Some solvers detect on-chain intents independently, while others rely on the order server to distribute them.

​
Intent Validation

Before creating an intent, ensure it is valid. Validation is divided into security and correctness categories. Important: The solver competition focuses on the first MandateOutput. Outputs are filled sequentially, not atomically.

​
Security Validation

Security defines the structure protecting your intent. Without proper structure, anyone could violate your fulfillment assumptions.
  1. Ensure your oracle network is secure relative to the intent size.
  2. For non-global auctions (e.g., output dutch auctions), only the first output may be filled quickly. Assume other outputs may fill at their minimum.
  3. Multi-output orders may be vulnerable to DoS by filling only the first output. Ensure the first output is the most valuable.
  4. All oracles should belong to the same network.
  5. Outputs may execute out of order. If your contract requires multiple tokens before taking action, each output should include logic/calldata to check whether other outputs are filled.
  6. Calls from the output settler cannot be trusted; anyone can fill fake outputs to trigger external calls.

​
Correctness Validation

Correctness ensures the order is safe and understandable for solvers.
  1. Use known, reliable components: input/output tokens, settlement contracts, and oracles.
  2. Use the fewest tokens possible. Random or near-zero value tokens reduce the likelihood of being filled.
  3. For multi-chain outputs, only the first output should include calldata.
  4. Provide sufficient time between fillDeadline and expires to accommodate messaging delays.
  5. If no existing deposit exists in a resource lock, ensure enough settlement time is included in fillDeadline.
  6. Ensure the nonce is unique. For The Compact, this applies to the allocator, not the user.
  7. Include external calldata only when MandateOutput.recipient is a contract capable of receiving outputFilled(...).
  8. If using The Compact:
    1. Ensure all inputs share the same allocator.
    2. Ensure the resource lock expiry is after the intent expiry.
    3. For non-durable signature schemes, ensure an emissary is set.