Dynamic：内嵌钱包与后台自动付款，先分清谁在控制

一个交易平台希望订单完成后自动向卖家付款。用户已经在使用内嵌钱包，于是团队想用同一家服务商给后台付款进程接上钱包。首先要回答的不是 SDK 怎么调用，而是后台在使用用户授予的权限，还是在支配平台自己控制的资金。

资料边界： 本文于 2026 年 11 月 1 日核对官方产品与技术资料，提出接入验收问题；没有部署付款系统，也没有执行钱包恢复测试。

公司关系与具体产品要分开看

Dynamic 当前产品页已归入 Fireblocks，展示内嵌钱包等金融产品能力。这个关系并不意味着 Dynamic 的接法等同于所有 Fireblocks 钱包产品。应该评估实际使用的 SDK、钱包类型及策略配置。

在平台例子中，用户登录与无人值守付款是两条路径。内嵌钱包可以服务用户体验，后台控制的钱包则可能用于平台自己的付款资金。选择哪一种，也是在决定谁负责授权、谁负责恢复。看到熟悉的登录界面，还不足以回答控制权问题。

后台钱包对运行环境有具体要求

Dynamic 的服务器钱包文档说明，Node SDK 使用原生 MPC 扩展，需要支持的标准 Node 运行环境，不能直接运行在浏览器或 Cloudflare Workers 这类边缘运行时。前端部署在边缘网络，并不妨碍调用独立后台，但这会增加一个需要保护和运维的服务。

因此，在编写付款队列前就应确定签名进程部署在哪里。接收业务请求的公开 API，与有权读取钱包材料并签名的服务，最好职责清楚。前端采用什么框架，不应顺带决定资金签名权限放在哪里。

数据持久化也是钱包设计的一部分

服务器钱包流程概念示意，非部署实测。钱包元数据与签名材料的存储和访问要求不同。

Dynamic 的存储指南说明 SDK 本身无状态。应用需要保留完整钱包元数据，包括与恢复有关的字段；选择自行管理时，还要保护客户端一侧的密钥分片。在文档描述的流程里，只留下公开地址，不足以完成之后的签名或导出。

这会直接影响灾难恢复。数据库恢复出了卖家编号和地址，不代表签名服务也恢复了。应围绕完整钱包状态及访问权限设计恢复演练，而不只是恢复付款流水。排查问题时，也不能为了方便把密钥分片写入普通日志。

策略限制的是哪一个量

策略文档介绍了当前 v3 TSS-MPC 钱包的签名前检查，包括单笔金额限制和地址规则。核对时，钱包层与签名器层策略仍标记为 early access，不同链的校验也存在例外。出现在支持网络列表里，不等于每一种规则对所有操作都生效。

对卖家付款系统，单笔上限不能代表月度额度。把大额请求拆成多笔小额请求，可能仍满足每次调用的限制。如果产品承诺累计预算，就必须指出总量由哪里记录和执行，并考虑多个进程并发付款的情况。

另一方面，收款地址白名单也可能漏掉合约调用过程中涉及的其他地址。应核对模拟执行路径和必要参与方。一次正常付款被拒绝，不应成为关闭整个环境白名单的理由。

开启自动化前，明确运维责任

需要回答的问题	对平台为什么重要
谁能修改策略	付款进程不应随意改写自己的限制
谁恢复钱包状态	恢复业务数据与恢复签名能力是不同职责
哪项服务能解密分片	无关 API 被攻破不应直接解锁付款
策略拒绝后怎么办	订单保持未支付，不能悄悄换用更宽权限
哪种状态算付款完成	签名或广播尝试不等于卖家收到可核对的款项

这些是我们提出的验收标准，不是说某个默认配置自动满足全部要求。成本评估也要包括钱包服务、RPC、网络费用与恢复工作，而不只是看是否提供内嵌钱包功能。

我们的判断

Dynamic 适合同时需要用户钱包体验与后台可编程操作的产品继续评估。建议从控制权示意图、实际运行环境和恢复演练开始。MPC 改变了签名材料的处理方式，但不会替应用解决凭证、授权和重复付款问题。

相关资料见 Dynamic 目录页与支付幂等性。先验证一条边界清楚的付款流程，比直接让进程操作环境中的所有钱包更容易发现问题。