Testing Deep Dive
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 provides a detailed overview of the testing framework and validation coverage.
Test Metrics
| Metric | Value |
|---|---|
| Test files | 289 |
| Test functions | 3,500+ |
| Invariant suites | 9 |
| Invariant functions | 50+ |
| Fuzz test files | 7 |
| Adversarial test suites | 3 |
| Chaos simulations | 1 (multi-phase) |
| Stress test suites | 3 |
| Fork validation domains | 14 |
Invariant Testing
Stateful invariant testing validates that critical properties always hold.
Core Invariants
- solvency:
totalAssets > 0 if totalSupply > 0 - value conservation:
assets = deposits + yield − loss − withdrawals - share-price consistency within bounded tolerance
- fee bounds enforced across all paths
- queue accounting integrity
These invariants are tested across large randomized sequences (up to 10,000 runs).
Queue & Settlement Invariants
- no double settlement
- no double cancellation
- ownership enforcement on claims
- escrowed shares consistency
Adversarial Invariants
Testing includes extreme scenarios without artificial bounds:
- large deposit ranges (1K–100M)
- high yield volatility
- extreme loss conditions
The system maintains bounded behavior under stress.
Fuzz Testing
Fuzz tests validate:
- deposit and withdrawal correctness
- fee invariants
- adapter round-trip consistency
- strategy allocation constraints
Adversarial Testing
Attack vectors tested include:
- reentrancy (single and cross-function)
- read-only reentrancy
- gas griefing
- denial-of-service patterns
The system maintains:
- invariant preservation
- bounded gas usage
- consistent pricing behavior
Chaos Simulation
A multi-phase simulation validates system resilience:
- normal operation + oracle degradation
- adapter failure scenarios
- guardian intervention cycles
- faulty adapter injection
- compound failures
- recovery validation
The system is verified to:
- avoid permanent failure states
- remain recoverable via governance
Stress Testing
Stress scenarios include:
- high TVL simulations (hundreds of millions)
- multi-user environments
- queue saturation
- epoch rollover conditions
All critical operations remain within gas bounds.
Fork Validation
Validation across multiple domains ensures:
- integration correctness
- cross-module consistency
- real-world execution behavior
Summary
The testing framework verifies:
- correctness under normal operation
- resilience under adversarial conditions
- bounded behavior under stress
- recoverability after failure
This level of testing significantly reduces the probability of critical system failure.