Safe多签交易如何提案、确认与执行？

按官方API Kit流程说明创建交易、计算哈希、提案、查询和收集确认。

本文围绕“Safe多签交易如何提案并收集确认safeTxHash与签名步骤详解”建立一份可复查的Safe提案与确认工作底稿：先区分规范事实、部署状态与界面推断，再给出可以实际执行的核验顺序。

Safe提案与确认：现场核验清单

• 创建交易后独立计算safeTxHash。
• 每位owner签名前核对Safe、chainId、nonce和data。
• 达到阈值后另行执行，并以链上nonce与事件收尾。
• 保存两条一手来源的版本与访问日期
• 记录仍未确认的网络、实现或权限差异

只有与Safe提案与确认直接相关的前三项全部能复现，才把本次记录交给下一位复核者。

Safe提案与确认：事实问答

提案时序应怎样理解？

Safe提案流程先创建SafeTransaction，再用Safe地址和交易内容计算safeTxHash，由owner签名后提交到Transaction Service。

safeTxHash字段应怎样理解？

其他owner可从服务读取同一safeTxHash并提交确认签名；服务端确认只是链下聚合，不等于交易已经在链上执行。

确认与执行对照应怎样理解？

每位签名者都应核对chainId、Safe地址、nonce、to、value、data与operation，达到阈值后仍需单独发起执行交易。

Safe提案与确认：什么时候必须停手

未解决问题	当前处理
服务索引延迟、nonce冲突和不同SDK版本会影响结果，最终状态应以Safe合约链上事件与nonce为准。	标记待核验，不继续外推
来源版本或目标网络不一致	重新取证
无法复现达到阈值后另行执行，并以链上nonce与事件收尾。	不显示完成

Safe提案与确认：四个常见追问

规范页面存在，能否说明目标网络已经支持？

不能。规范事实和部署状态是两份证据，必须用“创建交易后独立计算safeTxHash。”核对目标环境。

返回格式正确，能否直接判定业务成功？

不能。还要执行“每位owner签名前核对Safe、chainId、nonce和data。”，确认字段在当前状态下的含义。

页面显示完成，是否还需要原始记录？

需要。最终判断必须能够通过“达到阈值后另行执行，并以链上nonce与事件收尾。”复查。

两个来源有差异时采用哪一个？

先比较版本、网络、对象和访问时间；无法解释差异时把结果标成待核验。

Safe提案与确认：原始规范索引

来源	本文用途
Safe Docs	核对Safe提案与确认的正式接口、字段与规范语义
Safe API Kit	核对Safe提案与确认的实现路径、兼容性或安全边界

Safe提案与确认的资料读取时间为2026-07-19。涉及签名、权限、资金或部署动作时，应重新打开一手页面确认当前版本。Safe提案与确认的站内延伸阅读：EIP-712签名核对、链上权限模型。