交易状态
本指南说明如何使用 LI.FI 提供的/status 端点检查跨链和交换交易的状态。
查询 status 端点
要获取转账状态,可以使用以下任一值查询/status 端点:
- 发送交易哈希
- 接收交易哈希
- transactionId
上述值只需提供其中一个,并需要通过
txHash 参数传入。必填:
txHash
可选:
fromChain:加快请求速度(推荐)toChainbridge
fromChain 和 toChain 设置为相同的值。bridge 参数可以省略。
示例响应
报价金额与成交金额
当 LI.FI 为该笔转账签发过报价时,GET /v1/status 会带上可选的 quote 对象,用来核对报价时的估算与实际结算结果。
quote.action是当时请求的内容。quote.estimate记录报价金额与成本(toAmount、toAmountMin、费用、gas)。sending和receiving是实际成交的两端。用receiving.amount对比quote.estimate.toAmount和quote.estimate.toAmountMin。
/quote 或 /stepTransaction、由合作方导入,或记录早于报价持久化。省略不是错误,也不会改变 status 或 substatus。
quote 在 status 仍为 PENDING 时就可能出现,因为它来自报价时的记录,而不是目标链结算。
完整 schema 见 GET /v1/status API 参考。
Quote 对象
内部数据库字段会被去掉,不会出现在响应里。
核对已完成的转账
- 轮询
/status,直到status为DONE。 - 若存在
quote,把receiving.amount与quote.estimate.toAmountMin(报价最低值)和quote.estimate.toAmount(报价估值)比较。 substatus: COMPLETED表示转账成功结束,并不表示receiving.amount等于quote.estimate.toAmount。实际到账可以与报价估值不同,但仍不低于toAmountMin。- 若不是足额交付,结合
PARTIAL/REFUNDED和金额一起看。
示例
2026-09-14 在生产环境观察到的GET /v1/status(已精简)。报价 toAmount 为 377946589;实际 receiving.amount 为 377639049,仍高于 toAmountMin 376056856。
状态值
当 LI.FI 无法找到该哈希时,如果未提供
/status 可能返回 HTTP 404 和错误代码 1003(其他查询路径仍可能返回 NOT_FOUND 响应体):fromChain,消息会是 Transaction hash is not found in any chain.。请将此响应视为 NOT_FOUND:广播后的头一两分钟内出现是正常的,如果持续存在则可能存在问题。参见未知和永远不会被打包的交易哈希。子状态定义
PENDING
WAIT_SOURCE_CONFIRMATIONS:等待源链确认WAIT_DESTINATION_TRANSACTION:等待目标交易BRIDGE_NOT_AVAILABLE:桥接 API 不可用CHAIN_NOT_AVAILABLE:源链/目标链 RPC 不可用REFUND_IN_PROGRESS:退款进行中(如果支持)UNKNOWN_ERROR:状态不确定
DONE
COMPLETED:转账成功PARTIAL:仅完成部分转账(常见于 across、hop、stargate、amarok)REFUNDED:代币已退回
FAILED
NOT_PROCESSABLE_REFUND_NEEDED:无法完成,需要退款OUT_OF_GAS:交易 gas 耗尽SLIPPAGE_EXCEEDED:接收金额过低INSUFFICIENT_ALLOWANCE:授权额度不足INSUFFICIENT_BALANCE:余额不足EXPIRED:交易已过期UNKNOWN_ERROR:未知或无效状态REFUNDED:代币已退回
未知和永远不会被打包的交易哈希
LI.FI 查不到哈希,并不证明交易没有上链。原因可能是索引延迟、源链选择错误、交易仍在等待、被替换、从 mempool 丢弃,或记录的哈希并非最终广播的交易哈希。被丢弃的交易之后仍可能重新广播。- 按源链情况设置有限的轮询窗口并采用退避策略;等待时间不是失败证据。
- 先在正确源链上查询原哈希的收据(EVM 使用
eth_getTransactionReceipt)。有收据表示原交易已上链,不应判为被替换:执行失败则按源链失败处理;执行成功则继续核对 LI.FI 和跨链后续状态。按应用要求等待确认,并考虑链重组。 - 没有收据时,再查原交易(EVM 使用
eth_getTransactionByHash)。仍处于 pending 时不能判为被替换;RPC 查不到或查询失败也不证明交易已被丢弃。 - 对普通 EVM 账户交易,可用
eth_getTransactionCount的latestnonce 缩小调查范围,但 nonce 前进也可能是原交易上链造成的。只有核实另一笔交易在同一源链、由同一发送账户使用同一 nonce 上链后,才能确认替换;不要用pendingnonce 证明上链。这套 nonce 规则不适用于非 EVM 交易或账户抽象的操作标识。 - 在将替代哈希绑定到原订单前,检查它实际执行的操作(接收方、value、calldata 及相关事件)是否延续原转账。加速、取消、改变用途都可能使用同一 nonce。取消不代表完成跨链操作;未知原始 nonce 或用途时,不自动绑定。
按钱包核对
当被跟踪的哈希未知,但用户的资金可能已经在另一个哈希下发生了转移时,请改为查询该钱包的转账记录,而不是查询哈希:status=ALL 才会同时纳入 DONE、PENDING 和 FAILED;默认只返回 DONE。这些只是 LI.FI 已索引的候选,不是完整链上历史;没有结果不证明未发生替换。响应示例:
sending.txHash,按上述流程核对源链、发送方、nonce、收据和用途;全部核实后才绑定原订单,并继续使用 /status?txHash=<sending.txHash> 跟踪。可选过滤条件包括 fromChain、toChain、integrator。参见 transfers 端点参考。
轮询指南
DONE和FAILED是终态。一旦收到其中之一,应立即停止轮询。- 采用退避策略:第一分钟内每 10 秒轮询一次,随后改为 30 秒,再改为 60 秒,并设置总时长上限。大多数 bridge 会在报价的
estimate.executionDuration时间内完成。 - 持续的
404/1003(或NOT_FOUND)不是终态证据。按上述源链流程核查;暂停轮询不等于确认失败或替换。

