投票通过一个参数修改之后，还有一个问题常被忽略：已经开着的仓按新参数管，还是继续按开仓那一刻的旧参数管？这个问题叫参数的适用边界，有的协议选择一律生效——所有仓位的健康因子立刻按新线计算；有的采用新人新办法，新参数只管新开的仓，存量仓位沿旧规走到还清或处置。后一种设计在别处被称为 grandfather 条款，它在 DeFi 里出现的次数远比在文档里被讨论的次数多。
先看两种写法各自防什么。一律生效的执行简单：参数是全局变量，改掉那一秒所有计算同步刷新，没有状态分叉、没有版本账本。代价是改参数的破坏力被放大：一次收紧清算线，等于把一批原本安全的存量仓位当场推近危险区，治理投票变成了对第三方仓位的强制动作。新人新办法把这层杀伤力卸掉：老仓位的风险假设在开仓时已定，协议承诺不追溯改契约，收紧只约束增量。代价是实现要多存一份按仓位记录参数的状态，且同一市场里新旧两套参数并存，计算路径翻倍。
适用边界的问题还常藏在参数类型里。抵押类参数——上限、折价率、清算线——是否追溯，直接关系存量借款人的命运，严肃协议会写进风险框架文档；费率类变更多数默认全局生效，因为利息按块重算、追溯反而复杂；时间型参数如冷却期、限速窗，对已在途的操作是否生效，是最容易漏写的角落。同一个新参数，对三类参数可能天然有三种答案，读文档别指望一句全局生效蒙住所有细节。
对存量仓位最隐蔽的坑是分界线不清。假设某市场把借款上限调低、并声明不追溯：老仓位保留借款身份，但老仓位想部分还款后再借回，那一刻它已执行了修改动作，会被归入新仓适用新参数吗？借新还旧与维持旧仓之间，协议实现会有不同分岔，有的以是否发生修改型交互为界，有的干脆让旧仓只出不进。这类细节通常藏在合约注释或风险文档的角落，而不是公告正文里。
把自己的仓位放进这个框架自查：这个参数变更声明了适用哪类仓位吗；你的仓位在变更后发生任何交互动作会不会被重分类；旧规待遇是终身制还是还完即收回。与参数监控的分工也要分清：监控提醒你参数变了，适用规则决定变了之后有没有烧到你——前者是工具，后者是契约，缺了后者，监控给你的是无法翻译的警报。
参数的适用边界很少被写进标题，但它比参数本身更早决定一次投票的影响半径。新人新办法把治理的手只按在增量上，一律生效让每次投票都重写所有存量的世界，没有免费的选择。读懂你的仓位挂在哪一边，等于读懂了协议对你这份合约的诚意刻度：它是在管理新增风险，还是在随时重画所有人的风险地图。
最后补一层迁移工程的视角：凡参数需要分新旧的协议，都背着一份状态账本，每个仓位记开仓版本、每次交互判新旧归属，这笔账要么存在仓位结构里、要么从交易历史重放推出来，前者费 gas、后者费计算。设计者选择哪条路，就会在压力时刻暴露哪种弱点——状态账本在拥堵时更贵，重放推演在极端行情下更慢。读协议的风险文档时留意它如何解释新旧参数并存，那一段文字同时回答了两个问题：它如何记账，以及它认为你的仓位在规则变更时处于什么地位。
本文为机制说明，不构成投资建议，不涉及任何收益承诺或买卖建议。链上参数、费率与清算规则随时可能变化，请以协议官方文档与链上合约当前状态为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。