DeFi 协议升级迁移：旧仓位搬家的兼容断层与双币风险

公告之外还要核对什么

升级信息的环境其实混杂：转述会漏掉生效条件，社区帖会把激励补贴写成保证。逐项核对能救你的是三类原始件：治理提案原文，它写清了谁投票、通过了什么、留了什么后门条款；部署清单，新版合约地址以官方文档列出的为准，公告里的任何地址都应与部署记录相互印证；变更日志中被轻描淡写的那几行——新增权限、暂停开关、参数上限——恰恰是未来风险敞口的来源。还有一个容易被情绪带偏的点：升级伴随的争议与分裂（同一家协议分出两条路线各自发版）会让旧仓位的归属与兼容性变成开放问题，此时更要先查清自己持有的资产在争议链条里的法律与技术位置，而不是跟着热度先跑。把核对当仪式而不是保险，是因为升级事件里真正丢钱的人，多数输在没打开那份文档，而不是输在技术判断力。

补一个迁移事件的时间管理建议：给自己设一个搬家日历而不是一句提醒——提案生效日、激励窗口中点、旧市场流动性明显衰减的观测点，三个日期各自对应一个动作（推演、执行、清零核查）。升级事件的损失多数来自拖到最后被迫高成本搬迁的仓位，日历把被动追事件变成按点办事，这就是全部诀窍。

升级不是软件更新

链上协议的大版本升级与手机应用更新是两回事：旧合约通常继续在线上运行，新版本以另一组合约地址上线，两套市场长期并存。没有中央服务器替你切换数据，你的存款、债务、LP仓位都还躺在旧地址里，等不来的那句自动迁移，就是这类事件最大的认知陷阱。

升级的合约组织方式

协议改底层逻辑的原因各不相同：修复结构性缺陷、引入新风控参数、改变清算方式或适配新资产标准。可行的路径无非几种——在新地址部署全新合约并把流动性引导过去；保留旧数据合约只替换执行层；或给旧合约加装代理指针指向新逻辑。三种方式对用户仓位的含义完全不同：换地址的升级要求你主动搬家；只换执行层的，你的资产地址不变但行为可能改变；加代理指针的，规则在某个区块高度被瞬间替换，你前一天读到的参数当场失效。哪个方案、何时生效，升级公告与治理提案里都写得出来，读这两处比读新闻转述可靠。

迁移窗口的经济学

新版本上线后，协议通常用激励引导流动性迁移：新市场给更高排放或补贴，旧市场停排或降权。于是出现一段两条市场并存、深度此消彼长的窗口期。窗口内旧资产与新资产往往一一对应但比价漂移——兑换通道刚建立时深度不足，折溢价比常态大；窗口末期旧市场流动性枯竭，届时再搬，冲击成本显著抬升。所谓迁移期限的约束不是硬截止，而是经济意义上的越来越不划算。

双币与僵尸仓位风险

大版本常伴随代币合约更换，旧币按公告比例换新币，期间两套代币并存、两处报价，忘记执行换币的持仓等于持有一枚逐渐失去用处的凭证。更隐蔽的是僵尸仓位：旧市场的债务仍在计息、清算线仍在执行，而盯盘习惯、提醒服务甚至前端页面都已转向新版——你不再看着的那个界面下面，利息照提、清算照跑。历史上多数被动损失不发生在升级本身，而发生在升级之后无人问津的角落。

搬家检查顺序

一，从官方渠道确认升级类型：换地址、换执行层还是换代币，各自对应不同的操作清单。二，列出你在旧合约的全部仓位，逐一对照新市场的参数差异，特别是抵押率与清算阈值的变化，同一仓位在新参数下的清算距离可能完全不同。三，兑换通道迁移选流动性充分的时段执行并设边界。四，代币换新走官方入口核对合约地址。五，全部搬完后确认旧地址仓位清零，撤销旧合约的授权。整个动作的先后无所谓，清零与撤授权这两步不可省略。 本文为机制科普，示例非实时参数，不构成操作建议，升级方案以协议官方公告与文档当前版本为准。