ERC-7946 UWULink：一串二维码把一批链上调用送进钱包，还不暴露地址

链下应用想让钱包执行一组链上操作，主流做法是网页弹窗或深度链接——应用全程知道你是谁，钱包全程在线。冷钱包场景则干脆反过来：人在离线设备上手工拼参数。ERC-7946 提出第三条路：定义一种单向投递协议（Unidirectional Wallet Uplink，UWULink），应用把要执行的调用清单打包成紧凑的二进制消息，通过二维码、NFC 这类单向通道送进钱包，钱包原子执行整批，发起方从头到尾拿不到用户地址。按照以太坊 ercs 仓库的记录，这份提案状态为 Draft，创建于 2025 年 5 月 10 日。

两种模式：清单随件走，或清单在链上

协议支持两种载荷。静态模式（Static Mode）里，消息本体直接装着调用列表——目标地址、调用数据逐项编码，钱包解出来就能执行。编程模式（Programmable Mode）里，消息只带一个合约引用，真正的清单要现场问：钱包调用该合约的标准接口 UWUResolver，用 getCalls(address requester, bytes calldata data) 换取本次要执行的调用数组，getErrorCodeDetails(uint256 errorCode) 则把错误码翻译成人能读的原因。静态模式简单可离线审计；编程模式让应用能按参数动态生成清单，代价是钱包必须联网解析一次，且要信任那个 resolver 合约当场的回答。两种模式共用一套 Protobuf 消息结构，编码小到一个普通二维码装得下，这正是选 Protobuf 而非 JSON 编码调用列表的原因——低带宽通道上，字节数就是可行性。

单向投递的安全含义

协议名里的 uplink（上行链路）点出了核心设计：信息只从应用流向钱包，不存在回程信道。好处之一是隐私——链下发起方永远不知道你用的是哪个地址，适合活动页给不特定用户发起领取这类场景；好处之二是攻击面缩小——没有双向会话就没有会话劫持，钓鱼方能伪造的最多是一张静态二维码。相应的代价也要读明白：单向意味着钱包无法向发起方回传执行结果，回执要么没有、要么走链上查询；同时二维码本身可能被中途替换（拍照重放一张更旧的码），所以清单里带不带过期字段、目标合约是否接受任何提交者，成为安全评估的重心。错误详情函数 getErrorCodeDetails 的存在也提示实现方：拒绝原因必须显式，静默失败等于把风险留给用户猜。

和二维码配对签名类方案的关系

它容易与硬件钱包的二维码 PSBT 类流程联想在一起，思路同族、目标不同：那些方案传的是待签交易本身，UWULink 传的是调用清单，签名的构造仍由钱包在本地完成——钱包先解清单、本地组交易、本地签名，私钥路径不变。对开发者，它更像是把钱包应用商店里各家私有配对的通用连接器：任何支持该协议解析的钱包都能接入任何按协议出码的应用，不必一对一写适配器。

判断落地程度的办法

二维码之外的通道与代价

协议选 Protobuf 的动机值得展开：低带宽不只是二维码一个词，NFC 标签、蓝牙 beacon、甚至纸质凭证上的紧凑编码都算。同一份消息格式跨通道复用，意味着活动方可以按预算自由选投递方式——一场会议可以用 NFC 胸卡做批量签到铸造，一个网页表单用二维码，一个 API 用原始字节流。代价同样具体：二进制格式不可肉眼审计，钓鱼方伪造一张码在观感上和真码没有区别，因此协议安全完全依赖载荷内的语义约束——目标合约的白名单校验、过期字段、可编程模式下 resolver 的诚实性。用户侧的实用推论：扫任何批量执行码之前，先看钱包展示出来的目标合约地址是否与活动官方公告逐字符一致；单向投递的架构下，钱包就是你唯一的守门人，它显示什么，什么就是这次签字的全部依据。

按 ercs 仓库口径该提案为 Draft，尚属早期。评估任何自称支持它的产品，两个具体测试胜过宣传语：拿一张过期的编程模式码，看钱包是否调用 getErrorCodeDetails 给出可读拒绝原因；用支持该协议的钱包扫一张静态码，核对展示出来的调用列表与协议内容是否逐项一致——展示层忠实，是这类协议安全成立的前提。本文为机制说明，不构成任何投资建议。