Strategy & Allocation Logic
Multyr implements a rule-based, multi-layer allocation system designed to structure how capital is distributed across DeFi opportunities.
The system does not rely on discretionary decision-making. Instead, allocation behavior is determined by predefined rules, parameters, and constraints encoded in smart contracts.
Allocation as a System
In Multyr, allocation is not a single decision.
It occurs across multiple layers:
- the Allocation Vault layer, which distributes capital across strategies
- the Strategy layer, where each strategy allocates capital across its own adapters or protocol integrations
Each layer applies its own logic within defined boundaries.
Objective
The system is designed to improve how capital is deployed over time.
This includes:
- adapting to changing yield conditions
- managing exposure across multiple targets
- maintaining constraints related to liquidity and risk
The objective is not to maximize yield in all conditions, but to structure capital allocation under changing market conditions.
Allocation Inputs
Allocation decisions are based on a set of predefined inputs.
These may include:
- target weights or priorities
- available liquidity
- protocol or adapter limits
- yield conditions
- strategy-specific parameters
- buffer requirements
- execution thresholds
Inputs may differ between the Allocation Vault and individual strategies.
Allocation Constraints
All allocation behavior operates within strict constraints.
These may include:
| Constraint | Description |
|---|---|
| Exposure limits | Caps on capital allocated to a strategy or protocol |
| Liquidity constraints | Allocation sized to available market depth |
| Buffer requirements | Maintenance of liquid reserves for withdrawals |
| Execution thresholds | Minimum conditions required before capital is moved |
| Strategy parameters | Rules specific to each strategy |
Constraints define the boundaries of the system, not optional guidelines.
Strategy Selection & Eligibility
At the allocation layer, capital is routed only to eligible strategies.
A strategy is considered eligible only if it satisfies predefined conditions, which may include:
- being enabled
- not being in a degraded or restricted state
- being able to accept new deposits
- having available capacity
- passing relevant system guardrails
Strategies that do not meet these conditions are excluded from allocation.
In particular, strategies marked as degraded or unhealthy are prevented from receiving new capital.
Allocation Behavior Across Strategies
The system adapts its allocation behavior based on the number of eligible strategies:
-
No eligible strategies → no allocation is performed
-
One eligible strategy → capital is routed entirely to that strategy
-
Multiple eligible strategies → capital is distributed across strategies based on a structured evaluation process
Scoring-Based Allocation
When multiple strategies are eligible, allocation is determined through a multi-factor scoring framework.
This framework evaluates each strategy based on factors such as:
- yield conditions
- risk characteristics
- available liquidity
- stability of returns
- remaining capacity
These factors are combined to determine relative allocation targets.
The objective is not to select a single "best" strategy, but to distribute capital across multiple opportunities while respecting system constraints.
Constraints and Final Allocation
After initial allocation targets are determined, the system applies additional constraints, including:
- maximum exposure per strategy
- liquidity limitations
- allocation caps
- safety and risk parameters
If necessary, allocations are adjusted to remain within these constraints.
Strategies that fail checks or exceed limits are excluded or reduced.
Strategy Design
Each strategy represents a controlled allocation framework.
A strategy may:
- allocate capital across multiple adapters
- redistribute capital internally over time
- apply its own parameters and limits
For example, a lending strategy may distribute capital across multiple protocols rather than relying on a single integration.
Rebalancing Behavior
Allocation is not static.
Capital distribution may change over time through rebalancing.
Rebalancing:
- is triggered by predefined conditions
- operates under constraints and guardrails
- is executed in controlled batches
- is subject to execution costs and trade-offs
Rebalancing does not occur continuously and does not guarantee improved outcomes in all cases.
Multi-Layer Interaction
The interaction between layers is hierarchical:
- the Allocation Vault determines exposure across strategies
- each Strategy determines exposure across its own adapters
This results in a system where capital may be reallocated:
- across strategies
- within strategies
- across underlying protocols
Each layer operates independently within its defined scope.
Trade-offs
The system introduces several trade-offs:
| Trade-off | Description |
|---|---|
| Responsiveness vs Stability | Faster adjustments may increase churn and execution risk |
| Optimization vs Cost | Capital movement may improve allocation but incurs gas and slippage |
| Liquidity vs Deployment | Maintaining buffers reduces fully deployed capital |
| Flexibility vs Complexity | Multi-layer allocation increases precision but adds complexity |
These trade-offs are managed through parameters and constraints.
Governance and Parameters
Allocation parameters, including those influencing strategy selection and weighting, are controlled through governance.
These parameters may evolve over time as the system is validated and improved.
However, allocation remains rule-based and deterministic, and does not rely on discretionary decision-making.
Important Clarification
Multyr does not make discretionary investment decisions.
All allocation behavior follows predefined logic encoded in smart contracts.
Governance may configure parameters, but day-to-day allocation behavior is governed by predefined logic encoded in smart contracts.
Current Status
Multyr is currently deployed on mainnet with limited functionality and is undergoing controlled validation.
As a result:
- not all allocation layers may be fully active
- parameters may evolve over time
- system behavior is still being validated