上线运维：权限、升级与常见误解
本节要回答的问题
- 哪些能力对象 应纳入 多签 / 托管 / 冷热分离？
- 包升级 时 代币类型与
Currency可能受何影响？ - 社区所说的 「CoinLock」 在 当前 Framework 里指什么？
权限对象与事故面
| 对象 | 若泄露或误用 |
|---|---|
TreasuryCap<T> | 增发 / 销毁供应（视状态是否仍允许） |
MetadataCap<T> | 篡改展示信息（钓鱼风险） |
DenyCapV2<T> | 黑名单写入 |
TokenPolicyCap<T> | 修改闭环规则（allow、Rule 表） |
建议：生产环境 至少 将 TreasuryCap 与 DenyCap 分属不同多签；文案权限（MetadataCap）单独一组。
升级与迁移
代币 类型 T 由 包 ID + 模块 + 结构名 确定；包升级 后 类型标识 可能变化（新包地址），旧币与新币 不是同一类型。Currency 迁移、DenyCap → DenyCapV2、旧 CoinMetadata 合并 等路径在 coin_registry 中有专门函数——必须以目标网络文档与审计结论为准，本书不替代迁移清单。
「CoinLock」与锁仓
在本书成文时所依据的 sui-framework 依赖中 没有 名为 CoinLock 的 通用标准类型。若你在其他资料中见到该词，可能指：
- 其他链或旧版文档；
- 业务合约自定义的「锁仓对象」（共享对象 +
Balance+Clock）； - 质押（staking） 等系统模块的俗称。
若需线性释放或时间锁：在应用层用 显式模块 实现，并对 TreasuryCap 接触面 做威胁建模。
DenyList 与运营文案
再次强调：名单变更可能按 epoch 生效（见 §15.8）。对外公告应包含 「生效时间」，避免法律与舆情风险。
小结
安全发币 = 类型与策略设计 + 权限治理 + 迁移计划 + 用户可见口径。完成本章后，可继续 第十六章 · NFT 或 第十七章 · 客户端。