ERC-6864 代币升级协议：不动旧币，套一层新壳换血

智能合约以不可变为荣，但现实里有三类绕不开的改需求：修漏洞、上新功能、跟着监管改条款。主流答案是代理合约模式，用 delegatecall 把逻辑层做热替换。2023 年 4 月 5 日创建、状态为 Draft 的 ERC-6864 认为代理模式有自己的短板，提出另一条路：旧代币合约一个字都不改，在它外面套一个全新的合约，用户把旧币存进新合约换等量新币，需要时再换回来。本文按原文拆这套金套结构。

升级与降级是一对对称操作

接口 IERC6864 继承 ERC-20，只加三个函数。upgrade 的动作是把某地址的旧代币存进来、给指定接收地址铸造等量的新代币，参考实现里可以看到先 transferFrom 拉旧币进合约、再 _mint 发新币的两步。downgrade 是镜像操作，把新币销毁、旧币退回，原文对权限写得很细：调用者要么本人持有足够新币，要么拿到足够授权，否则必须回退，接收地址为零地址同样回退。baseToken 返回底层旧合约的地址，让任何程序能顺藤摸到被包裹的本体。从结构看，这就是一个专门吃自己的封装合约：旧币被锁在升级合约里，市场上流通的是新壳，旧链上历史完整保留，而新合约可以同时实现标准之外的新接口。

双层账本逼出一个透明度接口

这种套娃设计带来一个真实的盲点：旧币被锁进升级合约后，只看任何一层都会数错总量。旧合约上躺着一大笔已被升级锁定的余额，新合约上是流通中的镜像币，行情网站若只读一层，要么重复计算、要么漏算。ERC-6864 的答案是一个可选接口 IERC6864SeeThrough，三个函数直接把两层账合成一张报表：combinedTotalSupply 返回合并后的总量，combinedBalanceOf 返回某地址跨两层的合计余额，combinedAllowance 合并授权额度。名字里的“看穿”很形象——数据还是那两本账，但标准多给了一扇同时看见两本账的窗。

迁移日的一份动作清单

把这套结构落到用户侧，会得到一份具体清单。升级公告出来，先核三件事：升级合约的 baseToken 是否指向自己持有的那个旧合约；升级合约代码有没有公开验证；官方渠道给出的升级入口地址从哪来——升级需要持有人亲自执行，这个窗口恰恰是仿冒升级站最活跃的时段。执行当天链上动作很清晰：一次授权加一次 upgrade，旧币流入升级合约、新币铸给接收地址，事件 Upgrade 记下双方地址与数量；想退出就反向 downgrade。没赶迁移的人继续持有旧币，旧合约仍然存活，失去的是新合约承载的功能与生态适配。迁移完成后核一遍总账：被锁进升级合约的旧币加上流通中的新币，应与迁移前总量吻合，实现了透视接口的合约还能直接读 combinedTotalSupply 拿合并口径。每一步都可独立验证，不必听信项目方的进度汇报。

Draft 状态的取舍逻辑

按 ercs 仓库记录，这份标准停在 Draft，实际部署罕见。它值得读的原因是设计取舍清晰。代理模式的代价是把逻辑层控制权交给升级者，用户必须信任那个能换代码的地址；ERC-6864 的代价反过来：升级动作要求每个持有人自己执行，流动性被拆到两个合约，谁没动谁就留在旧壳里。一个把风险集中在管理员权限上，一个把摩擦摊派给全体持有人，都没有消灭升级这件事的不信任，只是重新分配它。读者拿到一个新发行代币时值得顺手查一下它属于哪种：有没有 baseToken 指向另一个合约、总量与流通量的口径用的是哪一层。看到升级合约地址，旧币流向可查；看到代理地址，逻辑变更历史可查。两种结构都能体检，最怕的是两头不靠的沉默改造。

本文为机制说明，不构成任何投资建议。