Cardano 上的原生代币在链上只带一串不透明的标识符——由资产名称与铸造策略哈希出来的 policy ID 与 asset name，光看这串十六进制，钱包根本不知道它叫什么、几位小数、图标在哪。CIP-26（Cardano Off-Chain Metadata，状态 Active，2021 年提出）解决的正是这个“链上编号、链下含义”的对接问题：它定义了一套把链上标识映射到人类可读元数据的规范，并配套一个由 Cardano 基金会维护的注册表仓库 cardano-token-registry。
CIP-26 的元数据由一个“元数据主体”加若干“属性”构成。主体通常是那串链上标识的哈希，属性则是从“属性名”到“属性值、序号、签名”的映射。规范对三件事下了硬性规定：第一，凡是需要哈希的地方，一律用 Blake2b-256 算法，并且是对字符串按其编码后的字节做哈希；第二，主体、属性名、属性值都必须以 UTF-8 字符串表示，且属性值必须能解析为合法 JSON；第三，每个属性都带一个递增的“序号”，配合作者签名，用来表达“这条描述是第几版、是否被作者本人确认”。这套设计让钱包在展示一枚代币时，可以去查注册表拿到 name、description、ticker、logo、decimals 等字段，同时能通过序号与签名判断拿到的描述是不是最新、可不可信。
注册表的工作方式是提交一个 PR：资产持有者按规范为某个 policy ID 提供签名过的元数据，合并后由一个托管的元数据服务把它以键值存储的形式对外暴露，钱包和 dApp 通过一个 RESTful API 按标识符查询。规范特意强调，它只覆盖“元数据如何组织、如何签名、如何寻址”这一层，具体谁来建服务端、钱包怎么调用，都留作实现自由；它还假设存在一个用户界面或 API 供提交内容。换句话说，CIP-26 是数据格式与登记流程的约定，不是一个强制的全链上账本——元数据仍然“住在链下”，链上只有那串标识。
这带来两个必须点破的边界。其一是信任落点：链上只保证“某资产 ID 存在”，不保证注册表里那条“它叫 XYZ、供应多少”的描述为真；描述的真伪靠作者的签名与序号链条来背书，读者要确认签名指向的密钥确实代表资产方。其二是收录范围：这个主网注册表主要面向原生代币，测试网资产走另一套登记；平台“收录了某资产”也只意味着有人提交了合规的签名元数据，不等于平台做了尽职审查。把 CIP-26 查到的字段当成“链上事实”而非“经签名的链下声明”，是对它最常见的误读。理解了这一点，就不会把“钱包能显示代币名”和“代币发行方承诺了什么”混为一谈。
从产品角度再补一层：钱包端对 CIP-26 元数据的消费方式决定了用户看到的“官方感”。钱包按标识符哈希查询注册表，拿到的是带签名与序号的属性集；同一资产在注册表里可能存着多版本描述，序号高的那条是最新声明，但钱包是否展示版本历史、是否提示“该资产无注册元数据”，完全是各家实现选择。无注册的资产照样能转账、能在浏览器里验证存在，只是界面会退化成一串裸哈希——这时任何人在场外喊“这是某某币”，都请回到注册表查询页复核签名主体。对发行方，注册流程意味着一次公开承诺：提交签名元数据后，改名、改图标都要走新一轮签名与序号递增，历史版本可被追溯，这比以太坊上改一句合约字符串更“留痕”。两侧合起来，CIP-26 给生态建立的其实是一条“可审计的描述变更史”，钱包负责呈现它，用户负责读取它；把这条链条想完整，就不会在“显示名不一致”时误判资产真伪——多数不一致是元数据版本问题，不是链上资产被替换。
本文为机制说明，不构成任何投资建议，也不构成对任何平台、合约或标准实现的背书。文中功能与规则描述以对应版本的官方文档为准，阅读时可能存在版本滞后。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。