Architecture

HypeSafe separates the human operating surface, keyless coordination service, signer-side automation, and Hyperliquid execution layer.

The architecture is designed around two goals:

• secure default: account actions require approval from the configured multisig owners;
• maximum workflow flexibility: teams can use a manual workspace, optional local automation, or both without changing the approval model.

Components

• safe-frontend is the web app. It is where people connect wallets, sign in, create or add accounts, review proposals, approve tasks, and execute as the selected leader.
• safe-gateway is the coordination API. It tracks accounts, templates, tasks, signatures, rejection votes, and execution history. It builds the exact typed payloads owners review, then verifies submitted signatures before counting them.
• safe-node is optional. It is a self-hosted signer and policy service that pulls tasks from the gateway for one configured multisig account. It can co-sign allowed tasks and, if it is the leader, submit approved actions to Hyperliquid.
• Hyperliquid is the final execution layer. Approved actions ultimately go to Hyperliquid as native multisig actions.

Transaction flow

1. A signer uses the frontend to choose an account, template, inputs, and leader.
2. The gateway reserves the nonce and creates the fixed signing payload.
3. The initiator signs first, then other signers review the same payload and approve or reject.
4. The gateway recovers signer addresses, confirms they are authorized, and tallies approval progress.
5. Once the threshold is met, the leader executes. This can happen manually in the frontend or through a leader node.
6. The execution result is written back to the gateway so the team can see history and final status.

Signing boundary

The gateway never holds private keys and never signs on behalf of users.

Business signatures come from:

• browser wallets controlled by human signers; or
• self-hosted safe-node instances controlled by operators.

The gateway's job is coordination: build the canonical payload, verify signatures, count approvals, and keep the read model consistent. Hyperliquid still performs the final multisig validation when the action is submitted.

Automation boundary

safe-node extends the workflow without replacing the multisig. It can only use the local signer configured by the operator. It cannot sign for other owners and it cannot make the gateway bypass approval verification.

The node path uses the same gateway API as the frontend:

• it signs into the gateway with its local signer;
• it tracks the configured multisig account;
• it pulls sign and execute inboxes;
• it applies local policy before signing;
• it submits signatures, rejection votes, and execution results through gateway endpoints.

That keeps automation inside the same audit trail as manual approvals.