ERC-3569 元数据封存：一次性的 seal 与改不掉的 sealedURI

“这个项目元数据已经锁死了”——听腻了这句话，你可能想知道链上到底有什么能证明。ethereum/ERCs 仓库里状态为 Stagnant 的 ERC-3569（2021 年 5 月创建）把“锁死”做成了一个动作：seal。它做的事情有三层：给一串代币封存一份总目录 URI、让目录里逐枚映射到各自的元数据、把这些代币的状态钉成“不能再封存”。

三个函数讲完全部

seal(tokenIds, uri) 由有权限的人调用，参数是一段一个或连续多个代币编号，加一份指向去中心化存储（标准文本点名 IPFS 这类服务）的 URI；调用成功后 URI 存进合约，代币被标记为已封存。sealedURI 把被封存的 URI 原样还给你，isSealed 查某枚代币封没封，Sealed 事件让索引器能追踪。已封存的代币不能再次封存——这个一次性设计让“换一份目录”从操作上就不可能。目录文件本身是个 JSON，键是代币编号，值是逐枚的元数据原文或下一跳 URI，一次封存就能服务整期发行。

封存证明的是承诺，不是物理事实

把三层含义分开：合约能证明的，是这个地址在某个区块把这段 URI 钉进了状态，且代码规定之后没人能替换它；文件是否真的在 IPFS 上永久可取、内容是否与 URI 里的内容哈希匹配，是存储层的事，得你或工具去取回验证；而 URI 指向的中心服务器域名哪天改了解析、换了内容，seal 无能为力。所以“已封存”三个字真正的价值在于堵住合约内改元数据的常见路径——把 tokenURI 悄悄从 IPFS 指回自家服务器的操作，会与此前的封存状态直接冲突，容易被工具发现。

看到“已封存”后该做的三件事

封存值多少：给“反悔成本”标价

换个角度理解 seal：它不改变元数据本身，改变的是项目方改元数据的成本结构。没有封存机制时，修改 URI 指向是一笔普通交易加一次公告，反对者的反馈周期以天计；封存在合约状态里写下“这些编号的目录 URI 不可再替换”之后，项目方想改口径只剩两条路——部署新合约迁移（把选择权交给持有人），或者在已封存指针指向的子文件层面动手（改动会暴露在与封存哈希比对的探照灯下）。换句话说，封存是一种用密码学预承诺提高反悔成本的工程手段，和财务审计的“审计意见”一样，保证的是程序诚实的底线，不是内容质量的上限。判断一个项目的封存是否到位，看三点：封存的编号覆盖率（漏封新铸批次是最常见的猫腻）、目录与子文件的哈希链条是否至少有一环落在内容寻址存储上、有没有公开的第三方比对工具持续抽查。三点俱全的封存才配得上“承诺”二字，只完成 seal 调用的只能算完成了一半仪式。

没有封存功能时怎么办

现实中多数合约没有 seal，判断“元数据是否会变”需要另一套证据链。先测可读性：间隔数周调用 tokenURI 比对返回字符串，完全一致是弱证据，不一致是强警报。再看权限：翻合约源码或代理实现，查 URI 设置函数的角色门槛——任何地址可改、管理员可改、需治理通过，三种设计对应三种信任等级。最后看快照：社区是否有人把早期元数据存档并公开哈希，有存档的项目改起来顾忌更多。证据拼完，你虽然拿不到“链上不可改”的硬承诺，也能拼出一份“改起来的代价与可见度”的评分表，这已比大多数买家走得更远。

先调 isSealed 与 sealedURI，确认查询的编号确实在封存范围内；再把目录文件从声明的存储网络里实际取一遍，比对内容哈希；最后抽几枚子文件看是链下指针还是完整 JSON，指针再往下有没有中心服务器环节。一份封存的目录加一个随时能改的子 URI，等于把锁装在了第一道门上、最后一道门开着。它说明的是“链上承诺不再变动”，不能替代你对存储耐久性的独立核验。本文只做机制科普，不构成投资建议。