Skip to main content

Security Model

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.

This page describes the core mechanisms that enforce security at the protocol level.

Access Control (RBAC)​

The system implements a multi-layer role model:

  • PUBLIC
  • OWNER
  • GUARDIAN
  • OWNER_OR_GUARDIAN
  • MODULE

Access is enforced before any execution through a selector-based permission system.

Only authorized modules may perform sensitive operations such as:

  • minting shares
  • burning shares
  • transferring internal balances

Reentrancy Protection​

Reentrancy is prevented through:

  • custom flag-based guards at vault level
  • module-level non-reentrant execution
  • additional guards on external interaction layers

Critical operations such as deposits, withdrawals, and queue execution are protected.

Oracle Safety​

Oracle inputs are validated through:

  • staleness checks (min / max bounds)
  • secondary oracle validation
  • deviation thresholds
  • NAV freshness requirements

Deposits may be blocked if data is stale. Withdrawals are not blocked by oracle failures.

The system enforces:

  • a single source of truth for total assets
  • smoothing mechanisms to reduce volatility
  • deterministic pricing within execution batches

This prevents manipulation of share pricing.

Strategy Safety​

Strategies are governed through:

  • health states (OK / DEGRADED / BROKEN)
  • per-strategy allocation caps
  • loss caps (per strategy and aggregate)

Unhealthy strategies are excluded from new allocation.

Liquidity & Buffer Management​

Liquidity is managed across:

  • hot buffer
  • warm buffer
  • strategies

The system enforces:

  • minimum buffer thresholds
  • rebalance constraints
  • controlled capital movement

Fee Safety​

Fees are constrained by:

  • maximum caps
  • centralized calculation logic
  • consistent rounding rules

Performance fees are applied only above high-water mark conditions.

Upgrade & Storage Safety​

The protocol uses:

  • modular architecture with delegated execution
  • namespaced storage to prevent collisions
  • immutable selector mappings

This reduces upgrade-related risks.

Mathematical Safety​

The system relies on:

  • Solidity overflow protection
  • validated percentage operations
  • consistent rounding direction

Summary​

Security at the model level is enforced through:

  • strict access control
  • validated inputs
  • bounded execution
  • deterministic accounting