Fundamental security assumptions

• Using a UI hosted on an external server means relying entirely on it not being hacked.
• Even extremely cautious multisig signers can still get hacked.
• A "$5 wrench attack" (physical threats or coercion) is a genuine risk and should be considered when designing secure processes.
• Even the most meticulous signers will eventually experience review fatigue from repeatedly checking the same multisig transactions, potentially overlooking critical details.

Core principles for Safer Safes

• Minimize repetitive approvals: Recurring transactions should only require thorough verification once, rather than repeatedly.
• Timelocks on all transactions:
  • Pre-approved or routine transactions can go through a short timelock
  • New, unusual, or higher-risk transactions must face a longer timelock to allow cancellation.
• Prohibit DELEGATECALL: This opcode introduces critical security risks and should be categorically disallowed.
• Eliminate external dependencies: The Signers flow should rely solely on the blockchain—no off-chain trust or external services.
• Everything on-chain:
  • Approvals must be done via on-chain transactions only.
  • Simulations and safety checks should depend purely on on-chain data, requiring zero off-chain inputs.
• Resilience under coercion: Even in extreme scenarios (e.g., all signers compromised simultaneously), it should still be impossible to immediately drain the Safe.
• Emergency recovery mechanism:
  • To mitigate accidental lockouts or misconfigurations, a high-threshold emergency multisig (e.g., 10-of-12) may be deployed
  • This is assumed to be secure and used only as a last resort.

A Safer Execution Model for Multisigs

Organizations that rely on multisigs often execute recurring transactions—such as salary disbursements or vesting fund claims. Each transaction proposal and signature introduces a surface for potential exploitation. The goal of this solution is to significantly reduce that risk.

This approach draws inspiration from the spells architecture used by Sky (formerly MakerDAO) and Spark, additionally avoiding the use of DELEGATECALL that requires extreme carefulness on each call, because of the risk of changing the contract storage (catastrophic).

At the core of this system is the concept of Actions: Solidity smart contracts that encapsulate all the necessary transaction logic and parameters. These Actions are designed to be:

Simple – Focused and easy to reason about.

Immutable – Once deployed, they cannot be altered.

Independent – Self-contained, with no external dependencies.