“在几条链上收多少钱”写成链接：ERC-7856 链上收款请求 URI

商家贴一张收款码，用户扫出来只知道一串地址，不知道收款方要的是哪条链上的哪种币；收款人换个钱包收款，还得分链接发好几遍。ERC-7856（Chain-Specific Payment Requests）把”在 Z 链上给我转 X 个 Y 币”这句话编码进一个标准链接。按 ercs 仓库记录，该提案状态为 Draft，创建于 2025 年 1 月 1 日。

URI 的字段构成

请求格式是 cspr:// 前缀加路径段加查询参数。recipient 是必填项，用 CAIP-10 账户标识书写——这种写法本身就把链标识和地址捆在一起，例如以太坊主网写成 eip155:1 前缀加地址，比特币主网写成 bip122 前缀加创世块哈希与地址，链选错在语法层就会暴露。amount 是必填的整数或小数金额。token-address 也是必填，写 ERC-20 合约地址并以 base64 编码表示，特殊值 native 表示索取该链的原生币——请求以太坊原生币和请求 100 枚 USDC 在链接里写法不同。查询参数 on-success 与 on-error 都是可选的回调 URL：交易确认后跳转去哪个页面、失败后回落到哪个页面，供商户把收款流程接回自己的网站。

标准同时要求解析端做校验：钱包或应用解析这类链接时必须验证 recipient 格式，任何字段不合规格就向用户报错，而不是猜测性修复。

提案自己承认的边界

这份规范的 Rationale 与 Limitations 部分坦率得少见。它明确写道：URI 本身没有任何方式保证回调发生时交易真的在指定链上成功了，也没有保证发起交易、收款、交付与退款这几个环节被可靠地连接起来——换句话说，on-success 跳转是一个商户侧的便利信号，不是结算凭证。金额段同样存在表述模糊：小数写的是人类可读值还是代币最小单位，需要解析端按链上小数位换算，这一步出错就是数量级事故。

这决定了这类链接的正确定位：它是把交易意图从人脑搬进机器可读格式的”订单表”，可靠性上限取决于读它的钱包有多诚实多仔细。

对 NFT 卖家与买家的用法

生成合规 URL 与把它接进系统的步骤

如果你是给商店或收款页写集成的人，落地分四步。第一步生成：按 CAIP-10 写 recipient 时直接采用链官方给定的命名空间与参考串——以太坊系用 eip155 加链号，比特币用 bip122 加创世块哈希——不要自造链名，链名错了整条链接就失去语法防线的意义。第二步编码：ERC-20 合约地址段按标准做 base64 表示，金额写明是面值小数，两种写法混用是数量级事故的来源。第三步回调：on-success 与 on-error 域名固定在自家域内并校验入参，回调页只作展示入口，成交判定始终以区块浏览器或自家节点查询为准，提案对回调不保证结算这一点写得直白，工程上就要照办。第四步测试：为每种币各生成示例链接跑一遍钱包解析，覆盖原生币的 native 写法、错误链前缀的报错路径、金额小数位的换算一致性。四步各有一类经典事故对应，测试清单按事故类型排，比按功能模块排更容易暴露问题。

如果你是卖家，一条 cspr:// 链接能在私聊、社群、网页里同时兼容多条链和多币种收款诉求，且语法自带链标识，比手写”USDT-TRC20 或 ERC20 都行”的模糊话术歧义小得多；但结算确认仍然要回到区块浏览器看交易本身，不能拿跳转页面当到账依据。如果你是买家，看到 cspr 链接先读三样东西：CAIP-10 前缀对不对、金额与小数位对不对、token 地址是不是你认识的合约——三段信息都是明文，核对成本很低。提案的示例本身就展示了理想用法：请求某条 L2 上的原生币、请求比特币主网上的若干 BTC、请求以太坊上的 USDC，各自链接互不含糊。本文为机制说明，不构成任何投资建议。