ZeroDev换owner后地址不对：核guardian恢复与原账户
链小知 · 进阶 · 核验 · 依官方文档整理
把Kernel账户、guardian验证器、恢复动作与新owner分开，避免恢复后创建到另一个账户。
开始前准备
- 准备已有脱敏账户地址、网络、Kernel/EntryPoint版本、guardian设置和恢复前后owner材料；不要只留登录截图。
1. 确认原账户与文档版本配对
先记录原智能账户地址、链、EntryPoint、Kernel与validator。create-account页要求显式版本：其示例将旧SDK v4及以下配Kernel 2.4/EntryPoint 0.6，已有SDK v5配3.0/0.7，新示例用3.1/0.7；不能仅凭包更新自动替换实际账户版本。
该页区分创建账户对象和首次UserOp部署。只有计算出的地址，不能证明账户已部署、guardian已启用或已恢复；没有这些记录就先保留未知。
检查结果：原账户地址、版本配对和对象/已部署状态分开。
2. 核guardian是否在失钥前配置
恢复flow适用于已用官方恢复插件设置的Kernel账户。自恢复是另一本人认证因子；DApp-assisted是把应用作为guardian，不能把任意邮箱登录当已获guardian恢复权。
SDK示例先用guardian signer构造signerToEcdsaValidator，多个guardian则指向multisig validator方法。此处按已有实际配置识别单guardian/多guardian，不从联系人列表推门槛或签名已足够。
检查结果：guardian身份、validator及事先启用证据明确，缺证不视为可恢复。
3. 核恢复动作和目标validator的数据
原设置应分别对plugins.sudo、plugins.regular（guardianValidator）及action.address/selector。官方示例的action为doRecovery(address _validator,bytes _data)的recovery executor，面向ECDSA validator；不是普通转账目标或任意合约恢复器。
实际恢复示例将ECDSA_VALIDATOR_ADDRESS与newSigner.address送入doRecovery。只对已有编码参数和授权记录核目标，准备好的callData或返回UserOp hash不证明owner已更换；不同validator或版本不套此例。
检查结果：guardian授权、executor/selector、目标validator与新owner对应原材料。
4. 恢复后显式绑定原地址并核owner
官方写明更换owner后，不能再由新owner计算原账户地址；重建createKernelAccount对象时要显式address使用原智能账户地址，保留匹配的版本与其他配置。否则“新owner登录成功”可能只是生成另一个账户对象。
create-account FAQ给出ECDSA validator的ecdsaValidatorStorage(account.address) owner字段。用本人已有该字段/恢复结果材料对原地址的新owner，缺当前owner结果就留未验证；不要由地址计算或页面按钮推实际恢复成功。
检查结果：原地址继续使用，新owner字段有对应材料或明确未验证。
5. 将便利门户与链上恢复权限分开
recovery portal是便利UI，不是恢复能力本身；官方说明已获授权的guardian可直接与账户交互，即使门户停止服务。能打开门户或插件对象不等有guardian权限。
归档原地址、旧/新owner、guardian及实际结果状态。恢复文档不证明全部旧guardian、session或其他插件权限已撤销；这些项没有单独记录时保留未知，也不从该ECDSA示例推其他恢复方案的延迟或门槛。
检查结果：门户可达、guardian权限、owner变化与其他插件状态分别记录。
怎样确认完成
- 得到原账户地址、guardian配置与恢复前后owner对照；官方方法已核，实际账户恢复状态依本人原记录确认。
常见错误与边界
- guardian必须事先设置；另一个登录因子不自动获得恢复权。
- 新owner地址不是原智能账户地址，不能丢弃原address再重新推导。
- ECDSA示例不覆盖所有validator，也不证明恢复后所有旧授权已经清除。