一份 JSON 说清一个资产在哪几条链：CAIP-390 的元数据字段

元数据散在几家仓库的问题

一个代币的图标、官网、社媒、精度，今天散在好几家名单仓库里，每家的 JSON 结构都不一样；同一资产跨链桥接后，各钱包常把它当两个毫不相干的条目，组合视图很难聚合；链接字段的键名更是各写各的，twitter、social_twitter、x_url 指的可能是一回事。CAIP-390 的方案是一份「最小」的链无关 JSON 模式：字段不求多，够用、可校验、能对齐现有标准。

四个必填与取值纪律

模式的必填字段只有四个：name、symbol、decimals、image。值得展开的是 decimals 与 image。decimals 对不可分割资产（NFT）强制写 0——规范的理由是消除歧义，让钱包分得清「精度为零」和「数据缺失」两种情况。image 是单个 URI 字符串而非多尺寸对象，规范认为缩放和格式协商交给现代 CDN 与前端框架即可，钱包侧解析越简单越好。另有一个对外字段 external_url 而非 website，为的是与 ERC-721 及 OpenSea 元数据的既有习惯兼容。

links 与 locations 两个数组

links 把杂乱的链接收敛成对象数组，每项必须有 name、url 和受控词汇的 rel：homepage、whitepaper、documentation、source_code、governance、audit、social、browser、exchange、bridge 十个取值，数组元素不可重复。exchange 专指交易对直达链接，bridge 专指跨链桥界面，各归各位。locations 则是这份提案的题眼：一个资产用 CAIP-19 标识（见 CAIP-19资产标识如何避免跨链混淆？）列出自己在各链的「分身」合约，例如同一个稳定币把以太坊主网、BNB 链、Solana 上的合约各写成一条。钱包据此聚合余额，不必依赖中心化的桥映射表。

消费方必须自查的三件事

规范在安全考量里把丑话说在前面：格式标准不等于内容可信。第一，external_url 与 links 里的网址是钓鱼入口，钱包在跳转前必须把域名清楚展示给用户；第二，image 若允许 SVG，必须先清洗掉内嵌脚本，防存储型跨站注入；第三，这份 JSON 的来源要核验——它应当出自可信域名或可验证的链上登记合约，而不是随便一个缓存副本。换句话说，locations 帮你把各链分身认全，认的根据仍是这份文件本身的可信度。

和 Token List 的关系

Uniswap 风格的 Token List 是这份模式最直接的近邻：同样是一段代币信息 JSON，但 Token List 面向「一份名单里成百上千个条目」，字段重心在地址与图标；CAIP-390 面向「一个资产一份文档」，重心在 links 语义与 locations 跨链图谱。规范在兼容性一节明确说两者可以互转——一份名单里逐项展开即可得到一组这样的对象。差异提醒我们把「标准」和「名单」分开评价：格式统一解决解析成本，不解决名单本身收录谁、剔除谁。一份 locations 写错的清单（比如把仿冒合约列为分身）会让聚合视图变成投毒向量，所以名单的来源纪律与格式无关，仍需人工维护。

一次完整的核对演练

设想你持有某个多链发行的稳定币，钱包显示你在两条链上各有一笔余额，第三笔显示为未知代币。按这份模式可以走完一轮核对：第一步，找到该资产的官方元数据文档，确认它的 name、symbol、decimals 三个必填值与你已知的官方口径一致——decimals 写错一位，显示的数额就差十倍，这是元数据错误里最伤用户的一类；第二步，读它的 locations 数组，逐项对照区块浏览器上对应链的合约页，确认地址、部署交易与官方桥公告吻合；第三步，检查文档来源域名是不是官方渠道，防止你核对的是一份被仿冒的「同名文档」；第四步，回到钱包确认未知代币被正确归并到同一条资产线，若仍不归并，则是钱包尚不支持该文档或 locations 缺了那条链。整套动作里没有任何一步需要信任文档自称的内容，每一步都链上可验，这正是这类「只定格式、不定真伪」标准在用户侧的正确打开方式。该提案为草案（Draft），创建于 2025 年 12 月 22 日，类别标注为 Interface，消费端支持程度以各钱包现文为准。本文仅作机制说明，提及字段均以其规范文本为准，不构成投资建议。