跨链数据包：证明完成、超时或仍待处理
IBC确认可以携带应用错误；超时条件可能已满足，却尚未处理；协议描述可退款，也不代表已查到实际到账。跨链资产研究应分开数据包运输、应用结果与资产结算。
逐包建账，不用单个completed标志。目标是确定每份原始数量去向，避免把所有ACK都认作成功交付，或把时间已过都记为资产已收回。
固定规范与部署范围
本文实际读取完整提交bdfe570beb5cec017da89ce08e7b87ae2bd34a38下的ICS004通道与数据包语义和ICS020同质代币转移第一版。
它们是参考材料，不是任何真实部署兼容证书。ICS20页列ibc-go v10.0.0、ibc-rs v0.53.0，ICS4页自列ibc-go v7.0.0。真实调查必须匹配实际核心、应用实现和协商channel版本，不能把两页标题当全部组合已兼容。
ICS4的Synopsis明确通道对payload无感，运输语义不会独立规定代币应用确认的含义。这里假设案例的应用层依据，是固定ICS20的Data Structures与Routing module callbacks。
给每包可复现身份
保存源链、源port、源channel和sequence，以及目标标识与原始包字节。sequence不是全局唯一，不能因为序号或金额相同就合并不同channel的数据包。
保留denomination trace、原始金额、sender、receiver、timeout height与timestamp。跨链比较数量前，先建立适用面额和转换关系，相同符号不够。
源、目标分别保存区块参照。两链独立推进，不存在一个普遍同步的“同一时刻”。截止说明应写每侧实际检查的状态，以及尚待消息或证明。
两层解读ACK
固定ICS20结构将成功result与错误字符串分开。保存应用原始ACK，按实际格式解码；有字节或运输确认事件，不会单独告诉你成功还是失败。
还应区分目标侧已写确认，与其证明已在源侧处理。后者可能触发退款相关逻辑，一张目标ACK截图不证明源侧也已完成过渡。
参考规范同时含结构化schema与示意回调伪代码。真实解码应匹配部署序列化，不把伪代码success成员当普遍线上字段。未知或畸形消息留未知，不能乐观归成功。
假设主例：四包合计一百
设虚构兼容环境实现相关ICS20转移行为。所有数量已按有依据的一比一关系换成原始资产单位，假设没有税费、middleware费用或面额错配。四包合计发送一百。
| 包 | 数量 | 截止运输结果 | 应用结果 | 已核资产状态 |
|---|---|---|---|---|
| P一 | 六十 | 源侧ACK已处理 | 成功确认 | 接收者有六十 |
| P二 | 十 | 源侧ACK已处理 | 错误确认 | sender退款十已核 |
| P三 | 十五 | 所需证明下timeout已处理 | timeout回调 | sender退款十五已核 |
| P四 | 十五 | 无已核终态 | 未解决 | 十五留待处理 |
包数是两包确认、一包超时、一包未知。附着这些状态的数量为七十已确认、十五超时、十五待处理。七十是资产单位，不是七十个包，不能混分母。
资产对账则为六十交付，加错误后退十，加超时后退十五，加未知十五，合计一百。已完成退款二十五，交付加退款八十五，剩十五未知。
把七十ACK单位全叫接收成功，会多计十；把所有未交付都叫丢失，又会误计已退二十五。分开的四栏防止这两种错误，也说明终态运输不等于同一方向资产成功。
若只保留百分比，会失去每包证据。应能够从六十回到P一原字节、接收状态与截止区块，从二十五回到P二和P三两条不同恢复机制，不能用总额相平代替逐包核验。
沿应用逻辑追退款
固定ICS20回调描述错误ACK和timeout的退款，refundTokens还区分归还源侧托管资产与相应方向恢复凭证。应检查具体分支，不能假设每个退款都是同种链原生币转账。
P二、P三应保存源侧处理交易、应用结果、正确面额下sender实际余额或收款证据。协议有路径是机制证据，而“已核退款”列还要观察结果。
不能把退款和原锁定数量当两份独立资产。做经济供应对账时，要保留技术阶段，再按真实机制消除重复权利。本表确定结算状态，不独自审计整个桥储备。
对于余额差，核对同区间其他流量。sender同时有别的收付款时，净余额增加可能不等于这笔退款；最好取得明确事件或状态过渡关系，无法分开就说明归因尚未完成。
不同边界：时间已过，尚未处理
假设P四在相关对手链上下文已超过规定条件，但未取得有效timeout过渡或退款。研究截止仍列待处理，时钟经过不是成功timeout交易。
固定ICS4超时讨论需要证明该包按适用规则不能再被接收，正确证明与状态过渡很重要。目标查询不可用或浏览器没显示事件，不自动构成已验证未接收证明。
若满足期限、处理timeout和实际退款在三次不同观察出现，就保存三日期。不能把后来的退款倒填成截止期限当天，也不能说中间始终可以取用。恢复事实与中间访问能力需要分别表述。
不同边界：交付先于ACK回传
包可以已有目标应用到账证据，但相应ACK尚未在源侧处理。此时报告目标资产已观察到，源运输状态仍有待办；不要强行压成一个success，也不将同数量算两次结算。
反过来，错误ACK已知而源退款未核，也应分开。应该退款的机制不能替代缺失收款材料。新增证明到达后更新对应列，不覆盖之前真正未知的状态。
middleware可能引入转发、额外动作和确认语义，存在时需检查协商栈与实现。若费用或转发改变发送与收到单位关系，就不能照搬四包一比一数量，把差异全解释成丢币。
保持观察队列闭合
给每个原始包一个主状态，保证原数量不会从表中消失，同时允许运输与资产列不同步。错误ACK后待退款不应同时列“已退”和“未知余额”，需要明确哪一列已核、哪一列等待。
例如P二只有错误ACK而未核到十退款时，原表应将已退从二十五改为十五，另列错误待退款十，而不是维持八十五已解决总额。这个变化来自证据覆盖，不是声称真实机制从此不退。
建立原始队列的完整性
原始队列应来自发送记录，不只查当前尚存commitment。commitment不再出现可能代表后续已处理过渡，不证明该包从未存在。历史包身份和终态证据应连起来，否则只查未结状态会漏掉对账最需要的已确认、已超时包。
例如P二错误ACK已核、十退款未观察时，已核退款由二十五降十五，交付加已核退款为七十五；十为错误待退款证据，另十五为其他未解决。不能因规范应退款就继续保留八十五已解决总量。改变的是证据覆盖，不是断言机制不再退款。
每包分别记录发送观察、目标结果、源侧处理和资产核验的取得时间。晚取得的旧结果可以补完账，但不应改写成截止时已经检查完。若两条链的来源日期不同，就保留不对称覆盖，不用一个统一更新时间掩盖缺失。
当前查询缺少历史发送材料时，应把队列完整性列为未核，而不是用已发现四包的百分比代表全部跨链活动。包级账可以精确描述被覆盖集合，其范围与总桥业务量仍是两件事。
解码前核应用边界的序列化。固定ICS20说明packet与ACK数据采用JSON，ICS4另讨论建议的通用确认封装，不能用单一通用解析器静默替代实际应用格式。保留原始字节、所选schema与解码错误，不把解析失败当空成功结果。字段名也要按真实消息，而非把示意代码里的布尔成员直接当线上结构。
可执行发布清单
| 操作 | 保存材料 | 暂停条件 |
|---|---|---|
| 匹配实现 | 核心、应用、协商版本 | 仅参考页标题作兼容依据 |
| 固定包身份 | 双链、port、channel、sequence、字节 | 把序号当全局唯一 |
| 解应用确认 | 部署schema下原始成功或错误 | 所有ACK都叫交付 |
| 查源处理 | ACK或timeout过渡及证明 | 只有目标事件或时间已过 |
| 查资产 | 正确面额、接收者、数量 | 收款或退款只是预期 |
| 对队列 | 原始单位的交付、退款、未知 | 状态重叠或数量消失 |
ACK中继、timeout证明到达、退款观察或面额解释改变后，应重核。分别发布运输、应用和实际资产位置。待处理是可行动证据缺口，不是永久损失预测，也不是最终必恢复的保证。
常见问题
有ACK就说明代币成功到账吗？
不是。应用确认可能携带错误，需要解码并核实际资产结果。
超时条件已满足是否自动说明sender收到退款？
不是。条件、处理与观察退款是有各自证据和日期的不同事实。