Multisig Mechanics
Relevant source files
The following files were used as context for generating this wiki page:
Canon Guard (formerly referred to as Safer Safe) is an advanced multisig enhancement layer built on top of the industry-standard Safe smart accounts. It introduces a security framework that utilizes fully on-chain Actions contracts and dynamic timelocks to minimize reliance on external services while simplifying the verification of recurring transactions.
The system's primary objective is to provide a "safer" way to execute transactions by enforcing time delays, mandatory approval mechanisms for specific action patterns, and emergency protection features. It operates through a modular architecture where an entrypoint contract governs how transactions are queued, validated, and eventually executed by the underlying Safe.
Sources: README.md:3-5, CLAUDE.md:7-10
Core Architecture
The Canon Guard architecture is composed of several interlocking components that extend the functionality of a standard Safe multisig. The logic is centered around the SafeEntrypoint, which acts as the gatekeeper for all interactions.
Component Overview
| Component | Description |
|---|---|
| SafeEntrypoint | The primary contract for executing transactions with time delays and approval logic. |
| ActionHub | An abstract management contract that coordinates "Action Builders." |
| Action Builders | Implementation contracts (e.g., SimpleActions, CappedTokenTransfers) that define specific transaction patterns. |
| OnlyEntrypointGuard | A security guard ensuring transactions are only executed via the authorized entrypoint. |
| EmergencyModeHook | A circuit-breaker mechanism to pause operations during security incidents. |
Sources: CLAUDE.md:14-20, test/invariants/PROPERTIES.md:5-10
Transaction Lifecycle Flow
The following diagram illustrates the lifecycle of a transaction within the multisig mechanics, from initial queueing to final execution.
The system distinguishes between different delay types. Transactions involving "Pre-approved" action builders utilize a shorter delay, while standard transactions default to a longer security timelock.
Sources: CLAUDE.md:65-70, test/invariants/PROPERTIES.md:21-25, test/invariants/PROPERTIES.md:46-52
Execution Dynamics and Timing
Multisig operations are governed by strict timing invariants to prevent front-running and ensure sufficient time for signers to review or cancel pending actions.
Timing Constraints
All queued transactions are subject to three specific timestamps:
- queuedAt: The block timestamp when the transaction was first added to the queue.
- executableAt: The earliest time the transaction can be processed (queuedAt + delay).
- expiresAt: The deadline after which the transaction is no longer valid for execution.
Sources: test/invariants/PROPERTIES.md:21-23
Approval Logic
The relationship between Action Builders and the Entrypoint is strictly managed through approvals. The system maintains ghost state consistency to ensure every queued hash corresponds to a valid, non-zero action builder.
Security Invariants
The security of the multisig mechanics is validated through a series of invariant tests that ensure the system remains in a consistent state even under edge cases.
Queue Consistency
- No Duplicates: The transaction queue is prevented from having duplicate action builder addresses.
- Mapping Sync: The internal queue array and the
transactionsInfomapping must always remain synchronized; any builder in the queue must have a non-zero expiry timestamp. - Sanity Checks: Every hash in the system's "ghost state" must map to a valid action builder.
Guardrails
- Cap Limits: Action hubs (such as
CappedTokenTransfers) enforce that transaction limits are never exceeded, accounting for defined epoch boundaries. - Expiry Limits: Approval durations are capped at a
MAX_APPROVAL_DURATIONto prevent indefinite authorizations.
Sources: test/invariants/PROPERTIES.md:13-35
Deployment and Configuration
The system is deployed using Foundry scripts with specific configurations for different EVM-compatible networks.
| Parameter | Value / Detail |
|---|---|
| Solidity Version | 0.8.30 |
| EVM Version | Prague |
| Optimizer Runs | 10,000 |
| Deployment Method | CREATE3 (Deterministic) |
Sources: foundry.toml:13-17, CLAUDE.md:52-54, CLAUDE.md:65
Deployment Scripts
The project uses specific yarn commands to handle deployments to Ethereum and Optimism, ensuring that the SafeEntrypoint and related contracts are initialized correctly within the multisig environment.
# Deploy to Ethereum
yarn deploy:ethereum:canon-guard
# Deploy to Optimism
yarn deploy:optimism:canon-guard
Sources: package.json:15-16, README.md:73-83
Summary
Multisig Mechanics in Canon Guard represent a shift from simple signature-based execution to a structured, on-chain workflow. By integrating SafeEntrypoint with specialized ActionBuilders and enforcing cryptographic timelocks, the system provides a robust framework for managing treasury operations. The architecture ensures that all actions are pre-validated, transparently queued, and subject to mandatory delays, thereby significantly reducing the surface area for governance attacks or accidental misconfigurations.