The LI.FI Intent System modularizes three components of the cross-chain intent flow:
  1. Input settlement scheme – Handles the source chain funds.
  2. Output settlement scheme – Handles the destination chain funds.
  3. Oracle System – Makes Output Settlement statements available for the input settler.
Overview of the intent process Historically, these components have been intertwined, which presented scaling challenges. A componentized approach allows for greater flexibility and extensibility, enabling different input and output settlement schemes and validation layers to be mixed and matched.

​
Input Settlement

The input settlement scheme manages user deposits and releases funds to solvers once intents are fulfilled. LI.FI intent currently implements one input settlement scheme: Resource locks support both fill-first flows and ordinary flows. The intent system imposes no restrictions on the implementation of input settlements. Input settlements can access proven outputs through validation layers by calling 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: 
interface IPayloadCreator {
    function arePayloadsValid(
        bytes[] calldata payloads
    ) external view returns (bool);
}
This allows the output settlement scheme to be incredibly flexible; it can support any order type on any virtual machine, as long as the filled order can be expressed as an opaque bytes array. The initial version of the intent system uses 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: 
function submit(address proofSource, bytes[] calldata payloads) external payable {
    // Check if the payloads are valid.
    if (!IPayloadCreator(proofSource).arePayloadsValid(payloads)) revert NotAllPayloadsValid();

    // Payloads are valid. We can submit them on behalf of proofSource.
    _submit(proofSource, payloads);
}
Oracles may use custom message encodings, custom relaying properties, custom interfaces, or other special integration concerns. Internal oracle messaging is not standardized. On the input chain, the oracle system is expected to validate the payload(s) through a virtual machine local hash: 
interface IValidationLayer {
    /**
     * @notice Check if a series of data has been attested to.
     * @dev Does not return a boolean; instead, it reverts if false.
     * This function returns true if proofSeries is empty.
     * @param proofSeries remoteOracle, remoteChainId, and dataHash encoded in chunks of 32*4=128 bytes.
     */
    function efficientRequireProven(
        bytes calldata proofSeries
    ) external view;
}
Using only the payload hash makes the system more efficient, as less data is passed around. No attempt is made at standardizing the payload. As a result, there may be incompatibilities between the input and output settlement layers. Learn more about Validation Layers →

​
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.
No single actor can independently access funds, creating a secure environment for cross-chain transactions. For more about security and intent validation, see order-validation →

​
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.
Integrators can freely pick and choose which components to use for which swaps. This gives intent issuers maximum flexibility to describe their desired end state.

​
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: 
struct OutputDescription {
    bytes32 remoteOracle;
    bytes32 remoteFiller;
    uint256 chainId;
    bytes32 token;
    uint256 amount;
    bytes32 recipient;
    bytes remoteCall;
    bytes fulfillmentContext;
}
The proposed message format is as follows: 
Encoded FillDescription
     SOLVER                          0               (32 bytes)
     + ORDERID                       32              (32 bytes)
     + TIMESTAMP                     64              (4 bytes)
     + TOKEN                         68              (32 bytes)
     + AMOUNT                        100             (32 bytes)
     + RECIPIENT                     132             (32 bytes)
     + CALL_LENGTH                   164             (2 bytes)
     + CALL                          166             (LENGTH bytes)
     + CONTEXT_LENGTH                166+RC_LENGTH   (2 bytes)
     + CONTEXT                       168+RC_LENGTH   (LENGTH bytes)
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 as O(n) instead of O(n^3), with n roughly being the number of components.

​
Optimistic Validation Layers

The current validation layers mainly support explicit validation. Optimistic validation can be implemented but requires each output to have on-chain storage, which increases gas costs. Ideally, the specification should define a way for one proof to validate multiple orders, not just outputs. This would likely involve using Merkle trees or similar constructions to pass validated messages