钱包可迁移，也要有人负责停止授权

分析 | 2026年10月14日。

10月13日公告预告将进一步完善控制功能。然而，Privy的XRPL文档已经描述了策略执行能力。这些材料尚未明确实际推出范围。规格说明并不能证明某个应用已启用哪些功能。更持久的问题是：当所有者迁移钱包、失去访问权限或停止自动支出时，控制权如何变化？本文将这几种情况分开分析，因为其中一种演示成功，并不代表其他情况也能顺利处理。

导出是一场迁移测试

Privy的导出指南说明，导出路径取决于钱包的创建环境。对产品团队而言，有用的测试不应止于找到导出按钮。可以设定一个虚构的所有者，让其先完成一笔获准付款，再在测试环境中改用另一个界面。他是否仍能识别自己的账户、理解其权限，并完成同样获准的操作？

然后测试限制。要求新界面执行一个原有安排会拒绝的操作，记录限制是被保留、消失，还是需要重新建立。这是一项建议采用的验收测试，并非断言某个实现允许绕过限制。可迁移性的承诺应同时说明所有者获得了什么，以及哪些责任会随之转移。

这一区别具有商业意义。清晰的退出流程可能降低对单一应用的依赖；但若防护措施的变化解释不清，也可能增加所有者的操作负担。仅统计导出次数，无法看见这种取舍。

恢复应还原正确的权限

XRPL的密钥管理指南要求在停用主密钥之前，先具备另一种授权方式。我们提出的更广泛设计问题是：恢复流程到底恢复了什么？恢复登录、恢复签名能力，以及恢复修改权限的权力，应分别评估。

设想所有者丢失了一台设备，而代理仍获准执行操作。恢复演练应确认谁能介入、需要提供什么证据，以及哪些旧权限仍然有效。还应测试失败场景：只知道账户名称，却缺少必要证明的人，不应获得控制权。

一份有用的完成记录应同时展示两个结果：合法所有者能够再次操作，而计划废止的权限确实已不能使用。只恢复便利性，却不核对第二个结果，测试就不完整。

明确谁能停止支出

Privy的控制模型将钱包所有权赋予一个密钥或达到审批门槛的一组密钥。接下来，我们建议追问一个人的责任问题：出了状况，谁负责使用这项权力？

对于一个假设的代理钱包，应记录谁能申请支出、谁能修改限额，以及谁能终止授权。这些角色可以重合，但重合应是有意的设计。财务人员能够观察活动，并不应被误认为他们有权叫停活动。

最能说明问题的演练，应从撤回授权之后开始。用原来的权限提交一个新请求，并验证它被拒绝。同时，单独检查那些已经签名或提交的请求，而不要假定一条撤销成功的消息就解决了此前所有操作。测试应区分阻止新的授权操作与调查既有工作。

衡量能否安全地失败

这些演练提出了一个比功能清单更有价值的采购问题：预期的所有者，能否在更换界面、失去访问权限和撤回委托时继续掌控钱包？

可信的答案应包含测试结果、明确的责任人和清楚的限制，也应说明哪些保护被保留、哪些被有意替换，以及哪些依赖另一方在线可用。这些证据才能让可迁移性具有实际意义，避免恢复沦为空泛承诺，也避免停止授权成为无人负责的工作。