Rebalancing
In Multyr, rebalancing is the process by which capital is redistributed across eligible targets according to predefined rules, parameters, and constraints encoded in smart contracts.
Rebalancing can occur at different layers of the system:
- At the allocation layer, where capital may be distributed across Strategy Vaults
- At the strategy layer, where an individual strategy may redistribute capital across its own adapters or protocol integrations
In the current deployment, the active single-strategy USDC Lending vault rebalances internally across multiple lending adapters connected to distinct protocols.
Rebalancing is not continuous and is not discretionary. It is executed through controlled batch operations subject to guardrails, health checks, cooldowns, and post-execution validation.
Scope of Rebalancing
Rebalancing determines how capital is redistributed when the current allocation no longer matches the intended allocation framework.
Depending on the active layer, this may involve:
- Routing capital between Strategy Vaults
- Shifting capital between adapters inside a single strategy
- Recalling capital from one target and deploying it to another
- Maintaining buffer requirements needed for withdrawals and operations
Rebalancing should therefore be understood as a capital redistribution process, not as discretionary portfolio management.
Current Deployment Context
In the current deployment:
- The system operates with a single active strategy vault
- That strategy is the USDC Lending strategy
- The strategy is connected to multiple lending adapters
- Capital may be redistributed internally between these adapters
This means that, even in a single-strategy deployment, rebalancing remains relevant because allocation still occurs within the strategy itself.
How Rebalancing Is Executed
Rebalancing is executed through the StrategyRouter, which coordinates capital movement across active targets.
The StrategyRouter is responsible for:
- Determining how much capital should be deployed or recalled in a batch
- Executing deposits into eligible targets
- Executing withdrawals from eligible targets
- Enforcing allocation constraints and operational guardrails
- Validating post-execution conditions such as NAV stability
The router does not act independently. It operates under predefined configuration, access control, and system parameters.
Allocation Modes
The StrategyRouter supports different allocation modes.
Priority Mode
In PRIORITY mode:
- Deposits are routed first to the target with the highest priority
- Redemptions drain capital starting from the lowest-priority target
A lower priority value means higher priority.
This mode is useful when the system should prefer a primary target first and only use others when capacity or constraints require it.
Weighted Mode
In WEIGHTED mode:
- Deposits are split according to configured weights
- Redemptions are drawn proportionally to current asset distribution
This mode is useful when capital should be distributed across multiple targets according to a predefined allocation profile.
None Mode
In NONE mode:
- No automatic allocation is applied
This disables automatic routing behavior at the router level.
Rebalancing Flow
At a high level, rebalancing follows three stages:
1. Pre-execution validation
Before any capital is moved, the system validates that the batch is allowed. Checks include:
- Cooldown requirements
- Batch size limits
- Adapter allowlist checks
- Oracle freshness checks
- Plan size and available surplus checks
If these checks fail, the batch does not proceed.
2. Batch execution
If validation passes, the router executes the batch on a best-effort basis. Depending on the operation, this may involve:
- Depositing capital into selected targets
- Withdrawing capital from selected targets
- Skipping targets that fail health checks
- Skipping targets that fail execution
A failed target does not necessarily cause the entire batch to fail immediately. This design improves operational resilience by allowing the system to continue processing valid actions when one target is unavailable or unhealthy.
3. Post-execution validation
After execution, the system validates that the batch remains within acceptable bounds. Post-execution checks include:
- NAV delta limits
- Aggregated loss caps on redeem batches
- Per-target loss caps where configured
If these bounds are violated, the batch reverts.
This means that rebalancing is not only constrained before execution, but also validated after execution.
Guardrails
Rebalancing is protected by a layered guardrail stack. These guardrails constrain how capital can move and under what conditions a batch is valid.
Cooldown
A minimum cooldown applies between rebalance batches. This prevents capital from being moved too frequently and limits unnecessary churn.
Batch Size Limits
A maximum number of actions may be executed per batch. This limits operational complexity and constrains the scope of oversized batch operations.
Adapter Allowlist
Only approved targets may be used in a rebalance batch. This prevents routing capital to unauthorized or unapproved integrations.
Oracle Freshness Checks
Oracle inputs are validated before execution. These checks may include:
- Feed freshness
- Valid timestamps
- Maximum staleness
- Non-zero pricing
- Acceptable deviation between oracle sources when configured
If pricing data is invalid or stale beyond allowed thresholds, the batch does not proceed.
NAV Delta Limits
After execution, the system verifies that NAV has not changed beyond a configured threshold. This acts as a final sanity check on batch behavior. If NAV changes excessively during execution, the batch reverts.
Loss Caps
Redeem batches may be constrained by:
- A global loss cap
- A per-target loss cap
These caps limit the amount of tolerated shortfall during withdrawals. If realized loss exceeds the configured threshold, the operation reverts.
Health Checks
Targets may be checked for health before receiving additional capital. If a target is unhealthy, it may be skipped during deposits or treated differently during rebalancing. This prevents new capital from being routed into degraded targets.
Best-Effort Execution
Rebalancing is designed as a best-effort process within bounded limits.
This means:
- Individual targets may fail
- Unhealthy targets may be skipped
- Successful actions may still continue within the same batch
However, best-effort execution does not override critical safety checks. If post-execution conditions such as NAV delta or configured loss caps are violated, the batch reverts.
This balances operational flexibility with final state validation.
Buffer Interaction
Rebalancing does not operate in isolation from withdrawal and liquidity management.
The system may maintain buffer targets to ensure:
- Immediate or near-immediate withdrawal capacity
- Operational headroom
- More efficient capital movement
As a result, rebalancing is influenced not only by allocation parameters, but also by the need to maintain sufficient liquid reserves. Not all capital is necessarily deployed at all times.
Failure Handling
Rebalancing distinguishes between recoverable failures and critical failures.
| Type | Examples | Behavior |
|---|---|---|
| Recoverable | Target fails to accept a deposit; target unhealthy for new capital; target skipped during execution | Batch may continue processing remaining actions |
| Critical | Excessive NAV delta; loss beyond configured caps; invalid oracle conditions; unauthorized or oversized batch | Batch reverts entirely |
Special Paths
The system may include special execution paths for recovery or forced withdrawal scenarios. These paths are intended for exceptional conditions and may bypass some of the standard rebalancing checks.
Examples may include:
- Emergency batch redemptions
- Forced redemption to satisfy withdrawals
- Strategy-level drains under owner or governance control
These paths exist to improve recoverability, but should be understood as exceptional mechanisms rather than normal rebalance behavior.
Operational Trade-offs
Rebalancing introduces trade-offs that users should understand.
| Responsiveness vs Stability | More frequent rebalancing may react faster to changing conditions, but can increase churn and execution risk |
| Optimization vs Cost | Moving capital may improve allocation, but incurs gas costs and potential slippage |
| Liquidity vs Deployment | Maintaining buffers improves withdrawal readiness, but limits fully deployed capital |
| Flexibility vs Complexity | Multi-layer allocation enables more precise routing, but increases system complexity |
These trade-offs are managed through parameterization and guardrails, not eliminated.
Rebalancing in Multyr should not be understood as discretionary decision-making.
Capital movement follows predefined rules, configured parameters, eligibility checks, and safety constraints encoded in smart contracts.
Governance may configure parameters, but does not manually manage day-to-day capital routing through discretionary actions.
Current Status
Multyr is currently deployed on mainnet with limited functionality and is undergoing controlled validation.
As a result:
- Rebalancing behavior is being validated in live conditions
- Not all future allocation layers may be active yet
- Parameters may evolve as the system is hardened
Users should take this into account when evaluating how the system behaves over time.