@BabylonLabs_io 把一次全额还款摊成三行账，会发现钱包里那些很接近的数字，脾气完全不同。
第一行是spending-cap。
它写的是合约最多可以调用多少。给TBV相关合约设置的上限高于真实欠款，多出来的只是权限空间，不会因为数字写得宽，就自动变成额外扣款。
第二行是这次实际还了多少。
用户读取债务、准备交易、等待确认的这段时间里，欠款仍可能继续变化。若提交的清偿金额低于确认时的实际债务，合约只能按收到的金额减债。交易可以成功，差额也可以继续挂在仓位里；“执行成功”和“债务归零”并不是同一个结果。
第三行才是执行后的剩余债务。
这行最安静，后果却最硬。spending-cap偏高，留下的是没有被使用的调用额度；实际还款偏低，留下的是仍需清偿的余额。两边都叫“和目标有一点误差”，方向一换，结果就从“没有多扣”变成“没有还完”。
拿$BABY 当前公开测试流程作例子，授权、实际扣款和债务余额会连续出现在一次操作里，很容易被当成同一个数字的三个版本。合约却分三次理解它们：先看权限够不够，再看交易实际交付多少，最后更新债务。它不会因为用户主观上点了“全部”，就把未覆盖的部分当作不存在。
这些借贷资产目前都是无真实价值的mock资产，三行账只能说明机制，拿去套真实亏损没有依据。固定buffer也不存在，确认时间一变，数字就可能跟着变。要核对的不是钱包曾经显示过多大的授权，而是交易落地以后，第三行到底还剩多少。
差别就在这里。多出来的授权停在门口，少掉的还款留在账上。#baby