#termmax @TermMax 如果项目方告诉我“核心合约不可升级”，我不会立刻鼓掌。真出 bug 的时候，不能升级到底是护栏，还是把问题锁死？TermMax 的升级说明给了一个相对清楚的答案：UUPS 只放在 AccessManager 和 TermMaxRouter，核心协议逻辑不在可升级范围内。
我把这段权限范围对着看了几遍，发现它其实是在做取舍。路由和权限系统需要留出修补空间，借贷本身的核心规则则尽量不让管理员随手改。对用户来说，坏处是某个核心逻辑真的出问题，不能指望后台发个升级就解决；对接入方来说，好处是基础设施更新时，借贷规则不会顺手被换掉。
麻烦会出在最急的时候。假设路由合约发现严重漏洞，修复还要经过 4/6 多签，用户可能先面对暂停、等待和重新确认；如果问题恰好落在不可升级的核心逻辑里，团队能做的也许只剩隔离影响，而不是直接替换代码。灵活性和确定性，偏偏会在事故里正面相撞。
所以我看 @TermMax 的升级设计，不会只数“几个签名才能通过”。我更在意每次升级到底碰到了哪一层：是入口和权限，还是用户以为不会变化的核心规则。$TMX 后面要建立的信任，不是承诺永远不出问题，而是让每次可升级范围都能被外部核对。#TermMax
我把这段权限范围对着看了几遍，发现它其实是在做取舍。路由和权限系统需要留出修补空间，借贷本身的核心规则则尽量不让管理员随手改。对用户来说，坏处是某个核心逻辑真的出问题，不能指望后台发个升级就解决；对接入方来说，好处是基础设施更新时，借贷规则不会顺手被换掉。
麻烦会出在最急的时候。假设路由合约发现严重漏洞，修复还要经过 4/6 多签，用户可能先面对暂停、等待和重新确认；如果问题恰好落在不可升级的核心逻辑里，团队能做的也许只剩隔离影响，而不是直接替换代码。灵活性和确定性，偏偏会在事故里正面相撞。
所以我看 @TermMax 的升级设计，不会只数“几个签名才能通过”。我更在意每次升级到底碰到了哪一层：是入口和权限，还是用户以为不会变化的核心规则。$TMX 后面要建立的信任，不是承诺永远不出问题，而是让每次可升级范围都能被外部核对。#TermMax