逐笔核对一次清算的回执：从触发到抵押品处置要还原哪些字段

清算发生后的第一个问题往往不是为什么爆仓，而是那笔交易里到底转了哪些东西。协议页面上一行清算记录背后，是四五层彼此独立的账：谁提交的交易、协议事件里写了什么、内部调用把钱怎么搬了、代币层面各自余额变了多少。把这些对平，才谈得上知道损失由哪几段构成。

第一层是回执本身。状态字段告诉你整笔交易成败；失败的交易什么也没清算，只剩执行费用。 确认成功的那笔里，先记下发送方地址——这是字面意义上的触发人，通常是一名清算执行者或其路由合约。同一区块里若有多笔清算交易，回执顺序即执行顺序，这对理解后面的排队与竞争很重要。

第二层是事件日志。借贷协议在清算完成时会发出结构化的清算事件，典型字段包括：被清算的借款人、使用的抵押物种类与数量、偿还的债务种类与数量，以及清算本身使用的价格基准。事件里的数字是协议官方口径，罚金比例通常就编码在这次使用的价格与市场价之差里。把事件里的抵押数量记下来，后面所有核对都以它为锚。

第三层是内部调用轨迹。执行者很少用自有资金垫付还款，多数清算在同一个调用栈里完成借债、偿还、领取抵押、变卖四步，内部调用列表就是这四步的路线图。轨迹里若出现向资金池的大额转入和随后向某个兑换池的转出，基本可以断定执行者把没收的抵押当场换成了结算币。这一步的兑换池子不是借贷协议，滑点与损失归属也不同，把它混进协议罚金，就会把清算损失算得比实际大。

第四层是代币转账账。把借款人、协议池、执行者三方的余额变动拉出来做差：借款人应看到债务凭证减少、抵押凭证按事件数量减少；协议侧应看到抵押品入账与债务凭证注销；执行者侧的净得，是抵押变现所得减去垫付还款与兑换成本。三边各自对平，这笔清算的数字才算闭环。若执行者还额外向协议付了清算协议费或把一部分罚金分给了其他地址，转账账里都能找到对应记录。

对完账，常见误读基本可以逐条排掉。其一，把执行者的换币滑点记在借款人头上：滑点是市场成本，处置效率低不代表罚金高。其二，把清算价格当成市场价：协议按喂价和折价参数出价，处置瞬间的现货价可能已经变化，两者差额是机制设定而非数据错误。其三，以为部分清算失败等于没损失：多次触发的累计债务与累计罚金要跨回执加总，单看最后一笔会低估。

最后给一个动作顺序：先搜被清算人地址的事件流，锁定全部清算事件；再逐笔打开交易，看内部调用的路线终点落在哪类池子；然后拉三方代币余额的区间差；最后用协议文档里公开的罚金与费用参数复算一遍事件数字。复算对不上时，优先怀疑版本差异与参数改动时间，而不是浏览器显示错误。

补充一个常被忽略的时间维度：一笔清算的完整故事往往从触发之前就开始。健康度跌破线的瞬间与执行交易被打包之间可能隔着几个区块，这段时间里债务按秒计息、抵押市价继续漂移，最终抵偿比例与事件里记录的价格都可能被这段空窗改变。复盘时把触发前最后一次健康度变化、喂价更新所在区块、执行交易所在区块三个时间点标在一条线上，很多看起来说不通的差额，其实是这段时间的利息与价格漂移，而不是任何人的失误。

风险提示

事件字段名称与费用分配结构因协议与版本而异，本文描述的是通用核对框架，具体字段以各协议官方文档为准。清算处置存在滑点与机制风险，历史复盘不构成对未来的预测。本文不构成投资建议。