ERC-20 也能带说明书：ERC-7729 metadata 函数与它的 JSON 约定

NFT 世界早就习惯了一个概念叫元数据：tokenURI 指向一份 JSON，说清楚这枚藏品是什么。有趣的是，使用最广的 ERC-20 反而没有对等的位置——它只有 name、symbol、decimals 三个字段，想多说一句“我是哪类资产、有什么特性”就只能自创函数。ERC-7729（Token with Metadata）把这个缺口堵上：给 ERC-20 加一个 metadata() 函数，返回一段按约定 schema 组织的 JSON 字符串。按 ercs 仓库记录，提案状态为 Draft（草稿），创建于 2023 年 6 月 24 日。

一个函数，一段 JSON

接口本身几乎是玩笑级的简单：IERC7729 继承 IERC20，加上 function metadata() external view returns (string memory)，实现方在合约里返回一段 JSON 文本。规范同时给出一份 JSON schema，约定对象的组织方式，让解析程序至少有个共同的骨架可循。与 tokenURI 最显眼的区别在“内容住在哪里”：常见的 NFT tokenURI 指向 IPFS 或某台服务器，链上只存一个地址；而 ERC-7729 的 metadata() 把内容本体放进了合约返回值里，读取不依赖外部站点，也无需担心链接腐烂。

代价写在 gas 里

天下没有免费的存储。字符串存在合约里意味着铸造与部署都要为字节付 gas，合约状态永久占据全网节点；修改元数据只能靠可升级合约或销毁重建。所以这份标准的合理适用面，是体量小、变化少、但要求“随链永生”的描述——例如协议代币的官方属性声明。反过来，内容频繁更新或体积偏大的场景，链上 JSON 会迅速变成一笔谁也删不掉的开支。读实现时可以用 metadata() 的返回字节数估一估这份“奢侈”的成本结构。

对工具开发者的一致性红利

对钱包与分析平台，统一入口的价值是可枚举的：过去要为每个代币适配自创的 getVersion、getPolicy、assetInfo 之类的函数，现在先试 metadata()，解析 schema 骨架，剩余差异退化成 JSON 字段层面的差异——比函数名层面的混沌友好得多。这也解释了为什么标准选择“只统一容器、不穷举字段”：字段列表永远列不完，容器先统一，生态才会开始积累通用解析器。

与相近标准的分工

放到元数据大家族里看清位置：ERC-721 的 tokenURI 管单枚藏品的外部说明书；ERC-4906 一类标准管“说明书更新了”的通知事件；ERC-4626 的“元数据”是另一种动物——它的 asset、totalAssets 是资金池的实时读数，属于计算出来的状态，不是声明式的描述。ERC-7729 站在声明式这一侧，内容静态、随合约而生。读到“代币元数据”四个字，先分清对方说的是指针还是本体、是状态读数还是文字声明。

阅读链上 JSON 的现实姿势

静态字段的两种命运

metadata() 返回的 JSON 存在合约里，这份存在有两种走向。合约若不可升级，这段文本就随合约永久生效——写错的字段无法修改，只能靠部署新版本合约迁移，旧地址的 JSON 永远挂在那里。合约若是代理结构，字段可以随实现替换而变，但改动合法性取决于升级权限的归属与流程。所以对接一个宣称支持 ERC-7729 的代币时，顺手在浏览器里查一次它的实现变更记录：代理指向新实现的那几笔交易由谁发起、有没有公告对应，比 JSON 本身的措辞更能说明“这份说明书由谁负责”。链上 JSON 免于外链腐烂是优点，不可篡改与可升级之间的张力，则要靠实现方自己交代清楚。

字段之外的读取成本

还有一处细节值得写进解析器容错：metadata() 返回的是无约束字符串，合法 JSON 只是规范要求而非链上强制——遇到返回空串、非法 JSON 或超长内容的实现都是可能的，工具应当回退到 name 与 symbol 的基础展示，而不是让整个资产页面崩溃。

截至 ercs 仓库记录，这份提案仍是草稿，实现者不多，因此现实里遇到自称“支持代币元数据”的合约时，检查路径是：先用 ERC-165 探测或直接调用 metadata()；拿到 JSON 后对照规范 schema 检查顶层结构；确认 JSON 里出现的链接字段只是引用，程序不该在解析阶段自动请求。链上内容不该触发自动网络访问，这条习惯在钓鱼频发的钱包前端环境里，比标准本身更值得写进团队规范。本文为机制说明，不构成任何投资建议。