系统架构

HypeSafe 将人工操作界面、无私钥协调服务、签名人侧自动化和 Hyperliquid 执行层分开。

架构围绕两个目标设计：

• 安全默认值：账户操作需要获得配置中的多签 owner 审批。
• 最大工作流灵活性：团队可以使用人工工作台、可选本地自动化，或同时使用两者，而不改变审批模型。

组件

• safe-frontend 是 Web 应用。用户在这里连接钱包、登录、创建或添加账户、查看提案、审批任务，并在自己是选定 leader 时执行。
• safe-gateway 是协调 API。它跟踪账户、模板、任务、签名、拒绝票和执行历史。它构建 owner 要查看的准确 typed payload，并在计入审批前验证提交的签名。
• safe-node 是可选组件。它是面向某一个多签账户的自托管签名与策略服务。它可以协签符合策略的任务；如果它是 leader，也可以将已批准操作提交到 Hyperliquid。
• Hyperliquid 是最终执行层。已批准的操作最终会作为原生 multisig action 提交到 Hyperliquid。

交易流程

1. 签名人在 frontend 中选择账户、模板、输入和 leader。
2. Gateway 预留 nonce，并创建固定的签名 payload。
3. 发起人先签名，其他签名人查看同一个 payload 后审批或拒绝。
4. Gateway 恢复签名人地址，确认其有权限，然后统计审批进度。
5. 达到阈值后，由 leader 执行。执行可以在 frontend 中手动完成，也可以通过 leader node 完成。
6. 执行结果写回 gateway，团队可以查看历史和最终状态。

签名边界

Gateway 永远不持有私钥，也不会代表用户签名。

业务签名来自：

• 由人工签名人控制的浏览器钱包；或
• 由操作方控制的自托管 safe-node 实例。

Gateway 的职责是协调：构建标准 payload、验证签名、统计审批，并保持读取模型一致。操作提交时，Hyperliquid 仍然会执行最终多签验证。

自动化边界

safe-node 扩展工作流，但不会替代多签。它只能使用操作方配置的本地 signer。它不能代替其他 owner 签名，也不能让 gateway 绕过审批验证。

Node 路径和 frontend 使用同一套 gateway API：

• 它使用本地 signer 登录 gateway；
• 它跟踪配置好的多签账户；
• 它拉取 sign 和 execute inbox；
• 它在签名前应用本地策略；
• 它通过 gateway endpoint 提交签名、拒绝票和执行结果。

这让自动化审批和人工审批留在同一条审计记录中。