跳转到主要内容
提交订单后,您可以通过订单服务器 API 或直接监控链上事件来跟踪其进度。

订单服务器状态

调用 GET /orders/status,附带您提交订单时返回的 onChainOrderId 或 catalystOrderId。

查询参数

至少需要一个参数。

响应

响应包含完整的订单、任何关联的报价,以及一个带有状态信息的 meta 对象。

状态生命周期

meta.orderStatus 取以下四个值之一: 其路径为 Signed → Delivered → Settled,Refunded 是另一种终态。 Signed 涵盖填充之前的所有情况,包括链上的 Open 事件——开启订单本身不会产生一个独立的状态。如果您需要确认订单已经上链,请关注 meta.orderInitiatedTxHash。
GET /orders 的 ?status= 过滤参数也接受 Submitted 和 Open 这两个值,但 meta.orderStatus 永远不会返回它们——匹配这些过滤条件的订单会显示为 Signed。
REST 响应和面向求解器的 WebSocket 信息流对同一组状态使用不同的名称。对应关系如下: 需要特别注意:不要等待 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 的完整架构