ERC-6734 二层代币清单：一份 JSON 怎么让多条链认同一枚跨链代币

同一枚资产跨到二层之后往往会拿到一个全新的合约地址：主网上的代币合约是一个地址，Arbitrum 上镜像出来的是另一个地址，Optimism 上又是一个。钱包要在三条链上把”三件马甲”识别成同一件资产，靠人工抄地址表显然不现实。ERC-6734 给出的答案是数据层的：定义一种 JSON 代币清单文档，让两条或多条 Layer 1、Layer 2、侧链之间可以机器化地互认”这些地址是同一条资产”。按照以太坊 ercs 仓库的记录，这份提案状态为 Review，创建于 2023 年 3 月 20 日。

清单的骨架：tokenList 与必备字段

标准文档描述的对象是一份 JSON 清单，其中的条目沿用 Uniswap 代币清单生态的常见字段——链标识、合约地址、symbol、decimals 等——并加上了跨链必需的扩展。文档点名的必备元素包括 chainId：它必须满足 EIP-155 对链标识的要求，也就是能支撑该网络的交易重放保护，标准还注明 chainId 的全局唯一性本身不在本文档管辖范围内。当条目使用扩展数据（extensions）时，schema 规定扩展内的元素必须完整出现，不允许只写一半。这套设计的直接来源是现实混乱：Arbitrum 维护了自己的定制清单，Optimism 也维护了一份字段不同的清单，两家都把”canonical（正统）“判定押在桥的扩展信息和 name 加 symbol 的组合上，而现实中同一枚代币能走的桥远不止官方那一座，清单和桥的绑定关系被认为应当拆开。

humanReadableTokenSymbol：把人看的名字拼出机器可解析的结构

标准里一个别出心裁的规定是 humanReadableTokenSymbol 的构造规则：它必须由代币 symbol 在前、chainId 在后，用连字符拼接而成。于是同一个资产在不同链上的展示符号形如 USDC-1 与 USDC-42161，人眼一眼能分开，程序也可以按连字符切开、还原出原始 symbol 和链号再做校验。标准的可测试性一节专门写了这条：解析结果应当与 schema 里使用的 tokenSymbol 和 chainId 逐项对得上。这个”把链信息编进显示名”的做法，针对的正是同名不同链代币在聚合器、行情页和转账界面上互相张冠李戴的高频事故。

清单之外还有谁在读它

这份 JSON 的消费者比想象中广。除钱包外，桥的前端用它确认”你在这条链存的币对应源链哪个合约”，风控脚本用 humanReadableTokenSymbol 批量拦截跨链同名混淆，行情索引器用它把三条链的同一资产并成一条 K 线。对普通用户，最直接的用法是把清单当作可版本化的证据：桥或钱包给出的跨链映射，若能指回一份带 commit 记录的 ERC-6734 格式清单文件，核验路径就完整了；只能指回”我们内部配置”的映射，等于要求你信任一个不公开的账本。

它和”钱包里手动添加代币”的区别

手动添加代币只是让钱包认识某个地址，添加错了钱包照样显示错了。ERC-6734 是一份可以被任何软件共同消费的映射文档：浏览器插件、桥的前端、审计脚本、行情索引器可以加载同一份清单，得到同一组”多链身份对照表”。校验一份清单的可信度，可操作的检查点是：条目里的合约地址能否在对应链的区块浏览器上读到官方桥的铸造记录；extensions 里声明的 bridge 与你在桥官方文档里看到的合约是否一致；humanReadableTokenSymbol 是否能按规则拆回 symbol 与 chainId。三项都过，映射才有证据链，缺一项就退回人工核验。

清单是地图，不是公证处

最后要说清这份标准的性质边界：ERC-6734 统一的是”清单怎么写”，不是”清单里写的一定对”。谁来发布清单、清单多久更新一次、跨链映射出错时谁负责，标准都交给生态解决。因此把清单当成防伪结论是误用，它更像一张格式统一、可以交叉核对的地图——地图画错了，路标（区块浏览器上的合约与铸造事件）仍然是最终的。按 ercs 仓库口径，该标准处于 Review 阶段，尚未定稿，采用它的钱包与索引器数量有限，遇到未收录的链上资产仍应回到逐条地址核验。本文为机制说明，不构成任何投资建议。