> ## 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.
# 创建并提交订单
> 构造一个 StandardOrder，选择资源锁，附加可选的 calldata，并提交到 LI.FI Intents 解算器网络。
订单（意图）描述了用户想要什么：输入资产、期望的输出、结算参数和截止时间。构造完成后，将其提交到订单服务器以分发到解算器网络。
***
## 订单结构
LI.FI 意图使用 OIF 的 `StandardOrder`，它支持单链输入和多链输出。
```ts theme={"system"}
type StandardOrder = {
user: `0x${string}`;
nonce: bigint;
originChainId: bigint;
expires: number;
fillDeadline: number;
inputOracle: `0x${string}`;
inputs: [bigint, bigint][];
outputs: MandateOutput[];
};
type MandateOutput = {
oracle: `0x${string}`;
settler: `0x${string}`;
chainId: bigint;
token: `0x${string}`;
amount: bigint;
recipient: `0x${string}`;
call: `0x${string}`;
context: `0x${string}`;
};
```
### 字段参考
| 字段 | 描述 |
| --------------- | ---------------------------------------------------------------------------------------------------------------- |
| `user` | 输入资产的所有者。如果订单未被填充，则为退款接收方。 |
| `nonce` | 每个订单的唯一标识符。对于 The Compact，这是一个 allocator nonce。 |
| `originChainId` | 意图发起的链 |
| `expires` | 提交订单已被填充的证明的截止时间（unix 时间戳）。在此之后，订单可以退款。 |
| `fillDeadline` | 解算器填充订单的截止时间。必须早于 `expires`。 |
| `inputOracle` | 源链上的 oracle 地址。必须与 `outputs[].oracle` 对应。 |
| `inputs` | 以 `uint256` 表示的 `[tokenIdentifier, amount]` 对数组。对于托管，token 标识符是转换为 `uint256` 的地址。对于 The Compact，它是 ERC-6909 标识符。 |
| `outputs` | 描述期望交付的 `MandateOutput` 数组 |
### 输出字段
| 字段 | 描述 |
| ----------- | --------------------------------------------------- |
| `oracle` | 输出链上的 oracle 地址。必须与 `inputOracle` 处于同一个 oracle 网络中。 |
| `settler` | 输出 settler 合约。决定拍卖类型和结算逻辑。 |
| `chainId` | 目标链标识符 |
| `token` | 目标链上的 token 标识符 |
| `amount` | 输出 token 数额 |
| `recipient` | 输出代币和任何 calldata 的接收方地址 |
| `call` | 在代币交付后交付给 `recipient` 的 calldata。如不需要则设为 `0x`。 |
| `context` | 拍卖参数和结算上下文。对于简单的限价单，设为 `0x`。 |
***
## 选择资源锁
资源锁决定了在解算器填充订单期间用户资金如何被持有。
| 锁 | 最适用于 | 工作原理 |
| --------------------------------------- | ---------------- | -------------------------------------- |
| **Simple Escrow**（`InputSettlerEscrow`） | 与非资源锁桥接一同使用的标准集成 | 用户批准托管合约（通过直接批准或 Permit2）。代币按每笔意图进行托管。 |
| **The Compact**（`InputSettlerCompact`） | 资源锁原生应用 | 长期存款。用户存入一次即可从同一余额发出多个意图。 |
如果您要在其他桥接之外添加 LI.FI Intents，推荐使用 Simple Escrow。如果您正在构建资源锁优先的应用，请考虑使用 The Compact。有关注册详情，请参阅[输入结算](/lifi-intents/architecture/input-settlement)。
***
## 提交订单
对于非无 gas 的托管集成，请在链上提交订单（例如通过 `open` / `openFor` 流程），并使用订单服务器进行报价发现 + 状态跟踪。
仅当您的集成需要链下订单提交时（例如无 gas 托管或签名的 Compact 领取），才使用 `POST /orders/submit`。如果您使用了来自订单服务器的报价，请包含 `quoteId` 以获得优先处理。
```bash curl theme={"system"}
curl -X POST 'https://order.li.fi/orders/submit' \
-H 'Content-Type: application/json' \
-d '{
"orderType": "CatalystCompactOrder",
"inputSettler": "0x0000000000cd5f7fDEc90a03a31F79E5Fbc6A9Cf",
"quoteId": "QUOTE_ID_FROM_STEP_1",
"order": {
"expires": 1942819670,
"user": "0xYOUR_WALLET_ADDRESS",
"nonce": "1004",
"originChainId": "8453",
"fillDeadline": 1942819670,
"inputOracle": "0x008C3800F3Ad9b3B662d002E90Cc00000000eE17",
"inputs": [
["749071750893463290574776461331093852760741783827", "10000000"]
],
"outputs": [{
"oracle": "0x000000000000000000000000008C3800F3Ad9b3B662d002E90Cc00000000eE17",
"settler": "0x00000000000000000000000075220B7600c300005038432a0000f308e0000068",
"chainId": "42161",
"token": "0x000000000000000000000000af88d065e77c8cC2239327C5EDb3A432268e5831",
"amount": "9986765",
"recipient": "0x000000000000000000000000YOUR_WALLET_ADDRESS",
"callbackData": "0x",
"context": "0x"
}]
}
}'
```
响应包含完整的订单、关联的报价（如有）以及一个带有 `orderIdentifier` 和 `onChainOrderId` 的 `meta` 对象用于跟踪。
这是一个参考模板。`CatalystCompactOrder` 提交需要 sponsor 签名或 Compact 注册的交易哈希。在主网上线之前，请始终在 `order-dev.li.fi` 上进行验证。
***
## 链上 vs 链下订单
| 类型 | 示例 | 是否需要订单服务器？ |
| ------------- | ------------------------- | ------------------------------ |
| **链上** | 已打开的托管意图、已注册的 Compact 领取 | 否。解算器和订单服务器会自动检测这些。 |
| **链下（无 gas）** | 无 gas 托管意图、签名的 Compact 领取 | 是。通过 `POST /orders/submit` 提交。 |
订单服务器是一个便利层，而非链上订单的必需项。所有链上意图都可以在不使用它的情况下提交。一些解算器会独立检测链上意图。
***
## 交付时调用
每个 `MandateOutput` 都支持一个 `call` 字段，用于在代币交付后在目标链上执行的 calldata。接收方先收到代币，然后输出 settler 在 `recipient` 合约上调用 `outputFilled(bytes32 token, uint256 amount, bytes executionData)`。
在使用交付时调用时：
* 对于每个单独的输出，代币在调用执行之前交付
* 如果调用失败，则整个意图无法被填充
* recipient 必须是实现了 `outputFilled` 的合约，而非 EOA
* 对于多链输出，只有第一个输出应包含 calldata
对于任意合约调用，请使用批处理合约或 Single-Call Architecture (SCA) 包装器，因为调用被包装在 `outputFilled` 中。如果您需要 SCA 实现，请联系 LI.FI。
***
## 意图验证
在提交之前，请根据以下规则验证您的订单。
### 安全性
1. 确保 oracle 网络相对于意图价值是安全的
2. 所有 oracle（输入和输出）都应属于同一个网络
3. 多输出订单可能容易受到 DoS 攻击，即仅填充第一个输出。请将第一个输出设为最有价值的。
4. 来自输出 settler 的调用不能用于认证，因为任何人都可以填充输出
5. 将 `user` 设置为预期的退款接收方，而非意图发起方或中继地址。
确保退款接收方能够正确接收和处理资金。使用无法接受代币的地址（例如没有 receive 函数的合约，或错误的链地址）将导致资金永久损失。
### 正确性
1. 使用已知的、可靠的代币、结算合约和 oracle
2. 使用尽可能少的代币。低价值或不知名的代币会降低填充的可能性。
3. 在 `fillDeadline` 和 `expires` 之间留出足够的时间以适应消息传递延迟
4. 确保 nonce 是唯一的。托管要求用户唯一性，而 The Compact 要求 allocator 唯一性。
5. 对于 The Compact，确保所有输入共享同一个 allocator，且资源锁的过期时间在意图过期时间之后
***
## 后续步骤
监控订单进度并处理终态
在构造订单之前获取解算器定价
托管和 Compact 注册详情
Oracle 网络和验证