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 Canon Guard

• 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 mode:
  • In case of an emergency, the Safe could be set in emergency mode by the allowed address (most probably a 1/x multisig)
  • When in emergency mode, the emergency signer will be required to also sign any transaction for its execution (the emergency signer will most probably be a 4/7 multisig or similar).
  • In case most signers of the Safe get compromised, this would allow the rotation of signers.

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.