把链 ID 写进交易号：ERC-7950 让交易引用自带网络前缀

你从一个跨链桥的通知里复制交易哈希去浏览器查，页面显示“无此交易”——原因很朴素：哈希没问题，你贴错了链。EVM 生态链众多，交易哈希都是十六进制串，字符串本身不带网络身份信息。ERC-7950 用交易哈希编码链 ID（Encode chain id with transaction hash）提出一个很小的解决法：引用交易时写成三段。标准状态为 Final，创建于 2025 年 5 月 22 日，建立在 EIP-155 及其链 ID 登记体系之上。

格式与语义

规定是：合规引用由链 ID、交易哈希、类型标识 tx 三段拼接。链 ID 取 EIP-155 及其引用列表登记的值；交易哈希必须带 0x 前缀；tx 作后缀防止与其他十六进制串混淆。整串字符不分大小写。文档给了示例：链 ID 为 1 的某笔哈希以 0xc55e 开头的交易，其引用写成一串以 1:0x 开头、以 :tx 结尾的形式——工具读到它，即可无歧义地路由到对应链的浏览器、RPC 或钱包确认界面。

理由部分说得很工程化：链 ID 放第一段，是因为路由器解析时第一个要决定的就是“去哪查”；tx 后缀解决“这串到底是地址、哈希还是别的”的类型歧义——没有它，一段裸哈希可能被误当地址解析。整套方案没有任何链上动作，纯粹是跨工具交换引用时的字符串约定，部署成本近零，收益在每一次复制粘贴。

它与相邻标准的关系

同一需求领域已有两件工具。EIP-3091 用 URN 风格标识区块链资源，适合做 URI 参数；CAIP 系列用 namespace:reference:transactionId 描述多链对象，面向更广义的资产与身份、命名空间注册更重。ERC-7950 的差异化在“轻”：不引入 scheme 注册、不要求命名空间治理，只规定“复制交易号时带上链 ID”一个习惯，钱包、浏览器、工单系统、通知脚本都付得起解析成本，最适合出现在铸造回执、客服工单与桥进度页这类低带宽场合。

给从业者的三条用法

第一，写任何含交易号的产品文案（NFT 铸造回执、客服工单、桥进度页）时，优先输出带链前缀的引用，或至少在哈希旁标注链名——一个字段能省下一半“我查不到”的咨询。第二，作为用户收到交易引用先问三件事：带不带链前缀、目标浏览器是否自动切换网络、若只是裸哈希，自己手动选网络了吗？第三，处理自动巡检与脚本时，按三段拆解引用、用中段带 0x 的哈希去对应链 ID 的 RPC 查询——把“查错链也返回未找到”的误报与“错链存在同形哈希”的更危险误判一并消除。

需要说清的局限：编码规范不校验哈希真伪与内容完整性，一段格式正确但内容伪造的引用照样能通过正则解析，路由器不会替你判断“这笔交易是否真的存在”；链 ID 写错也只会把查询带到错的链上显示未找到，不会警告冲突。所以“带链前缀”只是减少人手滑，不替代对交易本身的核对。另外，链 ID 的权威来源是 EIP-155 引用的登记仓库，私有链、测试网自定 ID 若未登记，解析工具只能原样透传，跨工具行为可能不一致。

落地示例场景：一个 NFT 空投页展示 50 笔发放记录、涉及 3 条链，未用带前缀格式时用户高频踩“点进去找不到”的坑；改用三段式后，客服工单里的哈希天然自带网络上下文，自动化审计脚本也免去人工标注。小事，但属于低成本高回报的接口卫生。

解析建议从右锚定：先确认尾部类型段再剥离，头部按第一个冒号切出链 ID，中段整体当哈希原样透传——不要“优化”掉 0x 前缀或改写哈希大小写，规范只承诺整串字符不区分大小写，其余内容必须逐字保留、逐字比对。 最后提醒：本文讲引用格式规范，不构成投资建议；以交易哈希核实资产状态时，请同时确认网络选择与合约来源。