一份被放弃的交易网址：ERC-67 为什么让位给 ERC-681

把一笔链上操作变成一条可以复制粘贴的链接，这个需求在 2016 年就被认真写过一次。ERC-67 创建于 2016 年 2 月 17 日，仓库当前状态是 Withdrawn，元数据里的撤回原因只有一行：被 ERC-681 取代。这份文件很短，但它对“一条网址应该装下哪些字段”的枚举，几乎预演了后来支付链接标准的全部内容，值得对照着读一遍。

一条网址里装什么

原文把目标定义为：用一个统一格式把地址、金额、字节码与元数据编码进去，让链接既能指向一次支付，也能指向一次合约调用，钱包读到它之后知道该替用户做什么。它给出的方案围绕一个自定义的 uriScheme 展开：方案名之后依次可以出现目标地址、要调用的函数、参数列表、随交易附带的金额，以及一个用来消除歧义的链标识。文档特别处理了链标识问题——同一条链上可能有多个合约叫同一个名字，甚至同一个地址在不同网络指向不同的东西，链接里不带网络信息就会出事。这一点后来在 ERC-681 里演化成了带链名的参数写法，属于少数被后继标准完整继承的洞见。

文件同时也写明了它的脆弱面：链接不携带执行时间与价格，钱包只能原样填充交易而不做任何判断，用户看到的参数必须自己逐项核对，签名之前不确认就没有第二道防线。这段自述在今天的钱包钓鱼场景下依然一字不差地成立。

为什么被 ERC-681 取代

ERC-67 停在概念与语法草图阶段，而 ERC-681 给出的是可实现的语法：一个 pay 前缀的可支付函数调用写法、以 at 分隔的地址与合约、带单位的金额后缀、明确的参数转义规则。工程层面的这些规定——哪些字符要转义、参数怎么分隔、默认函数省略时按什么处理——决定了一个格式能否被不同钱包无歧义地互操作。语法粗糙这一点加上缺乏真实场景推动，使 ERC-67 在标准流程里被主动撤回而不是慢慢腐烂，仓库里那行 withdrawal 说明就是这场交接的记录。读标准沿革时这是个值得记住的模式：被取代的早期提案会在元数据里留下指向后继的指针，顺着指针读能看清一个功能是怎么从创意变成协议的。

今天的支付链接长回了什么样子

把这条 2016 年的线与现在对照，会发现需求换了三种活法。第一种是钱包与行情站里的 EIP-681 式请求链接，直接用于发起转账与授权；第二种是二维码生态，扫描时由钱包按前缀识别意图并展示摘要，对应 ERC-831 对前缀与分层负载的设计；第三种是面向商户的收款请求，把链、币种、金额、有效期结构化。三种的共同祖先都是那份老文件的设想：让链接携带意图，让人在签名前有东西可核对。反过来说，那份文件警告的风险也全部保留：链接由别人生成，参数由别人填写，钱包只负责忠实地把链接翻译成一笔待签名的交易，这一层永远不承担审核责任。

用户侧的结论因此非常具体：看到任何自动填入参数、或从聊天里粘贴的链接触发的交易确认页时，把这条确认页当成一份别人填好的单据，逐项核对目标地址的尾段、函数名与金额单位这三样，再决定签不签。链接能不能分享与能不能信任，是两个永远分开的属性。本文为机制说明，不构成任何投资建议

把链接当合同读的三个字段

把 ERC-67 的设想落到日常操作，核对一条支付链接只需要看三处。第一处是目标地址：完整字符串逐段比对，前几位后几位都看，因为钓鱼地址通常改的是中段以躲开粗心的尾段核对。第二处是函数名与它的参数语义：同样是向同一个合约发起调用，transfer、approve 与 setApprovalForAll 的后果天差地别，链接格式不会替你标注这个区别，只有确认页上的函数名会。第三处是金额与单位：链接文本里的金额默认按最小单位解释，误读一位小数就是数量级事故。三处都对上，链接才从“别人填好的单据”降级成“我确认过的指令”。这份 2016 年的文件没能教会市场的事，就由这些年反复发生的事故来教。

本文为机制说明，不构成任何投资建议。