IBC回执和超时状态怎么查？

IBC 的源链交易成功，只能证明 packet 被写入发送侧状态。完整流程还包括目标链接收、写 acknowledgement、回执返回，或者超过条件后的 timeout。把这四段混成一个“跨链成功”，会让排障和退款判断同时失真。

从send_packet追到回执返回

1. 从源链 send_packet 事件提取完整 packet 标识。
2. 在目标链按 sequence 查询 receipt、recv_packet 事件和应用处理结果。
3. 若有 acknowledgement，验证其证明已回到源链并触发对应回调。
4. 若无接收且已过阈值，再按通道类型检查 timeout 资格与退款结果。

Packet 的主键不只有交易哈希

排查至少保存 source port、source channel、sequence、destination port、destination channel、timeout height 与 timeout timestamp。相同交易可包含多个 packet；sequence 才是通道内定位收据和 acknowledgement 的关键字段。

一只Packet留下哪些凭据

1. Packet 的主键不只有交易哈希：IBC数据包从源链发送后，需要Relayer提交到目标链；目标链可写入acknowledgement，再由Relayer把回执带回源链。
2. Receipt 与 Acknowledgement 不是一回事：数据包必须具有非零timeout height或timeout timestamp；超过条件且未接收时可走timeout证明与应用回滚逻辑。
3. Timeout 需要目标链证明：有序与无序通道对超时的处理不同，有序通道中某些超时会关闭通道，不能只凭源链成功判断业务完成。

Receipt 与 Acknowledgement 不是一回事

无序通道的 receipt 证明某个 sequence 已被接收；应用处理后还可写 acknowledgement，内容由应用协议解释。Relayer 再把 acknowledgement 证明提交回源链，源应用才执行成功或失败回调。看到目标链 receipt 不能擅自把业务 ack 写成成功。

错误Ack不能走普通超时

一个 ICS-20 转账可以出现“目标链已接收，但应用返回错误 acknowledgement”。此时应让回执回到源链执行退款逻辑，而不是把它当未接收 packet 发 timeout。两种失败的证据路径不同。

Timeout 需要目标链证明

超时不是本地时钟一到就退款。Relayer要证明目标链高度或时间已越过阈值，并证明 packet 未被接收；有序通道的超时还可能关闭通道。若 packet 已到目标链，即使前端没显示资产，也不能再走普通 timeout。

通道信息不全时不要补转

通道版本、应用 ack 编码或 ordered/unordered 类型不明时停止自动结论；不要根据前端的单个绿色图标决定补转。

为跨链客服保留Packet档案

运营台账可把每个Packet拆成发送、接收、应用处理、回执返回和超时资格五列，并用通道与sequence组成唯一键。Relayer切换不会改变这个主键；任何补偿动作都要引用原Packet证据，避免把界面延迟误当成第二笔跨链需求。

IBC状态判断的规范依据

1. Cosmos IBC Specification：用于核对IBC数据包回执与超时的候选主题的一手字段、产品说明或事件发现。
2. IBC Channel Semantics：用于核对IBC数据包回执与超时的实现路径、交叉验证或风险边界。

相关站内主题：XCM跨链排障、跨链到账核验。资料访问时间为2026-07-22；协议、接口、监管清单与产品界面均可能更新。

风险提示：IBC前端显示与链上Packet状态可能不同，未经接收证明就补转或超时，可能造成重复资金动作。先固定通道、Sequence与回执证据，再判断退款路径；本文不替代具体链和应用的运行规则。