Skip to main content

Contracts & Modules

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 built as a modular system composed of independent contracts with clearly defined responsibilities.

This architecture enables:

  • composability
  • upgrade flexibility (where permitted)
  • isolation of risk

Architecture Overview​

Multyr separates execution into:

  • CoreVault (dispatcher + storage)
  • delegatecall modules (execution logic)
  • external components (isolated systems)

This results in a layered and controlled execution model.

CoreVault (ERC-4626)​

The CoreVault is the primary entry point for all user interactions.

Responsibilities:

  • deposits and withdrawals
  • share accounting
  • total asset tracking
  • routing execution to modules

The CoreVault itself contains minimal logic and acts as a dispatcher.

CoreVault Architecture (Diamond-like)​

Multyr uses a diamond-like modular execution architecture centered around the CoreVault.

Unlike a traditional monolithic contract, execution logic is split across modules and routed dynamically.

Central Dispatcher​

The CoreVault acts as a thin execution layer:

  • no economic logic is implemented directly
  • all non-standard calls are routed via fallback()
  • execution is delegated to modules via delegatecall

Flow:

user call → CoreVault
          → fallback()
          → module lookup (selector → module)
          → role validation
          → delegatecall(module)

Standard ERC-4626 functions (deposit, mint, withdraw, redeem) are explicitly implemented to avoid unintended fallback routing.

Module System​

Execution logic is split into delegatecall modules:

ModuleResponsibility
AdminModulegovernance, fee timelock, sealing
ERC4626Moduledeposits, mint, force withdraw
QueueModuleasync withdrawals, claims
LiquidityOpsModuledeployment and rebalancing

These modules:

  • execute in CoreVault storage
  • do not hold independent state
  • are tightly access-controlled

External Components​

Certain components are not delegatecall modules, but separate contracts:

  • BufferManager
  • StrategyRouter
  • IncentivesEngine
  • FeeCollector

These components:

  • are called externally
  • maintain their own storage
  • can evolve independently via governance

Storage Model (EIP-7201)​

All state is stored in the CoreVault using namespaced storage slots.

This prevents storage collisions across modules using delegatecall.

Examples:

  • CoreStorage

    • ownership
    • selector routing (moduleOf)
    • role mapping (roleOf)
    • packed system flags

  • FeeStorage

    • fee configuration
    • pending timelocks
    • high-water mark (HWM)

  • QueueStorage

    • withdrawal queue
    • claim tracking
    • pending shares

Storage layouts are strictly defined and shared across modules.

Selector Registry (Immutable Guardrail)​

Selector routing is enforced through an immutable registry.

Properties:

  • each function selector has a predefined required role
  • role mapping is fixed at compile-time
  • module assignment is validated against this mapping

This ensures:

  • no privilege escalation
  • no incorrect selector routing
  • no runtime ambiguity

Unknown or invalid selectors are rejected.

Execution Guarantees​

The system enforces:

  • role-based access before execution
  • deterministic selector → module mapping
  • strict module authorization

This provides strong guarantees on execution correctness.

Strategy-Level Architecture​

Strategies follow a similar modular pattern:

  • logic split across multiple modules
  • shared storage layout across modules
  • delegatecall-based execution

This approach is required due to EVM size limits (EIP-170) and improves modularity.

Execution Model​

The protocol operates through three types of actions:

User Actions​

  • deposit
  • withdraw
  • redeem

Keeper Actions​

  • rebalance
  • harvest
  • buffer management

Governance Actions​

  • parameter updates
  • module configuration
  • system sealing

Upgrade Model​

Multyr follows a controlled, progressive upgrade model.

Phase 1 — Hot Updates​

  • modules can be updated immediately
  • no timelock enforced
  • used during early deployment phases

Phase 2 — Timelocked Updates​

  • changes require delay
  • submitted and later accepted
  • revocable before execution

Applies to:

  • fee parameters
  • external components

Phase 3 — Final Seal​

  • system becomes immutable
  • no further upgrades allowed
  • enforced on-chain

Differences vs Standard Diamond (EIP-2535)​

Multyr does not implement a full diamond standard.

Key differences:

  • no diamondCut
  • no runtime facet introspection
  • no dynamic selector remapping

Instead, Multyr uses:

  • static selector registry
  • controlled module assignment
  • irreversible sealing

Design Rationale​

This architecture balances:

  • modularity
  • safety
  • predictability

It avoids the risks of fully dynamic upgrade systems while preserving flexibility during early stages.

Integration Notes​

Developers should:

  • treat CoreVault as the primary entry point
  • avoid interacting directly with internal modules
  • rely on standard ERC-4626 interfaces

Internal complexity is abstracted and does not affect integration flow.

Summary​

Multyr's architecture is:

  • modular
  • delegatecall-based
  • storage-safe
  • governance-controlled

Designed to provide:

→ flexible development phase → strong safety guarantees → predictable production behavior