Security Model
Relevant source files
The following files were used as context for generating this wiki page:
The Canon Guard security model is designed as a modular enhancement for Safe (formerly Gnosis Safe) multisigs. Its primary purpose is to introduce programmable transaction execution through fully on-chain "Actions" contracts and dynamic timelocks. By moving transaction logic into specialized "Action Builder" contracts and enforcing time delays, the system minimizes reliance on external services and provides a transparent, verifiable path for recurring or sensitive operations.
Sources: CLAUDE.md:8-11, README.md:3-5
Core Architectural Layers
The security model operates through a layered approach where the Safe remains the ultimate owner of funds, but its execution flow is constrained by a set of specialized contracts.
Execution Flow and Constraints
Transactions must navigate a lifecycle involving queueing, mandatory delays, and validation against specific Action Builders. This ensures that even if Safe owners' keys are compromised, the dynamic timelock provides a window for intervention.
The diagram shows the interaction between Safe owners, the entrypoint management system, and the underlying logic layer that validates transaction patterns.
Sources: CLAUDE.md:15-25, test/invariants/PROPERTIES.md:33-35
Key Security Components
| Component | Role in Security Model |
|---|---|
| SafeEntrypoint | The central hub for execution; manages time delays and approval mechanisms. |
| OnlyEntrypointGuard | A Safe Guard that enforces that transactions originate from the authorized entrypoint. |
| Action Builders | Contracts defining specific transaction patterns (e.g., transfers, capped spends). |
| EmergencyModeHook | A mechanism designed to pause system operations during critical security events. |
| ActionHub | An abstract management layer for organizing and approving groups of Action Builders. |
Sources: CLAUDE.md:15-23
Transaction Lifecycle and Delays
The model distinguishes between transaction types based on their approval status, applying different time delays to mitigate risk.
Execution Delays
- Short Delay (
SHORT_TX_EXECUTION_DELAY): Applied to pre-approved transactions or those originating from trusted action builders. - Long Delay (
LONG_TX_EXECUTION_DELAY): Applied to transactions that do not meet pre-approval criteria, allowing more time for the multisig to react. - Expiry (
TX_EXPIRY_DELAY): Transactions must be executed within a specific window after becoming executable, or they expire.
Sources: CLAUDE.md:65, test/invariants/PROPERTIES.md:40-45
Transaction Timing Invariants
The system enforces strict chronological rules for transaction states to prevent front-running or stale execution.
This sequence demonstrates how timing parameters are calculated at the moment of queueing based on the security context of the transaction.
Sources: test/invariants/PROPERTIES.md:21-25
Invariant-Based Verification
The security model is validated through extensive invariant testing and formal verification to ensure the system cannot enter "frozen" or inconsistent states.
Core Safety Invariants
- Cap & Accounting: Limits defined in action builders (e.g.,
CappedTokenTransfers) must never be exceeded, even across epoch boundaries. - Approval Consistency: Queued transactions must have valid approvals from their respective hubs or builders at all times.
- Queue Integrity: The system maintains a strict mapping between the queue array and transaction info to prevent duplicate entries or orphaned transactions.
Sources: test/invariants/PROPERTIES.md:10-31
Testing Infrastructure
| Tool | Purpose | Configuration |
|---|---|---|
| Medusa | Fuzzing campaign for invariant discovery | 1000s of runs, 10 workers |
| Halmos | Symbolic execution for formal proof of logic | Integrated via yarn test:symbolic |
| Bulloak | Specification and linting of unit test trees | Used for test/unit files |
Sources: package.json:20-25, foundry.toml:34-40, medusa.json:3-10
Implementation Constraints
The security model relies on specific Solidity patterns and deployment strategies to maintain its integrity:
- Solidity 0.8.30: Leverages modern compiler safety features and the "Prague" EVM version.
- CREATE3: Used for deterministic address deployment, ensuring that entrypoints and builders are located at predictable addresses across different chains.
- Safe Integration: Built on top of
@safe-global/safe-contractsto inherit the security properties of the industry-standard multisig.
Sources: foundry.toml:15-18, CLAUDE.md:64, package.json:37
Conclusion
The Canon Guard Security Model effectively shifts the security burden from manual human verification of hex data to automated, on-chain validation via Action Builders. By enforcing mandatory time delays and strict invariant checks, it provides a resilient framework that protects assets even in the event of partial multisig compromise or administrative errors.