Skip to main content

Security Overview

Current Phase: Shadow Mainnet Testing

Multyr contracts are deployed on Arbitrum One. The system is currently in validation phase. Deposits are not open to the public. Behavior described on this page reflects the protocol's designed behavior; some mechanisms are active in shadow testing, others become active at public launch. See the Status page for details.

Multyr is designed around a core principle:

minimize the attack surface, then layer defenses around what remains.

Security is enforced through multiple independent layers, combining governance constraints, runtime protections, and capital safety mechanisms.

Security Architecture​

The protocol is built on three primary layers:

1. Governance Layer (Timelocked Control)​

All critical changes are controlled through:

  • SAFE_GOV (3/5 multisig)
  • ROOT_TIMELOCK (48h delay)
  • paramMinDelay (~24h internal delay, post-seal target)

→ total delay: ~72 hours

This ensures that:

  • no parameter changes are immediate
  • all actions are publicly visible before execution
  • users have time to react

2. Guardian Layer (Immediate Protection)​

The Guardian provides fast intervention in emergency situations:

  • guardianPause() — halts deposits and withdrawals
  • setStrategyState(DEGRADED | BROKEN) — isolates failing strategies

Key constraints:

  • no timelock required
  • cannot restore normal operation
  • subject to cooldown

→ easy to stop, hard to restart

3. Veto Layer (Final Safety Control)​

SAFE_VETO can:

  • cancel any pending governance transaction
  • revoke parameter updates

This ensures that:

→ no scheduled change is irreversible before execution

Defense in Depth​

Critical operations are protected by multiple independent mechanisms.

Examples include:

  • double timelock on parameter changes
  • role-based access control (RBAC) across all modules
  • reentrancy protection at module and system level
  • oracle validation with fallback and deviation checks
  • per-strategy and aggregate loss caps
  • withdrawal limits and queue constraints

No single mechanism is relied upon in isolation.

Capital Protection Mechanisms​

User funds are protected through structural constraints:

Strategy Isolation​

  • each strategy operates independently
  • failure in one strategy does not propagate
  • unhealthy strategies are automatically excluded from allocation

Loss Containment​

  • per-strategy loss caps (e.g. ~0.5%)
  • aggregate loss caps (~1%)
  • bounded exposure per strategy

Liquidity Controls​

  • withdrawal queues with epoch caps
  • instant withdrawal limits
  • buffer management (hot / warm / strategy capital)

Fail-Safe Exits​

Users retain access to funds even under stress:

  • standard withdrawals via queue
  • instant withdrawals (subject to liquidity)
  • force withdrawals available in extreme scenarios (strategy-conditional path, variable fee — not a standard user-selectable mode)

→ user exits are designed to degrade, not break

Oracle & Pricing Safety​

The system includes multiple protections against oracle-related risks:

  • staleness checks per feed
  • secondary oracle validation
  • deviation thresholds
  • NAV freshness enforcement

Deposits may be blocked if pricing data is stale or unsafe. Withdrawals are never blocked by oracle failures.

Upgrade & Immutability Model​

The protocol follows a progressive immutability path:

  1. normal governance (timelocked)
  2. routing freeze
  3. parameter freeze
  4. full system seal

At final state:

→ contracts can become immutable

Testing & Verification​

The codebase has undergone extensive automated testing:

  • 289 test files, 3,500+ test functions
  • 50+ stateful invariants, 14 fork validation domains
  • unit, integration, fuzz, invariant, fork, adversarial, chaos testing
  • shadow mainnet testing

Testing does not eliminate risk but significantly reduces the probability of critical failures. See Testing Deep Dive for the full coverage breakdown.

Audits & Bug Bounty​

  • External audits: top-tier auditor firms are being evaluated. Target engagement: end Q2 / early Q3 2026. Reports will be published at /security/audits when completed.
  • Bug bounty: scheduled concurrent with first audit report publication, Q3 2026. Hosted on Immunefi. Tier structure at launch.

For responsible disclosure during shadow testing: security@multyr.fi. See Responsible Disclosure for the full policy.

Emergency Model​

Emergency actions prioritize fund protection:

  • immediate pause capability
  • strategy-level isolation
  • forced withdrawal availability
  • governance-controlled recovery

Key Security Properties​

The system enforces several critical invariants:

  • no immediate parameter changes
  • no single entity has full control
  • user exits cannot be permanently blocked
  • fee routing is deterministic
  • core accounting remains consistent

Summary​

Multyr's security model combines:

  • governance delays
  • emergency controls
  • capital constraints
  • deterministic execution

The system is designed to:

→ fail safely rather than fail abruptly

Security in Multyr is not based on a single mechanism, but on the interaction of multiple independent safeguards.