Supra MoveVM 核对已有交易记录：网络、v3 状态与历史裁剪
链小知 · 进阶 · 核验 · 依官方文档整理
比对已有 REST 响应的 chain ID、交易类型和状态，区分成功执行、待定状态与节点无法提供历史数据。
开始前准备
- 准备公开交易 hash 与已有脱敏 MoveVM REST 请求/响应、HTTP 状态、响应头及采集时间；不使用钥匙、authenticator 原始签名或真实用户 secrets。
- 本教程从已有记录开始；仅阅读官方接口文档，不发送交易、模拟、faucet 或生产查询。
1. 定位 MoveVM 网络和 API 版本
先从官方 MoveVM Network Information 对照已有请求 host：rpc-mainnet.supra.com 对应 chain ID8，rpc-testnet.supra.com 对应6。
当前主网规范为 supra_node_v11.7.0。交易读取使用 GET /rpc/v3/transactions/{hash}；旧 v2 方法已标 deprecated，不把 Supra EVM、Oracles REST 或第三方同名索引服务混用。
检查结果：host、网络与规范版本已标记，记录中的 x-supra-chain-id 与预期一致。
2. 对照 hash、筛选条件与响应格式
已有请求的 path hash 应等于要查的 hash。type 可为 auto、user、meta、record；若无此参数按全部类型查询，限制类型可能改变结果。
exclude_uncommitted=true 会排除尚未 committed 的交易。检查响应 Content-Type；v3 可返回 JSON、BCS 或 octet-stream，二进制不能直接套用 JSON 字段。
检查结果：记录的参数和解析格式完整；筛选后的缺失不直接解释为交易不存在。
3. 根据 txn_type 选择字段
TransactionV3 是多种对象的联合类型：user 与 automated 使用含 hash/header/payload/status 的交易信息，block_metadata 与 automation_record 结构不同。
先读 txn_type 再选择相应 schema。不要把所有记录都按用户转账解析，也不要从 authentication_key 或响应附带的认证数据推出钱包由谁控制。
检查结果：已确认对象类型，hash 与目标对应，非用户交易没有被当作用户收款。
4. 把执行状态与区块信息分开
官方 TxExecutionStatus 包含 Success、Fail、Invalid、PendingAfterExecution、Pending。HTTP200 只表示返回数据，待定值不能当成功。
user/automated 的 block_header 与 output 可以为 null。区块关联、执行结果和预期收款方/金额属于不同证据；即使状态 Success，也需已有业务记录核对实际作用，不能只凭状态证明到账正确。
检查结果：保留完整状态原值，明确已核结果与缺失输出；不将待定或单一状态扩展为到账结论。
5. 解释区块查询的缺失与裁剪
如果已有相关 GET /rpc/v3/block/height/{height} 记录为404，规范仅说所需数据不可用；410 则说明已裁剪，查看 x-supra-oldest-block 记录历史边界。
不能把某节点无法提供旧区块推导为链上从未有交易，也不能把其它高度返回200当作目标交易被确认。保留原HTTP状态、message及查询高度。
检查结果：404、410、正常数据分别归类，裁剪边界与具体记录可追溯。
6. 形成有限范围的核对结论
整理 host/chain ID、请求版本、hash、type筛选、采集时间、txn_type、执行状态及区块/输出缺项。只有已有证据同时对应网络、交易和预期业务时才给具体结论。
公共规范未提供本次可确认的调用配额、当前价格或 SLA；也未测业务接口可用性。缺记录时写待核，不通过提交交易或调用 GET faucet 补测。
检查结果：结果能够复查原记录，未知费用/配额/业务结果保持未知；无新增链上动作。
怎样确认完成
- 已有交易记录按网络、版本、类型与状态核对完成，历史读取限制与缺证范围明确。
- 验证为文档整理，没有真实业务查询、模拟、签名或广播。
常见错误与边界
- 用 EVM chain ID 或预言机链列表解释 MoveVM 交易。
- 把 HTTP200、Success 或区块对象中的任一项直接视为正确到账。
- 把410历史裁剪解释为交易不存在，或认为所有GET均只读。