订单结构
LI.FI 意图使用 OIF 的StandardOrder,它支持单链输入和多链输出。
字段参考
输出字段
选择资源锁
资源锁决定了在解算器填充订单期间用户资金如何被持有。
如果您要在其他桥接之外添加 LI.FI Intents,推荐使用 Simple Escrow。如果您正在构建资源锁优先的应用,请考虑使用 The Compact。有关注册详情,请参阅输入结算。
提交订单
对于非无 gas 的托管集成,请在链上提交订单(例如通过open / openFor 流程),并使用订单服务器进行报价发现 + 状态跟踪。
仅当您的集成需要链下订单提交时(例如无 gas 托管或签名的 Compact 领取),才使用 POST /orders/submit。如果您使用了来自订单服务器的报价,请包含 quoteId 以获得优先处理。
orderIdentifier 和 onChainOrderId 的 meta 对象用于跟踪。
链上 vs 链下订单
订单服务器是一个便利层,而非链上订单的必需项。所有链上意图都可以在不使用它的情况下提交。一些解算器会独立检测链上意图。
交付时调用
每个MandateOutput 都支持一个 call 字段,用于在代币交付后在目标链上执行的 calldata。接收方先收到代币,然后输出 settler 在 recipient 合约上调用 outputFilled(bytes32 token, uint256 amount, bytes executionData)。
在使用交付时调用时:
- 对于每个单独的输出,代币在调用执行之前交付
- 如果调用失败,则整个意图无法被填充
- recipient 必须是实现了
outputFilled的合约,而非 EOA - 对于多链输出,只有第一个输出应包含 calldata
outputFilled 中。如果您需要 SCA 实现,请联系 LI.FI。
意图验证
在提交之前,请根据以下规则验证您的订单。安全性
- 确保 oracle 网络相对于意图价值是安全的
- 所有 oracle(输入和输出)都应属于同一个网络
- 多输出订单可能容易受到 DoS 攻击,即仅填充第一个输出。请将第一个输出设为最有价值的。
- 来自输出 settler 的调用不能用于认证,因为任何人都可以填充输出
- 将
user设置为预期的退款接收方,而非意图发起方或中继地址。
正确性
- 使用已知的、可靠的代币、结算合约和 oracle
- 使用尽可能少的代币。低价值或不知名的代币会降低填充的可能性。
- 在
fillDeadline和expires之间留出足够的时间以适应消息传递延迟 - 确保 nonce 是唯一的。托管要求用户唯一性,而 The Compact 要求 allocator 唯一性。
- 对于 The Compact,确保所有输入共享同一个 allocator,且资源锁的过期时间在意图过期时间之后
后续步骤
跟踪订单状态
监控订单进度并处理终态
请求报价
在构造订单之前获取解算器定价
输入结算
托管和 Compact 注册详情
Oracle 系统
Oracle 网络和验证

