系统概述

LI.FI 意图系统将意图流程拆分为三个组件：

输入结算器 – 处理源链资金。
输出结算器 – 处理目标链资金。
预言机系统 – 将输出结算器的声明带回输入结算器。

这些组件历来是焊死在一起的，这让此类系统难以扩展。将它们分开则更灵活：你可以混合搭配输入结算方案、输出结算方案和验证层。同样的三组件模型不仅限于 EVM：在 Tron 上使用同一套合约，在 Solana 上则是一组 Anchor 程序——该实现请参见 Solana 程序。

输入结算

输入结算方案管理用户存款，并在意图完成后将资金释放给求解器。LI.FI Intents 目前支持两种输入结算方案：

托管（Escrow） 通过 InputSettlerEscrow.sol
The Compact 通过 InputSettlerCompact.sol。The Compact 同时支持先填充流程和普通流程。

意图系统对如何实现输入结算没有任何限制。输入结算可以通过调用 efficientRequireProven 经由验证层访问已证明的输出。如果一个订单包含多个输出，且这些输出由不同的求解器填充，则订单规范中第一个输出的填充者就是规范求解器——由他来领取该订单的输入。了解有关输入结算的更多信息 →

输出结算

输出结算方案处理目标链上资产的交付。它不强制要求任何接口、订单结构或订单类型，只要求必须提供一个用于验证有效载荷的接口：

interface IPayloadCreator {
    function arePayloadsValid(
        bytes[] calldata payloads
    ) external view returns (bool);
}

这使得输出结算方案极为灵活；只要已填充的订单能够表示为一个不透明的字节数组，它就可以支持任何虚拟机上的任何订单类型。意图系统的初始版本使用 MandateOutput，其编码方式由 MandateOutputEncodingLib.sol 描述。如果输入结算能够验证此调用，就可以将输入支付给求解器——但它所需要的信息只存在于输出链上的输出结算中。填补这一空缺，正是预言机系统的作用。了解有关输出结算的更多信息 →

预言机系统

预言机系统将有效载荷从输出链传递到输入链。它充当确认输出交付已发生的桥梁。只要验证层支持验证来自远程链的有效载荷，任何验证层都可以被添加。目前可用的验证层包括：

在发出消息之前，预言机应检查一个或多个有效载荷是否有效，然后将它们发送到输入链：

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);
}

预言机可以使用自定义的消息编码、自定义的中继属性、自定义的接口或其他特殊的集成事项。预言机内部的消息传递未做标准化。在输入链上，预言机系统应通过一个该虚拟机本地的哈希来验证这些有效载荷：

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;
}

仅使用有效载荷哈希使系统更高效，因为传递的数据更少。有效载荷本身未做标准化。因此，输入和输出结算层之间可能存在不兼容的情况。了解有关验证层的更多信息 →

安全假设

意图系统包含资源锁，这在关键参与者之间建立了信任边界：

发起人（Sponsors）（用户）信任仲裁者不会欺诈性地完结已签发的锁。
仲裁者（Arbiters） 和 求解器（Solvers） 信任分配者不会共同签署超出用户存款的重叠锁。

没有任何单一参与者能够独立获取资金，从而为跨链交易创造了一个安全的环境。有关安全性和意图验证的更多信息，请参阅 order-validation →

集成点

LI.FI intents 具有高度可组合性——你可以替换任何一个组件：

输入结算：可以集成新的资源锁标准和标准意图接口。
输出结算：可以添加新的订单类型和履约机制。
预言机系统：可以支持不同的跨链消息传递协议和证明层。

集成商（Integrators）可以自由选择在哪些交换中使用哪些组件。这为意图签发者提供了最大的灵活性，以描述他们所期望的最终状态。

同链意图

LI.FI Intents 专为可组合的跨链交换而设计，同时也以相同的订单格式支持同链意图。对于同链意图，输出结算器可以充当预言机。要将 LI.FI Intents 用于同链交换，请将输出结算器同时配置为输入预言机和输出预言机。填充同链意图的求解器可以选择使用回调，在交付输出之前接收输入。

Same Chain Intent without Callback — Same Chain Intent

Same Chain intent with Callback — Same Chain Intent with callback

要在交付输出之前接收输入，你的求解器必须支持 orderFinalised。当使用回调接收输入时，重要的是在回调内部对意图输出执行 fill 和 setAttestations。

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

有关同链回调的更多信息，请参阅同链测试用例。有关同链意图的更多信息，请参阅将输出结算器用作预言机

智能合约

目前维护中的 LI.FI Intent 部署如下所列。在 EVM 链上，合约部署到相同的地址（通过无密钥的 CREATE2 factory），并且可以无需许可地部署到新的 EVM 链上。

EVM

Input Settler Escrow: 0x000025c3226C00B2Cdc200005a1600509f4e00C0
Output Settler: 0x0000000000eC36B683C2E6AC89e9A75989C22a2e
Polymer Oracle Mainnet: 0x0000003E06000007A224AeE90052fA6bb46d43C9
Polymer Oracle Testnet: 0xC401b53377b8A71A7cEB820e6a4dC53832343a90

Wormhole Oracle Mainnet

由于每条链的 Wormhole core 合约不同，Wormhole oracle 的地址因链而异。

链	地址
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

上面四个非 Wormhole 程序的 ID 已同时部署在 devnet 和 mainnet-beta 上。Solana 上的订单和指令还使用程序派生账户；具体的操作地址请参见 Solana 程序。

入门

Intents API

Solver API

MCP Server

架构

知识库

输入结算

输出结算

预言机系统

安全假设

集成点

同链意图

智能合约

EVM

Wormhole Oracle Mainnet

Tron

Solana

​输入结算

​输出结算

​预言机系统

​安全假设

​集成点

​同链意图

​智能合约

​EVM

Wormhole Oracle Mainnet

​Tron

​Solana

输入结算

输出结算

预言机系统

安全假设

集成点

同链意图

智能合约

EVM

Tron

Solana