Security Overview
Multyr is designed around a core principle: minimize the attack surface, then layer defenses around what remains. Every architectural decision — from contract structure to role separation — serves this goal.
Design Philosophy
- Minimal core. CoreVault holds user funds and exposes the smallest possible interface. Logic that can live elsewhere (fee calculation, strategy routing, oracle aggregation) is pushed to dedicated peripheral contracts.
- Defense-in-depth. No single control is trusted alone. Critical parameter changes must pass through two independent timelocks totaling 54 hours of public visibility before taking effect.
- Separation of concerns. The three governance entities — SAFE_GOV, SAFE_GUARDIAN, and SAFE_VETO — have non-overlapping powers. No single key or Safe can both change parameters and bypass the timelock.
Three Security Layers
Layer 1 — Governance (SAFE_GOV, 3/5 multisig + Timelock)
All protocol upgrades and parameter changes flow through the ROOT_TIMELOCK (an OpenZeppelin TimelockController with a 48-hour minimum delay). Only SAFE_GOV (a 3-of-5 Gnosis Safe) can schedule and execute transactions on the timelock.
Vault-specific parameters are additionally protected by an internal paramMinDelay of 6 hours — bringing the total effective delay to 54 hours.
Layer 2 — Guardian (SAFE_GUARDIAN, 1/1 — emergency response)
The Guardian can act immediately, without waiting for the timelock, but its powers are strictly limited to protective actions:
guardianPause()— halts deposits and withdrawals. Subject to a 7-day cooldown.setStrategyState(DEGRADED | BROKEN)— marks a strategy as unhealthy.- Backup harvest and rebalance — ensures yield continues to flow even if the normal keeper is offline.
The Guardian cannot restore a paused vault or a degraded strategy to normal operation. Only the ROOT_TIMELOCK can do that.
Layer 3 — Veto (SAFE_VETO, 1/1 — immediate cancellation)
SAFE_VETO holds the CANCELLER_ROLE on the ROOT_TIMELOCK. It can cancel any pending scheduled transaction at any time, with no delay.
Governance Flow
┌─────────────────────────────────────────────────────────────────┐
│ NORMAL GOVERNANCE │
│ │
│ SAFE_GOV (3/5) │
│ │ │
│ ▼ │
│ schedule() ──► ROOT_TIMELOCK ──[48 h]──► Target contract │
│ ▲ │
│ │ │
│ SAFE_VETO (1/1) ─── cancel() (immediate veto) │
│ │
├─────────────────────────────────────────────────────────────────┤
│ EMERGENCY PATH │
│ │
│ SAFE_GUARDIAN (1/1) │
│ │ │
│ ▼ │
│ guardianPause() ──► CoreVault (immediate, no timelock) │
│ setStrategyState() ──► Strategy (immediate, no timelock) │
│ │
└─────────────────────────────────────── ──────────────────────────┘
Key Invariants
- FeeCollector.governor is IMMUTABLE — set once at deployment, cannot be reassigned.
- Guardian cannot restore OK state — only ROOT_TIMELOCK can restore normal operation.
- Timelock is self-administered — admin role renounced to
address(0). - Double timelock on vault parameters — even if ROOT_TIMELOCK were compromised, an additional 6h delay applies per parameter change.
Sealable Core
CoreVault is designed so that, once the protocol reaches maturity, governance can renounce its own upgrade capabilities, rendering the core contracts immutable.
Live Addresses (Arbitrum)
| Contract | Address |
|---|---|
| ROOT_TIMELOCK | 0x295CFB45012b5f40814C4b74b50F871D3f072798 |
| SAFE_GOV | 0x70ef444799D6FBbE0865bA598Bee6795e064a326 |
| SAFE_GUARDIAN | 0x7407E68a5553E948eed862f19fc6B292eb48d677 |
| SAFE_VETO | 0xF0c1A33d6741EB2dc174a0977095587a0648f1D7 |
Document version: 1.0 Last updated: 2026-04-10