> ## Documentation Index
> Fetch the complete documentation index at: https://docs.li.fi/llms.txt
> Use this file to discover all available pages before exploring further.

# 求解 LI.FI 意图

> LI.FI 意图为您提供开放订单流和无需许可的求解——直接访问跨链流动性、快速结算周期和灵活集成。

作为跨链生态系统中的求解器，您可能专注于：

* 访问可靠的订单流
* 最小化用户托管解锁时间以减少库存要求
* 在流动性来源方面具有灵活性

### LI.FI 意图如何帮助

* **直接访问 [LI.FI](http://li.fi/) 的大量订单流**
* **自由使用任何流动性来源**进行求解（例如，DEX、CEX 或您自己的库存）
* **快速的用户托管解锁时间**（通常少于 2 分钟）
* **由于快速还款周期而降低资本要求**

## 求解意图

LI.FI 意图是一个完全无需许可的系统。由于系统是组件化的，并且组件与其他组件没有固有的信任元素，因此用户可以根据需要混合和匹配它们。因此，一旦收到订单，您就必须完整验证订单。一般流程是：

1. 赞助商签署 LI.FI 意图兼容的锁并将其发送到 LI.FI 订单服务器。

2. LI.FI 订单服务器初步验证订单并获取订单的分配者共同签名。然后将其广播给求解器。

3. 求解器将订单的输出提交到输出结算合约，启动预言机系统。

   <Note>
     [输出结算](/zh-Hans/lifi-intents/architecture/output-settlement)
     表示为 `output.settler`。
   </Note>

4. 证明通过验证层传递到输入链。

   <Note>
     [预言机系统](/zh-Hans/lifi-intents/architecture/oracle-systems)
     在订单结构中表示为 `localOracle` 和 `output.oracle`。
   </Note>

5. 求解器将订单提交到输入结算合约，验证交付并解锁关联的输入代币。

### 订单类型

LI.FI 使用三种订单结构，从最简洁到最详细列出：

1. `BatchClaim`：允许索取输入资产的签名意图。
2. `StandardOrder`：包含足够信息以传达意图的链上定义。
3. 订单服务器响应：包含可能对求解器有帮助的附加信息的充实订单。

除非您正在验证订单签名，否则您不会与 `BatchClaim` 交互。所有链上交互都使用 `StandardOrder` 来标准化接口。但是，`StandardOrder` 不包含足够的信息来填充意图。因此，它在链下使用 `InputSolver`、`signatures` 等进行充实。

### 收集订单

LI.FI 意图提供两种接收订单的方式：

1. **推荐**：通过 WebSocket 连接到订单服务器。
2. **替代方案**：通过存款接口监控链上存款。

订单服务器是大多数求解器的推荐集成界面。但是，如果您对最低延迟、去中心化和无需许可的订单发现感兴趣，您可以在链上读取一些订单。并非所有订单都可以在链上发现。从任一来源，您将收到一个 `StandardOrder` 和其他要在所有 VM 上提交的填充详细信息：

```solidity theme={"system"}
struct StandardOrder {
    address user;
    uint256 nonce;
    uint256 originChainId;
    uint32 expires;
    uint32 fillDeadline;
    address inputOracle;
    uint256[2][] inputs;
    MandateOutput[] outputs;
}
```

其中 `uint256[2][] inputs === [uint256 tokenId, uint256 amount][]` 和 `MandateOutput` 是：

```solidity theme={"system"}
struct MandateOutput {
    bytes32 oracle;
    bytes32 settler;
    uint256 chainId;
    bytes32 token;
    uint256 amount;
    bytes32 recipient;
    bytes call;
    bytes context;
}
```

有关收集订单的更多信息，[查看订单收集指南 →](/zh-Hans/lifi-intents/for-solvers/orderflow)

## 填充意图

要填充意图，必须执行所有 `MandateOutput`。每个 `MandateOutput` 都是一个独立的执行描述。

* `output.settler` 使用其关联的上下文定义执行，并应在其接口上调用。目前，只实现了一个 OutputSettler：[`OutputSettlerCoin.sol`](https://github.com/openintentsframework/oif-contracts/blob/3e4682f4366a6dd0aa46be59b5922c2231a52d41/src/output/coin/OutputSettlerCoin.sol)，它有两个填充接口：

```solidity theme={"system"}
/// @notice 用于实现自己的批处理功能
function fill(
    uint32 fillDeadline,
    bytes32 orderId,
    MandateOutput calldata output,
    bytes32 proposedSolver
) external returns (bytes32 actualSolver);

/// @notice 用于批量填充整个订单。
function fillOrderOutputs(
    uint32 fillDeadline,
    bytes32 orderId,
    MandateOutput[] calldata outputs,
    bytes32 proposedSolver
) external;
```

有关填充意图的更多信息，[查看 EVM 订单填充指南 →](/zh-Hans/lifi-intents/for-solvers/evm)

## 验证填充

填充意图后，必须将填充证明发送到输入链。订单使用的预言机系统通过 `localOracle` 和 `output.oracle` 指定。这些应该匹配。但是，验证已填充的输出高度依赖于预言机。有关更多信息，[查看预言机系统架构 ->](/zh-Hans/lifi-intents/architecture/oracle-systems#implemented-validation-interfaces) ->

## 结算订单

最后，意图必须在到期之前结算。这是通过在指定的 InputSettler 上调用 `finalise[withSignature]` 来实现的。调用者必须是填充时设置的指定求解器。

```solidity theme={"system"}
struct SolveParams(
    uint32 timestamp;
    bytes32 solver;
)
// 对于 Compact 输入结算器
function finalise(
    StandardOrder calldata order,
    bytes calldata signatures,
    SolveParams[] calldata solveParams,
    bytes32 destination,
    bytes calldata call
) external;
// 或对于托管输入结算器
function finalise(
    StandardOrder calldata order,
    SolveParams[] calldata solveParams,
    bytes32 destination,
    bytes calldata call
) external;
```

有关结算订单的更多信息，[查看订单结算指南 →](/zh-Hans/lifi-intents/for-solvers/settlement)