智能账户把登录说明书挂在链上：ERC-6662 账户元数据想解决什么

连网站要”连接钱包”，换设备要重新授权，登录状态说不清挂在哪——这些麻烦在智能账户（ERC-4337 那一类合约钱包）世界里有个更根本的原因：链上只认地址，不认”这个地址背后由谁、在哪、怎么替你签名”。ERC-6662（AA Account Metadata For Authentication）的思路是把这层信息登记到链上：账户自己挂一份”认证说明书”，应用可以直接来查，而不是每次靠弹窗连接。提案 2023 年 3 月 9 日提交，依赖 ERC-4337 与 ERC-4804，官方状态是 Draft。

一个接口的三个字段

方案的核心是叫 IAccountMetadata 的接口，作为 ERC-4337 IAccount 的扩展，对外只有一个函数 getAuthenticationInfo，返回一份 AuthenticatorInfo 清单。清单每项含两个字段：relayURI——一串服务地址，应用把验证请求经它转给你的认证器；schema——一段 JSON 描述（或其 URI），声明”认证请求该长什么样”。规范示例里，认证请求对象包含入口合约地址、链标识、去掉签名字段的 UserOp，外加一个装着加密内容的 encryptedData，并建议用类似 $e2ee 的标记表示字段已端到端加密。注册动作本身是账户合约把这份元数据写进自己的存储，一次部署长期有效；链标识字段特意要求用十六进制字符串表示，属于少见的规范性细节，说明作者预想过跨链复用的场景。

认证器可以离你很远，也可以离你很近

这份设计把”签名的人”从”持有钱包应用”里拆出来：认证器可以是一部离线保存密钥的设备，也可以是一个在线云服务（此时它自己直接监听应用请求）。应用发起一次请求，按链上登记的 relayURI 找到中继，中继再转给认证器；认证器核对后补签名。方向反过来也成立——因为信息登记在链上，应用可以主动查询而不必等你点”连接钱包”，这正是它对比传统连接模式的卖点，与一条通道完成连接：ERC-7846 的 wallet_connect 把授权与登录合成一次弹窗把授权与登录合并成一次弹窗的 wallet_connect 是同一片土壤上的两种长法：一个走浏览器接口做加法，一个走链上登记做减法，都试图回答”网站怎么知道该找谁要签名”。

用户该核对什么

第一，说明书写在链上，意味着任何人可查：你的账户用哪些中继、走什么认证格式，都是公开信息。链上公开什么就暴露什么的道理，在WalletConnect会话权限怎么读？的会话权限讨论里同样适用。第二，认证器是第三方时，“谁替我签”从设备安全变成了服务条款问题——服务停机、被收购、改条款，你的账户可用性跟着动。第三，注册链上元数据是一次交易，relayURI 指向谁的域名、schema 由谁维护，登记那一刻就固化进链上记录，改一次又要一笔交易。规范虽然提到加密字段，但加密只保护请求内容，不保护”你用了哪家认证器”这一事实本身，隐私预期要按这个口径设定。

现状

ERC-6662 停留在 Draft，主流智能账户实现没有把它作为标配接口，今天的登录体验更多由 wallet_connect、SIWE 一系接口推动。它值得读的原因不在”现在能不能用”，而在于问题真实存在：账户抽象越普及，“地址与认证方式脱钩”的需求越明显——今天各家钱包用推送通知、私有配对码、扩展中继各自解决同一个问题，恰恰说明标准化的空间没有消失。对个人用户，现在能做的准备是把常用账户的认证路径记录下来：哪些应用有活跃会话、认证依赖哪台设备、换了手机从哪里恢复，这份清单比任何单一接口都更保值。字段名与流程以官方提案文本为准。本文为机制科普，不构成投资建议。