ERC-6981 预留地址：平台先给你分配链上地址，钱包最后由你部署

一个部署前的尴尬

合约钱包（智能账户）的地址要等合约真正部署到链上才存在。可很多场景需要先有地址：平台想直接给你打一笔 NFT 或空投，而你连链上交互记录都没有。常见妥协是让平台代持，或先发个临时地址——两者都意味着资产暂时在别人手里。

ERC-6981 提供了第三条路。它在标准仓库中状态为 Draft（草案），核心是一个预留地址注册表：平台（提案中称 service）为用户生成一个唯一的盐值，签一份声明，用户凭盐和签名就能在链下算出一个确定会被部署出来的未来地址，提前收款；等用户准备好了，再亲自部署合约钱包拿回控制权。

地址凭什么能提前算出来

依据是 CREATE2 的确定性：合约地址由部署者地址、盐值和合约初始化代码三者哈希决定。注册表合约充当统一的部署者，只要平台声明“这个用户的盐是某个值”，任何人都能离线算出对应的未来地址。规范让注册表与 1167 最小代理、1271 合约签名、6492 签名构造等既有标准衔接，目标是让这类“尚未存在的账户”在生态工具里表现得尽量像一个普通地址。

从用户视角，流程被压缩成三步：

1. 平台注册盐值，发一份包含盐和生效上下文的签名，把地址“预留”给你。
2. 你拿到地址后可以立即接收资产，链上资产记录直接落在这个未来地址上，不经过平台钱包。
3. 你选择时机（想真正掌管它的那天）提交部署交易，部署出来的合约钱包就落在那个地址上，签名验证逻辑接管资产，控制权从“等待兑现”变为“已经自托管”。

安全边界在哪里

这个设计把平台从资产托管方改成了“登记员”，但信任并没有消失，只是换了位置：

• 盐值生成与签名过程在平台服务器完成。平台如果作恶，理论上可以抢先部署某个盐对应的钱包——但部署前资产已经在地址上，抢先部署会改变该地址未来的钱包逻辑，所以这套机制的安全性高度依赖注册表按规范处理“预留—部署”校验，部署交易的逻辑与声明的实现严格一致。选择支持该标准的平台时，值得核实注册表合约地址和实现仓库。
• 在你部署之前，这个地址没有任何密钥可言，也没有撤销权：谁先凑齐“盐 + 注册表登记 + 部署交易”三件套，地址就归谁。平台账号被盗，预留信息泄露，风险窗口就在部署前的这段时间。尽早部署是常识。
• 未来地址依赖 EIP-1167 代理与固定实现代码的模式。实现升级、注册表迁移都可能改变钱包逻辑，部署前确认注册表地址与平台文档一致。

对 NFT 玩家的实际意义

最直接的收益场景是“无链上足迹的领取”：活动主办方把奖励直接打到一批参与者的预留地址，参与者日后自行部署取回，省掉托管批次和认领脚本。另一个场景是继承与机构流程：先把资产转给“将来才存在的账户”，避免中间环节的代持风险。

评估一个使用这类地址的产品时，问三个问题就够画像是非：注册表合约是否公开可查、平台签名如何签发与轮换、部署前的资产由谁在什么条件下能动。答案透明，机制就比代持友好；含糊其辞，本质仍是托管。

风险提示：合约钱包部署前的地址控制权依赖注册表与平台流程，存在实现与平台风险，本文不构成任何投资建议。