钱包还没部署就能签名？ERC-6492 反事实签名验证

智能合约钱包（多签、插件式账户）的地址可以由部署参数提前算出来——先有”这个地址会属于我”，后有”地址上真的有合约”。问题来了：这类钱包还没部署时，EIP-712 消息签名该找谁验证？链上地址上没有代码，常规的 ERC-1271 合约签名验证无从调起。ERC-6492（Signature Validation for Predeploy Contracts）状态为 Final（最终标准），创建于 2023 年 2 月 10 日，依赖 ERC-1271，专门解决”合约还没出生就签名”的验证难题。本文讲机制，不构成任何操作建议。

包装格式：在签名尾巴上塞部署说明书

未部署的钱包签名时，把原始 ERC-1271 签名连同部署信息一起打包：部署工厂地址、工厂调用数据、原始签名，三者做 ABI 编码后再拼上一串 32 字节的魔数（0x6492 重复十六次）。规范推荐配合 CREATE2 使用，因为它的地址在任何部署前都可预测。已部署的钱包用普通 ERC-1271 格式即可；部署了但暂时还不能验签的（比如需要一次迁移调用），还有第三种把”预备调用”写进包装的格式。

验证顺序是标准的核心

规范要求验证按固定顺序走：第一步查签名尾部是否为魔数——是的话通过多调用合约先触发工厂部署，再用解出来的原始签名调 isValidSignature；第二步看地址上有没有代码，有就走常规 ERC-1271；第三步，若 ERC-1271 验证失败而包装数据还没试过，补执行部署调用再验一次；第四步都没有代码，才按普通外部账户走 ecrecover。顺序背后有理由：魔数检查必须在 ERC-1271 与 ecrecover 之前，防止合约钱包的签名被当成外部账户签名误判；而魔数以 0x92 结尾，天然不会和合法的 ecrecover 签名格式相撞。

对 NFT 玩家最直接的用处

新钱包领空投、认领铸造最经典的失败画面就是：签名被服务端以”签名无效”拒收，因为认领方要求地址是智能账户，而这个账户还没部署。ERC-6492 普及后，支持它的验证方可以接受反事实签名，钱包先签名、认领交易顺带完成部署，一步到位。查一个平台支不支持，就看它验证签名的服务是否声明兼容该标准。

值得留意的一格

标准的信任结构没有变：验签仍然依赖 CREATE2 工厂与部署数据的诚实性，仿冒工厂包装理论上存在，因此大额或高价值认领仍要在认领界面核对最终字节与地址推导是否与官方实现一致。标准解决的是”能不能验”，不解决”该不该信”。

为什么反事实签名不会被误认

魔数的设计带了一点小巧合：包装格式以 0x92 结尾，而在把签名按 r、s、v 打包的 ecrecover 方案里，v 取 27 或 28 一类值，0x92 从来不是合法的 v——两种格式在语法层就不可能相撞。魔数本身是 0x6492 重复十六次凑成的 32 字节，随机撞上的概率可以忽略。对实现者来说，规范把顺序讲得比格式更重：先魔数、再查地址代码、再 ERC-1271、最后 ecrecover，任何一步提前都可能把合约钱包的签名错判成外部账户签名——尤其当合约恰好是某个外部账户的代理钱包时，两套地址不同却签名合法的冲突真实存在。这套顺序还带来一个实用副作用：按标准包装后，验证方甚至能从签名里直接恢复出账户地址（靠工厂与调用数据推导），不必先知道地址才能验签。

反事实签名让智能账户从第一次交互就可用，但任何签名授权前读清楚内容的原则不变；本文仅为机制科普，不构成投资建议。