Turnkey 钱包无法导出？先核对钱包 ID、根权限和恢复条件
链小知 · 进阶 · 核验 · 依官方文档整理
从已有钱包记录确定导出对象，审核子组织 root quorum 和 policy，区分 Exported 标记、解密及实际恢复。
开始前准备
- 准备使用 Turnkey 的应用名称、当前版本、本人公开钱包地址、子组织 ID 和已有脱敏钱包/权限记录；没有内部记录时向应用索取公开字段说明。
- 本流程以检查导出资格为目标；检查材料不包含私钥、助记词、API key、认证凭据或加密目标私钥。
- 普通应用用户不应为核查新建 Turnkey 开发者组织；原账户控制方式和导出入口由原应用配置决定。
1. 定位原钱包及导出对象
在应用钱包设置或已有 useTurnkey 的 wallets 记录中，对照 walletId、完整地址及 accounts 的 addressFormat、path。列表可包含嵌入和外部钱包，外部连接账户不能当成本子组织托管的嵌入钱包。
核对入口标的是导出整个 wallet、一个 wallet account，还是 raw private key。官方示例 wallets[0] 只是演示写法，多钱包时不能据此选第一项；地址或 ID 不一致先停止。
检查结果：得到唯一目标 wallet/account 及对应子组织，缺失字段记为待核。
2. 核对能决定操作的根成员
在已有子组织配置中查看 root quorum 的 userIds 和 threshold，并将每个 userId 的控制方标为本人、应用或未知。父组织默认只读是组织间权限，应用也可能通过子组织自己的程序用户或根成员操作。
根 quorum 达到阈值可绕过全部 policy。一个 1/2 配置不是要求两人共同批准，而是两位成员中的一位即可满足阈值；不能因看到两个成员就写成双人共同控制。
检查结果：成员归属与阈值分别清楚，没有把父组织只读或成员数量当控制证明。
3. 读取日常与导出活动的策略
从当前脱敏 policy 列表核对 effect、consensus、condition：谁能请求、限定哪个钱包、允许哪类操作。对非 root 请求，适用 deny 优先，再看 allow；没有适用 allow 通常隐式拒绝，读取等行为另有例外。
请求被拒时保留活动类型、错误和目标 ID，交由应用核对策略。root quorum 成员也可能获得单独执行特定活动的 policy，不能把根阈值推广成每项日常操作都要相同人数。
检查结果：能区分根授权、日常策略和本次导出拒绝原因；未查看的策略保持未知。
4. 确认导出入口及状态的含义
React Embedded Wallet Kit 的 handleExportWallet({walletId}) 可由应用打开导出 modal。官方协议先用用户控制的 P-256 target encryption key 公钥加密结果，再由对应私钥解密；收到 encrypted bundle 不等于已经得到可用备份。
检查应用说明与已保存状态是否一致。Exported 标记不会删除 Turnkey 内的钱包，也不证明资金已经迁走。若仅审核集成版本，iframe-stamper 小于 2.0.0 的官方旧版限制应交给应用处理，不要用旧示例自行绕过入口。
检查结果：输出入口、目标和已知活动阶段；解密、备份验证或资产迁移没有证据时不记为完成。
5. 整理恢复缺口和下一步
对照应用已有恢复设置，分别记录可用 authenticators、邮件或社交身份恢复条件、root quorum 的可达成员，以及是否提供钱包材料备份。邮件可恢复登录，并不自动满足全部钱包操作的授权条件。
若身份失效、根阈值无法满足或应用没有导出入口，保留具体缺口和公开 ID，联系该应用支持确认可用路径。服务费用按应用配置核对，后续迁移交易另算网络费用；不要用删账户来证明备份可恢复。
检查结果：形成对象、权限、导出阶段和恢复缺口四项记录，未知条件没有改写为保证。
怎样确认完成
- 已定位正确的子组织和 wallet/account，整理当前权限与导出资格。
- 失败原因有脱敏记录或明确标未知；不声称备份可用、资金已迁移或服务中断时必能恢复。
- 本文按官方文档核验，未进行登录、导出、签名或恢复实操。
常见错误与边界
- root 达标可绕过 policy，普通 allowlist 不能约束所有根操作。
- 导出整钱包、账户私钥和外部连接钱包是不同对象。
- 导出状态、登录成功与异地恢复成功需要不同证据。