多签金库里的 NFT 怎么转出去：提议、凑签名、执行这三段

一个人管一把私钥的钱包，签一次就发出去。团队的 NFT 常放在多签智能账户里，同样的转移动作被拆成好几步：谁先提出、其他人怎么看到、签名怎么凑够、最后由谁上链。Safe 的开发者文档把这条链路写得很具体，收藏者哪怕只用网页端，理解它也能显著减少”卡在哪一步”的困惑。

第一步：先描述一笔要执行的动作

Safe 交易的数据结构核心是三个字段：目标地址 to、调用数据 data、金额 value，另有一个 operation 表示调用类型。从多签账户转一枚 NFT，本质就是让 Safe 去调用那枚藏品所在的合约：to 填集合合约地址，data 是带参数的转账调用，value 通常是 0。要在一次批准里转多枚，就传一个交易数组，由 Safe 批量执行——这也是团队做批量转移时最常见的形态。

确认前至少核对
- to：是集合合约、市场合约，还是某个陌生合约
- data：方法名与参数里的收款地址、代币编号
- value：这笔调用是否要带 ETH
- 数组长度：批量时是否被夹带进额外条目

第二步：算哈希、签名、把提案交出去

Safe 交易的哈希是基于交易参数确定性地算出来的 safeTxHash。提出方先算这个哈希、用自己的密钥对哈希签名，然后把交易数据和签名一起提交给 Safe Transaction Service，这一步在 SDK 里叫 proposeTransaction。文档对服务本身的定位值得记一句：它是一个集中式但开源的服务，任何人都能自己部署，Safe 钱包默认就用它来存交易与签名。也就是说，“别人能看到这笔提案”依赖的是一个链下服务，而不是链上事件。

其他持有者随后调用 getPendingTransactions 取回待处理列表，按 safeTxHash 认出同一笔，再各自签名并提交确认。因为签名对象是哈希而不是链上广播，凑签名这个阶段不花 gas，也不会产生不可撤销的动作。

第三步：凑够阈值才能执行，执行只发生一次

阈值决定门槛：如果阈值为 1，创建即可执行；大于 1 时，必须有足够多的持有者确认。文档在执行指南里说明，签名收集齐之后，这笔 Safe 交易才”可以被执行”，执行可以通过钱包网页、SDK、命令行或任何可用工具完成，执行后可以在交易历史里查到。

这里有两个防御性的常识：其一，待处理的提案在链上并没有生效，取消或替换只是链下状态的变化；其二，一旦签名凑够，任何有能力的人提交执行都会产生真实转账，因此”谁去点执行”在团队里最好有固定约定，避免同一笔被重复尝试或错时间执行。

文档还提到一种更复杂的情形：当签名方本身是一个子 Safe 账户时，签名方式要指定为智能合约签名，并且需要提供父 Safe 的地址，具体做法取决于合约版本。这类嵌套结构在联盟金库或多层治理里会出现。

一份给 NFT 团队的核对清单

1. 发起前：把 to、data、value 用可读工具解出来，写进提案说明
2. 确认时：每个签名人都独立比对 safeTxHash，而不是只看标题
3. 阈值变化后：重新检查历史待处理提案是否仍符合当前规则
4. 执行后：核对接收地址与代币编号，并在交易历史里留档
5. 出错时：优先确认签名是否凑齐、服务里的提案是否已被替换

多签解决的是”不能一个人说了算”，它不会自动帮你判断合约调用的内容是否正确；前者是权限结构，后者是每次签字时的人工核验。

还要提醒一个容易被误当成链上事实的细节：提案与签名在凑够阈值之前都只存在于链下服务里。文档说明这是一个集中式但开源、任何人都能自行部署的服务，Safe 钱包默认使用它。这意味着如果团队换用了另一套后端，此前只在某个服务里挂着的待处理提案未必能被新的签名人看到。稳妥的做法是把 safeTxHash 与解码后的调用内容一起记录在团队自己的工单里，让签名依据不完全依赖某一个界面的列表。

对 NFT 团队来说，另一条常见的意外来自阈值与持有人变更。阈值调低之后，此前需要多人同意才能执行的操作，可能只需要更少签名就能被推动；反之调高后，原本挂着的提案可能再也凑不齐。把“调整权限结构”当作一次独立的、需要重新核对所有待执行转账的事件，是比较稳妥的做法。执行环节本身也建议有固定约定：由谁提交、gas 从哪个账户出、失败后由谁复查，这些流程问题不会改变协议规则，却决定了同一笔 NFT 转账会不会被重复尝试。

本文为机制说明，不构成任何投资建议。