协议币的交易池不是一版用到老的单体合约。Zora 的架构把池子里的行为逻辑做成可插拔的钩子实现，再配两样配套件：一张登记“哪些钩子可用”的注册表，一条把存量流动性从旧实现搬到新实现的迁移路径。这两样东西分别有官方文档页，合起来构成一个容易被忽略的问题的答案——链上协议升级时，你持仓所在的池子会经历什么。
先解释钩子在池子里管什么。协议币的价格曲线、手续费怎么收、流动性怎么记，这类行为规则并不写死在发行合约里，而是集中在钩子合约实现；发行合约负责资产本身，池子运行时调用钩子来执行这些规则。这个拆分的意义在于版本策略：行为要迭代时，团队发布一个新钩子合约，而不是去改动已经发行过成千上万枚资产的资产合约——资产端的账本不动，行为端换引擎。
注册表页就是这件事的名录。官方文档的 Hook Registry 页按链列出登记表合约地址，表格里的行给出链名、链编号与注册表合约（例如 Base 主网对应条目里挂了区块浏览器可查的合约地址）。它的作用可以按字面理解：链上有一个合约记录哪些钩子实现是被这套协议承认的。对集成开发者的提醒很实际——自己的产品要指向正确的钩子与注册表地址，而这些地址应当从官方文档页获取；对普通用户的含义则更简单：某个池子用的是哪一版实现，是一个可以在链上查证的事实，不是需要相信的声明。
迁移页回答另一半问题。官方文档的 Liquidity Migration 页给出的交互时序图里，核心一步是名为 migrateLiquidity 的函数调用，参数带着新钩子地址和一段附加数据。按这个接口形态读：迁移是把绑在旧钩子上的流动性，改接到指定新钩子的过程，目标版本由参数显式给出，而不是隐式跟随“最新版”。时序图的存在本身也在提示，迁移是一个有先后顺序的多方流程——登记、调用、后续池子对新实现的接管，各步在链上各有事件。至于迁移发生时普通持有人要不要自己做什么，取决于持有的仓位形态与官方当时的迁移安排，文档没有把它写成统一答案，决策前应以对应版本的迁移说明为准。
把这套结构放回更大的图景里：链上协议的“升级”从来只有一个难题——账不能改，行为要变。常见解法有合约代理换实现、新链重新发行、双轨并行引导迁移等，注册表加显式迁移函数属于最后一种的工程化形态。它的优点是每一步都留链上痕迹、目标版本可参数化、失败可以停在旧实现上；代价是需要有人真的去执行迁移，存量池子在过渡期会呈现版本分裂。看到协议币讨论区出现“同一个币在不同池子报价不一致”，先别下结论，查一下两边池子各自挂的钩子版本，往往就是答案的一半。
对只持币不做市的读者，还有一句可以提前说的结论：只要你不主动参与迁移交易，钩子升级通常不需要你签名任何内容，资产余额与转账功能走的是资产合约那条路径。真正会感知到版本变化的是提供流动性的那批地址——他们的仓位记账跟着池子实现走，迁移期间对流动性头寸的任何操作指引，都应该以官方迁移文档当时候写明的步骤为准，而不是社群转述。
合约地址与流程以官方文档当前版本为准。本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。