订单服务器状态
调用GET /orders/status,附带您提交订单时返回的 onChainOrderId 或 catalystOrderId。
查询参数
至少需要一个参数。
响应
响应包含完整的订单、任何关联的报价,以及一个带有状态信息的meta 对象。
状态生命周期
meta.orderStatus 取以下四个值之一:
其路径为
Signed → Delivered → Settled,Refunded 是另一种终态。
Signed 涵盖填充之前的所有情况,包括链上的 Open 事件——开启订单本身不会产生一个独立的状态。如果您需要确认订单已经上链,请关注 meta.orderInitiatedTxHash。
GET /orders 的 ?status= 过滤参数也接受 Submitted 和 Open 这两个值,但 meta.orderStatus 永远不会返回它们——匹配这些过滤条件的订单会显示为 Signed。
需要特别注意:不要等待 WebSocket 的
Settled 事件——表示成功的终态事件名为 Finalised。
轮询示例
order.expires 已过(或 meta.expiredAt 已被设置),订单就无法再被填充——但这不等同于已经退款。只有当 orderStatus 为 Refunded 且 refundTxHash 已设置时,用户的资金才算真正退回;因此过期后应继续轮询(以较低的频率),并展示”退款处理中”的状态,而不是直接报告完成。
列出订单
使用GET /orders 通过过滤器查询多个订单。订单服务器会将响应缓存几秒钟,对过于频繁的轮询可能会限流或暂时超时。
链上事件
您也可以直接从合约事件跟踪订单。orderId 在所有相关事件上都作为 topic1 发出。
订单已打开
输出已填充(由求解器)
订单已完结(结算完成)
订单已退款
orderId 是确定性的,其计算方式为:
Solana 事件
在 Solana 上,各程序发出的是 Anchor 事件而非 Solidity 事件,每个生命周期步骤对应一个:
Solana 的
order_id 由内容派生:keccak256(borsh_serialize(StandardOrder))。intents_protocol 程序还会发出认证和配置层面的事件,列在 Solana 程序的”认证”部分中。
后续步骤
API 概述
完整的端点参考和 Base URL
创建并提交订单
订单构造和提交
结算
输入和输出结算的工作原理
系统概述
Intent/Solver Marketplace 的完整架构

