System Overview

The LI.FI Intent System splits the intent flow into three components:

Input Settler – Handles the source chain funds.
Output Settler – Handles the destination chain funds.
Oracle System – Carries the output settler’s statements back to the input settler.

These components have usually been welded together, which made such systems hard to scale. Keeping them separate is more flexible: you can mix and match input settlement schemes, output settlement schemes, and validation layers. The same three-component model runs beyond the EVM: on Tron with the same contracts, and on Solana as a set of Anchor programs — see Solana programs for that implementation.

Input settlement

The input settlement scheme manages user deposits and releases funds to solvers once intents are fulfilled. LI.FI Intents currently support two input settlement schemes:

Escrow via InputSettlerEscrow.sol
The Compact via InputSettlerCompact.sol. The Compact supports both fill-first flows and ordinary flows.

The intent system places no limits on how you implement input settlement. Input settlements can access proven outputs through validation layers by calling efficientRequireProven. If an order contains multiple outputs and different solvers fill them, the filler of the first output in the order specification is the canonical solver — the one who claims the order’s inputs. 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. The input settlement could pay the solver if it could validate this call — but the information it needs only exists on the output settlement, on the output chain. Closing that gap is what the oracle system does. 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 payloads through a hash that is local to that virtual machine:

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, since less data moves around. The payload itself is not standardized. 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 intents are highly composable — you can swap out any of the components:

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.

Same-chain intents

LI.FI Intents were designed for composable cross-chain swaps, and they also support same-chain intents in the same order format. For a same-chain intent, the output settler can act as the oracle. To use LI.FI Intents for same-chain swaps, configure the output settler as both input and output oracle. Solvers filling same-chain intents can optionally use a callback to receive inputs before delivering outputs.

Same Chain Intent without Callback — Same Chain Intent

Same Chain intent with Callback — Same Chain Intent with callback

To receive inputs before delivering outputs, your solver has to support orderFinalised. When using the callback to receive inputs, it is important to fill and setAttestations for the intent outputs within the callback.

function orderFinalised(
    uint256[2][] calldata inputs,
    bytes calldata call
) external

For more on same-chain callbacks, see the same-chain test case. For more about same chain intents, see Output Settler as Oracle

Smart contracts

Currently maintained LI.FI Intent deployments are listed below. On EVM chains, contracts are deployed to the same addresses (via a keyless CREATE2 factory) and can be permissionlessly deployed to new EVM chains.

EVM

Input Settler Escrow: 0x00fC00edbe7C003b006f870068c548940000223e
Output Settler: 0x75220B7600c300005038432a0000f308e0000068
Polymer Oracle Mainnet: 0x008C3800F3Ad9b3B662d002E90Cc00000000eE17
Polymer Oracle Testnet: 0xC401b53377b8A71A7cEB820e6a4dC53832343a90

Wormhole Oracle Mainnet

Wormhole oracle addresses differ per chain because each chain has a different Wormhole core contract.

Chain	Address
Ethereum	`0x940a87f18Ceb24e58c447851cbB3A57C6FA8d52c`
BNB Chain	`0x940a87f18Ceb24e58c447851cbB3A57C6FA8d52c`
Polygon	`0x6941D83e74d3DA1c056E34eeD97d1FC580ED7F5C`
Avalanche	`0x04B92cc1d51e80621aBa749aB526A47B6Edff84A`
Celo	`0xF6B0113BFE73E9CDA09057C1cbCE53d40Db2273b`
Arbitrum	`0xe1718d27c1aBdaa009Aa8F4d3BeF3AFcE7D81f80`
Optimism	`0x0068F705F4b6739671021C60104239Cf94B2C75E`
Base	`0x935a2dd6ae8153F2c71fa8c1942e1fe0b5A82E72`
Tempo	`0x935a2dd6ae8153F2c71fa8c1942e1fe0b5A82E72`
Unichain	`0x4dA5E848E86cBa97256483507F8359De2DE33fFC`
Ink	`0x4dA5E848E86cBa97256483507F8359De2DE33fFC`
World Chain	`0xD1d0a0378A6c20280b81CE8B5C29657A4C95ce3A`
HyperEVM	`0x3e81FDc6AFD40A08D867C7D74CE31876F0dDE590`
Monad	`0x719eF3abf326AC84FFD653311B0376cfb28faeF1`
Arc	`0x4362aCd4bc071E99eD5E508aE1d0250553fACEA5`
Robinhood Chain	`0x00ab70C0A23C3959B9E6c804776C6c27C6A9D7b6`

Tron

Input Settler Escrow: TXmVLCXzrhzmeCfchDPTmFF6Qe7rg3H7Kk
Output Settler: THWDD3umarircbqo8jXxVazbpJnE25VjhN
Polymer Oracle: TCeNWukZUoTSrgWZEMpn9X8C5NtV8Rsy6c

Solana

Wormhole Oracle Mainnet: LiFixrxyzmt1Degd42wQCsQNhDNLjbrRwtwopX5VUrt
Input Settler Escrow program: LiFiRp8RM7nJUZyUYC9FPPpDr7sAy5XPfBN6ABzBgT7
Output Settler program: LiFiEDFjz5x1jJe9gSXNDHQW4dWt4yLXdp2VN4EiQUt
Polymer Oracle program: LiFiBtfyPT1DnTHTAeZ2rwr5RgMrThwA5kt7KGT5nBV
Intents Protocol program: LiFixdGLT5CMdLsHBvaijTXpPy4Uux9Y53SXkuR4HaK

The four non-Wormhole program IDs above are deployed on both devnet and mainnet-beta. Solana orders and instructions also use program-derived accounts; see Solana programs for the operational addresses.

Getting Started

Intents API

Solver API

MCP Server

Architecture

Knowledge Base

System Overview

Input settlement

Output settlement

Oracle system

Security Assumptions

Integration Points

Same-chain intents

Smart contracts

EVM

Wormhole Oracle Mainnet

Tron

Solana

​Input settlement

​Output settlement

​Oracle system

​Security Assumptions

​Integration Points

​Same-chain intents

​Smart contracts

​EVM

Wormhole Oracle Mainnet

​Tron

​Solana

Input settlement

Output settlement

Oracle system

Security Assumptions

Integration Points

Same-chain intents

Smart contracts

EVM

Tron

Solana