ERC-5131 用 ENS 关联钱包：主钱包不露面，签名钱包来证明

热钱包裸奔的风险人人都懂：日常签名的高频私钥，和存着全部身家的冷钱包若用同一把钥匙，钓鱼站钓到的就不只是隐私。钥匙分开放之后，新的麻烦来了——主钱包怎么向一个应用证明“现在正在签名的这个轻钱包是我授权的”？2022 年 6 月 3 日创建的 ERC-5131 给出的答案很轻：不用任何新链上设施，就用 ENS 的文本记录做双向背书。这份名叫 SAFE 的提案现在状态是 Stagnant，本文按原文拆它的四两拨千斤。

用域名记录代替链上合约

抽象部分把机制说成一句话：通过 ERC-137 定义的 ENS 规范，把一个或多个签名钱包与主钱包链接起来，以证明对主钱包的控制与资产所有权。设计哲学是复用而非新建——不发明新合约、不加新交易类型，只在两个钱包各自持有的 ENS 域名上写记录。方向是双向的：主钱包的域名记录里写着哪些地址被授权代理签名，签名钱包的域名记录里回写着它归属哪个主钱包，任何验证方都能沿着两条记录互相对账。实现侧用到的 ENS 查询就是标准的解析器、地址与文本记录函数，原文示例代码里的 text 查询正是绑定的载体。

验证函数查什么

提案给出两个验证入口：validateSender 与 validate。前者的任务是确认某个签名者的地址在其声明的 ENS 域名下留有记录，且该域名的文本记录回指到被代理的主钱包；后者针对具体消息，检查签名有效、签名钱包的 ENS 记录指向目标主钱包、主钱包的授权记录列出了这个签名钱包。参考实现内部的对账函数处理地址与域名之间的格式转换。整个验证链读下来就是三段：签名有效，子认父，父认子。任何一段断裂，验证返回假。妙处在于全部信息都是公开可读的 ENS 状态，验证方不需要维护任何私下一致名单，主钱包更换授权也只需改域名记录，一次链上写入即可全局生效。

记录更新的时点就是授权的时点

用 ENS 文本记录当授权载体，好处集中在一点：授权状态的改变只需要主钱包完成一次域名写入。撤销某个签名钱包的代理资格，删掉那行文本记录，之后所有验证方顺着记录读到的都是新结果，不需要通知任何白名单维护方，也不需要等任何缓存过期；反向的坑也在这——两个方向的记录必须同时维护，主钱包列了子钱包而子钱包没声明归属，交叉对账同样过不了，日常操作会毫无征兆地失败。规范示例的实现复用了 ENS 标准的解析器查询面，验证函数只做读取与比对，验证成本低到任何钱包或应用都能顺手内置，不必信任任何第三方授权服务。轻巧设计的另一面同样清楚：它把双域名记录的配置正确性，默默转移给了普通用户自己。

Stagnant 状态与它的思想遗产

按 ercs 仓库记录，SAFE 停在 Stagnant，没有成为广泛部署的设施。原因不难理解：它依赖双方都持有并正确配置 ENS 域名，这个前提在普通用户里覆盖太低；账户抽象路线后来用更体系化的方式解决了同一问题。但这份提案切中了一个长期存在的真实缝隙，值得记住它的方法论：身份与授权的声明，可以利用已有的命名系统做交叉验证，而不是每遇到一个场景就部署一个新合约。今天去看各类“账户授权关系”的设计——智能合约钱包的模块注册、社交恢复的守护者名单、平台对官方账号的签名声明——底层问题都是同一个：声明关系放哪、谁来验证、更新成本多低。SAFE 给出的答案是放进最中立的命名层、让任何人都能验证、更新等于改一条记录。带着这三个问题读任何授权机制，你对它的信任就能落在可核对的事实上，而不是项目方的口头上。

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