Vault Mechanics
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 section describes how capital is represented, accounted for, and moves within the Multyr system.
Core Model
Multyr vaults follow the ERC-4626 standard.
Users deposit assets into a vault and receive shares representing a proportional claim on total vault assets.
Shares and NAV
Vault shares represent ownership of the vault.
- shares are minted on deposit
- shares are burned on withdrawal
- the value of shares is determined by the vault's net asset value (NAV)
Share Value
position value = shares × share price
Where:
- shares = user's balance
- share price = total assets / total shares
Capital Flow
Capital moves through multiple layers within the system.
1. Deposit
- assets are transferred to the CoreVault
- shares are minted
- capital is initially held in buffers
Deposits are subject to a lock period during which newly deposited capital cannot be withdrawn.
2. Buffer Layer
Capital may be held in buffers before deployment:
- hot liquidity → immediately available
- warm liquidity → near-liquid positions
Buffers are used to:
- satisfy withdrawals
- smooth allocation
- reduce unnecessary strategy interaction
3. Strategy Allocation (Layer 1)
Capital is deployed from the CoreVault to strategies.
Rebalancing (Layer 1)
Allocation across strategies is governed by a constrained policy framework.
Rebalancing is driven by:
- score-based target allocation
- benefit vs cost gating
- hysteresis
- minimum move constraints
- bounded rebalance budgets
- confidence-adjusted execution
As a result:
- rebalancing is discrete, not continuous
- short-term noise does not trigger reallocations
- unnecessary capital movement is avoided
- execution costs are explicitly considered
4. Strategy Layer (Layer 2)
Within each strategy, capital may be allocated across multiple underlying protocols.
Internal Rebalancing (Layer 2)
Strategies may rebalance internally:
- across multiple adapters or protocols
- between underlying markets
- based on predefined parameters
Constraints
Internal rebalancing is constrained by:
- allocation limits
- liquidity conditions
- execution costs
- risk thresholds
Execution Behavior
- strategies do not continuously chase yield
- allocation changes are discrete
- small fluctuations do not trigger reallocation
- behavior is rule-based, not discretionary
5. Withdrawal
When a withdrawal is requested:
- shares are submitted for redemption
- capital is sourced from buffers and strategies
- assets are returned depending on liquidity conditions
Withdrawals may require:
- available buffer liquidity
- recalling capital from strategies
- queue-based execution
The system does not guarantee synchronous or instant exits. When instant liquidity is insufficient, requests fall back to the queue and are settled progressively.
Withdrawals are never permanently blocked.
Advanced Mechanics
Net Asset Value (NAV)
NAV represents the total value of all assets in the system, including:
- CoreVault balances
- buffer liquidity
- strategy positions
NAV changes over time due to:
- strategy performance
- fees
- market conditions
NAV Calculation
NAV is derived from aggregated underlying positions.
Depending on system configuration:
- pricing may rely on oracles
- some values may use last known data
- updates may not be continuous
NAV may temporarily diverge from realizable value.
Liquidity Realization
Not all NAV is immediately withdrawable.
Capital may be:
- deployed in strategies with exit latency
- subject to market liquidity constraints
- dependent on external protocol conditions
As a result, realizable liquidity may differ from reported NAV.
Buffer Behavior
The system maintains liquidity buffers to support withdrawals.
Buffer levels:
- are defined as a percentage of total assets
- may change over time
Low buffer levels may lead to:
- withdrawal delays
- increased reliance on strategy exits
Time Considerations
System behavior is time-dependent:
- deposits are not always immediately allocated
- rebalancing occurs in discrete intervals
- withdrawals may take time to execute
Execution timing depends on system state and external conditions.
Constraints and Guardrails
All capital movement is constrained by system rules, including:
- allocation caps
- liquidity limits
- oracle validation
- loss caps
- cooldown periods
These constraints define how capital can move within the system.
Edge Cases and Limitations
Failure Scenarios
In adverse conditions:
- strategy losses are reflected in NAV
- capital may be partially unrecoverable
- withdrawal timing may increase significantly
The system does not guarantee full capital recovery.
System Trade-offs
The system prioritizes:
- cost efficiency over constant reactivity
- stability over short-term optimization
- controlled liquidity over immediate access
As a result:
- not all yield opportunities are captured
- allocation changes may be delayed
- liquidity may not always be immediate
Key Properties
- non-custodial — ownership represented by shares
- rule-based — no discretionary decisions
- liquidity-aware — withdrawals depend on available liquidity
- state-dependent — behavior varies over time
Important Considerations
- share value may fluctuate
- capital is not always immediately liquid
- allocation and withdrawal depend on system state
- underlying strategies introduce external risk
Multyr does not guarantee returns or capital preservation.