- Input Settler – Handles the source chain funds.
- Output Settler – Handles the destination chain funds.
- Oracle System – Makes Output Settlement statements available for the input settler.

Input Settlement
The input settlement scheme manages user deposits and releases funds to solvers once intents are fulfilled. The LI.FI intent currently implements two input settlement scheme:- Escrow via
InputSettlerEscrow.sol
- TheCompact via
InputSettlerCompact.sol
. The Compact supports both fill-first flows and ordinary flows.
efficientRequireProven
. If an order contains multiple outputs and the outputs are filled by different solvers, the filler of the first output in the order specification is considered the canonical solver.
Learn more about Input Settlement →
Output Settlement
The output settlement scheme handles the delivery of assets on destination chains. It imposes no interface requirements, order structure, or order type, except that an interface to validate payloads must be provided:MandateOutput
, with the encoding described by MandateOutputEncodingLib.sol
.
If the input settlement could validate this call, the inputs could be appropriately paid to the solver. However, this information only exists on the output settlement on the output chain.
Learn more about Output Settlement →
Oracle System
The oracle system ferries valid payloads from the output chain to the input chain. It serves as the bridge that confirms output delivery has occurred. Any validation layer can be added as long as it supports validating a payload from a remote chain. Currently available validation layers include: Before emitting messages, the oracle is expected to check if one or more payloads are valid and then ship them to the input chain:Security Assumptions
The intent system includes resource locks, which create trust boundaries between key actors:- Sponsors (users) trust that arbiters won’t fraudulently finalize issued locks.
- Arbiters and solvers trust allocators not to co-sign overlapping locks exceeding user deposits.
Integration Points
LI.FI intent is designed to be highly composable, with different components capable of being swapped out as needed:- Input Settlement: New resource lock standards and standard intent interfaces can be integrated.
- Output Settlement: New order types and fulfillment mechanisms can be added.
- Oracle System: Different cross-chain messaging protocols and proof layers can be supported.
Unsolved Issues
While the initial version is a significant improvement over competing solutions at standardizing the intent stack, there are still interoperability issues within the standard. For transparency, known specification issues are listed below.Standardized Message Format
Currently, the input settlement scheme and the output settlement scheme must agree on an order-type-specific payload. If a new order type or settlement system requires more functionality beyond the implemented message payload, it requires redeploying these components. This breaks composability between these layers. Assuming the output description can be represented as:No assumptions are made about how validation layers pass messages between themselves. They can pack fill descriptions however they like. Example of a packed payload.
Atomic Swaps and HTLCs as Validation Layers
HTLCs work very differently from ordinary intent schemes, as they require a round of strong commitments. This pre-bakes certain system assumptions that cannot be abstracted away through the OIF Intent System. As a result, these are not considered.Integration Overheads
As interfaces and validation layers are not standardized, each new order type, validation layer, or settlement scheme presents additional integration overhead. However, since components are eagerly reused, the system complexity scales asO(n)
instead of O(n^3)
, with n
roughly being the number of components.