手机钱包连桌面应用，十个里有八九个是先扫一个二维码。二维码里那串 wc: 开头、又长又密的文本，格式其实由一份 2018 年的标准定下：ERC-1328，WalletConnect URI Format。它的官方状态是 Final，早于今天流行的多数钱包连接方案。看懂这串链接，你就能在扫码前判断”对面是谁、通道通向哪、这串码会不会过期”。
语法：一个 topic、一个版本号、一串参数
规范的语法写成一行：wc: 之后是 topic（一段标识本次配对的字符串），可选地用 @ 跟版本号，再用 ? 挂若干参数。协议版本不同，必填参数也不同。v1 协议要求 bridge（中继服务器地址）和 key（加密用的对称密钥）；v2 协议换成 symKey（对称密钥）、methods（这条配对通道支持的请求方法列表）、relay-protocol（中继传输协议），可选 relay-data 与 expiryTimestamp（过期时间的秒级时间戳）。也就是说，同样一个二维码，肉眼分不出优劣，但字段可以逐项核对：中继地址是不是官方域名、methods 里列了哪些方法、有没有写过期时间。
为什么用 URI 而不是 JSON
规范在理由部分写得很直接：早期方案把 JSON 塞进二维码，钱包解析效率差；改用 URI 后，安卓的 Intent 系统可以直接识别并拉起对应钱包应用。这也解释了另一层设计意图：对称密钥字段让手机与桌面两端端到端加密，中继服务器只搬运密文、看不到内容——这是规范写下的设计目标，“通道通向哪台服务器”则由 bridge 或 relay-protocol 字段明说。这解释了为什么今天扫码时手机能一步跳到钱包 App——那个跳转能力就是 URI 格式的副产品。也正因为它是普通链接，同样的文本可以被做成网页按钮（deep link），扫码只是投递方式之一。顺带一提，这份格式标准诞生于 2018 年：规范文本里 v1 与 v2 两段参数并列，说明它承担了向后兼容的角色——同一套语法要装下两代协议。扫到 @1 结尾的老链接要多留一分警惕：v1 依赖的公共桥服务与今天的配对体系不是一回事，能扫出反应的码往往来自还在跑旧组件的页面，风险面比新协议更大。
桌面端那一步：确认弹窗才是权限起点
URI 建立的是”通道”，真正决定安全水位的是通道建立后的第一声弹窗：桌面应用发起的会话请求会推到手机上，写明了请求方域名与要的方法。这一步与直接装浏览器扩展连接钱包的体验不同——多了一跳中继，也多了一层”通道挂了多久没人管”的问题。配对完成后会话默认长期有效，桌面端关掉页面不等于断开连接，长期不用的会话要回钱包里主动清理。三篇姊妹话题各管一段：会话里权限怎么读见WalletConnect会话权限怎么读？，弹窗长什么样该警惕什么见WalletConnect弹窗怎么辨别？，用完怎么关见WalletConnect会话怎么关？。URI 格式本身不管这些，它只管”怎么建立通道”。
扫码前的三条实操纪律
第一，只从你自己打开的官网页面上扫码，陌生人发来的二维码——哪怕是”客服""空投验证”名义——一律不扫，因为 bridge/relay-protocol 指向哪里由生成方决定。第二，看到 expiryTimestamp 已过期的码不要试图”再试一次”，那通常意味着页面被挂着旧会话或被截了图。第三，冷钱包与硬件钱包用滚动二维码分帧传数据时，核对的是设备屏幕上重建出的完整内容，方法见硬件钱包为什么要滚动二维码：分帧扫码传数据的机制。最后，这串 URI 里没有任何”授权”效力：它只建立通道，转账与否永远由你在设备端的确认决定。本文为工具科普，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。