ERC-1328：WalletConnect 二维码里那串字符装了哪些字段

在桌面网页上连钱包，多数人会看到一枚二维码，手机扫完，钱包就“认识”了这个网站。这枚二维码里其实藏着一行以 wc: 开头的文本，而给它定格式的，是一份编号 ERC-1328 的提案。按 ercs 仓库的记录，这份标准创建于 2018 年 8 月 15 日，现在的状态是 Final，也就是已经走完规范化流程，属于 WalletConnect 生态里少见的定稿文件。本文按原文拆解这行字符的结构，以及扫码之前普通用户值得留意的几件事。

字符串的骨架：主题、版本、参数

标准用一套类似语法的规则定义了请求串：wc 加冒号，后面是主题 topic，可以跟一个 @ 加版本号，再可以跟一个问号加一串用 & 连接的键值参数。主题是一段任意字符串，实际部署里通常是随机标识，用来让应用和钱包在信道上互相找到对方。版本号为什么必须写进语法？标准的向后兼容部分说得很直白：这是为了让 WalletConnect 协议以后演进时能兼容旧格式，新旧客户端看一眼 @ 后面的数字就知道该用哪套规矩对话。

v1 和 v2 各自要求哪些参数

标准的语义部分把必填参数交给协议版本决定。版本为 1 时要有两个参数：key 是用于加密消息的对称密钥，bridge 是中转消息的桥接服务器地址。版本为 2 时参数换了一组：symKey 仍是会话加密对称密钥，methods 声明这个配对主题支持的 JSON-RPC 方法清单，relay-protocol 指明中继传输协议，另有可选的 relay-data 和 expiryTimestamp，后者是一个秒级时间戳，表示配对什么时候过期。值得留意的是标准的安全考虑一节：URI 本身不应包含任何能危及通信或控制私钥的敏感数据。换句话说，串里那把对称密钥只服务于会话消息的加密，和你的资产私钥完全是两层东西——它被看到不等于资产被控制，但会话的另一端是谁，取决于这枚二维码来自哪里。

为什么是 URI 而不是一包 JSON

标准的动机部分留了一段历史：协议 alpha 阶段的二维码里放的是一包 JSON，解析二维码意图的效率很差，于是改成 URI 格式，一是让钱包侧的解析器更好写，二是可以直接借用 Android 的 Intent 系统把链接分发给正确的应用。这个取舍解释了为什么今天扫到的不是一堆花括号，而是一行紧凑的键值串。

普通用户扫码前看什么

把这层机制翻回日常，能推出几条具体的自查。第一，二维码只建立会话、不直接动资产，扫码之后钱包弹出的每一笔签名请求才是真正要逐字读的东西，别把“连上了”误当成“一切安全”。第二，参数里的 bridge 或 relay-protocol 提醒一个事实：两边的消息经由公开中继转发，会话内容靠对称密钥加密，但从搜索结果、群聊截图或直播间里扫到的码，和自己在官方页面打开的码，面对的是完全不同的对面。第三，v2 的 expiryTimestamp 说明配对本就设计为会过期，长期挂在钱包里的旧会话值得定期清理。标准本身只管格式，不管对面是谁，身份核验永远是扫码的人自己那一步。

把 URI 拆开读的一次练习

拿 v2 的示例串做一次逐段阅读：wc: 声明协议，冒号后那串十六进制字符是配对主题，@2 说明走第二版协议，问号后的 relay-protocol=irn 指定中继协议，symKey 后面是会话对称密钥，methods 列出这次配对允许的请求方法清单，可选的 expiryTimestamp 给出配对失效的秒级时间戳。做一次这样的拆解，你对扫码连接这件事的理解就从魔法回到了数据：消息经哪个中继转发、会话到什么时候结束、能发起哪几类请求，全部明文可循。钱包厂商把这一切渲染成一个连接按钮，等于把复杂度藏进按钮背后；会拆这行串的人，更清楚弹出签名请求时该盯哪几个字段，也更理解为什么钓鱼站热衷于诱导用户扫一张来源不明的码——那枚码能改变的是会话的对端，而会话对端决定了后续每一条待签请求从哪里来。标准只负责这行串的写法，具体钱包与协议实现的版本演进、中继网络拓扑，都要以 WalletConnect 官方文档为准，提案文本是地基不是产品说明书。

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