扫码时钱包怎么一眼认出意图：ERC-831 的 ethereum 前缀与分层负载

收款方页面上一个二维码，钱包扫出来可能是一串以 ethereum: 开头的文本。这串字符里其实藏着“让钱包做什么”的指令，而约定怎么写，最早成形于 ERC-831。这份文档创建于 2018 年 1 月 15 日，仓库记录状态为 Stagnant，属于长期无人推进的归档状态，文件头声明依赖 ERC-67 与 ERC-681。摘要把场景讲得很清楚：嵌在二维码、网页超链接、邮件或聊天消息里的 URI，是松耦合应用之间最稳的互相打招呼方式——扫到的人用什么钱包、什么功能，全看这串字符写得规范不规范。

三段式语法

规范给的构造规则是：协议头写 eth 或者完整拼写 ethereum，然后是可选的前缀加连字符，最后是必选的负载，原文的形式化写法是 request = "eth" [ "ereum" ] ":" [ prefix "-" ] payload。理解这条语法的钥匙是“分层”：这份标准只管容器，负载里面具体装什么、怎么排，由每个用途自己的标准去定义，文档明确说结构化内容不在本文范围内，并且点名 pay- 前缀的负载格式归 ERC-681 管。换句话说，ERC-831 是信封，ERC-681 是信纸，以后出现新用途就再印新信纸，信封规格不用改。

不加前缀默认是收款，以及 0x 的消歧技巧

前缀段可以整个省略。规范的处理是：省略时按 pay- 理解，这是为了对最早那版 URI 标准 ERC-67 保持向后兼容。省前缀时负载必须以 0x 开头（也就是直接跟一个十六进制地址）；反过来，规范规定前缀本身不许以 0x 开始。于是规则闭合成一个机械判断：扫到的字符串里冒号后第一段以 0x 起头，就等于宣告“我没写前缀，走收款逻辑”；不以 0x 起头，那第一串字符就是前缀。原文承认这就是一个“清晰信号”的设计，用词序代替额外字段，钱包解析器不需要查表就能分流。

这套约定还带出一条兼容性警告：规范理由部分写明，只要用到前缀特性，老的 ERC-67 解析器就可能解析失败；作者们没有找到既兼容又创新的鱼和熊掌，选择了保留旧地址直写、新用途走前缀的折中。 ERC-681 一侧的负载是结构化收款请求：目标地址后可选链号、函数名和参数表，不带函数名就是原生币收款、金额用 value 参数以最小单位 wei 表示，带 transfer 就是 ERC-20 代币转账，参数键还可以是任意标准 ABI 类型名；旧格式那条只带 0x 地址的字符串则等价于“付钱给这个地址，金额用户自己填”。两种年代格式并存时，能否正确分流取决于钱包有没有实现 0x 信号规则——这也是为什么同一个二维码在不同钱包里反应可能完全不同。

为什么不用一个 scheme 一个用途

规范选择开放前缀而不是封闭枚举，理由写在 Rationale 一节：2018 年时已经有一批钱包和身份应用注册了 ethereum: 这个 scheme，把整个 scheme 锁死在当时已知的几个用途上，等于给未来所有新场景修了一堵墙，所以改用“前缀开放”让后来的用例可以增量进入。原文同时承认，开放前缀也意味着 scheme 层面无法替用户预审内容——任何一个自称新前缀的应用都能造出语法合法的 URI。安全考虑一节原文只写了一句“目前没有已知的安全考虑”，这不代表扫码零风险：URI 语法合法不等于内容可信，负载里指向的地址、金额、合约函数参数才是真正决定你钱去向的字段。

实操上可以把这份归档标准当成读码词典：ethereum:0x... 直写形式按收款处理；ethereum: 后接非 0x 开头的一段字母，先当它前缀，再找对应用途的标准核对负载结构——比如 ERC-681 自己就声明它取代的是已废弃的 ERC-67 那种低层任意交易写法，专注做收款请求这一个特例；负载内部的结构化程度完全由所引用的那份用途标准决定，扫出来完全不符合这套语法的字符串，更可能是某个应用自造的私有格式。遇到要转账授权的，宁可回到官方页面重新操作——语法能验真，意图不能，这一条是这份 Stagnant 文档留下的最实用提醒。本文为机制说明，不构成任何投资建议。