Testing Scenarios¶
This section outlines the core testing scenarios designed to validate Moosh's protocol behavior, risk controls, and system coherence under different conditions.
Each scenario focuses on system response, not outcome optimization. Testers are encouraged to observe parameter changes, state transitions, and liquidation behavior rather than maximizing yield or position size.
1. Baseline Usage Scenarios¶
These scenarios validate expected behavior under normal conditions.
Goals¶
- Confirm basic supply and borrow flows work as intended
- Verify interest accrual, share accounting, and state updates
- Establish a baseline for later comparison
Scenarios¶
- Supply a supported asset and observe share minting and balance changes
- Borrow against collateral within safe risk limits
- Repay borrowed assets and withdraw supplied collateral
- Observe interest accumulation over time
Focus on correctness and consistency rather than speed or returns.
2. Risk Boundary Scenarios¶
These scenarios test behavior as positions approach protocol-defined risk limits.
Goals¶
- Validate risk parameter enforcement
- Observe how close-to-liquidation states are handled
- Ensure signals are clear and consistent
Scenarios¶
- Increase borrow size until approaching liquidation thresholds
- Observe health factor / risk indicators as parameters change
- Modify collateral ratios through additional borrowing or withdrawal
- Track system response as safety margins narrow
Pay attention to whether risk signals remain interpretable and timely.
3. Market Movement & Parameter Change Scenarios¶
These scenarios examine protocol behavior under changing market or system conditions.
Goals¶
- Test resilience to parameter updates and simulated market shifts
- Validate system coherence under dynamic conditions
Scenarios¶
- Observe position behavior after parameter updates (e.g. LTV, liquidation thresholds)
- Simulate price movements where applicable and monitor system response
- Track interest rate changes over time and their effect on positions
Focus on whether transitions are predictable and rule-driven.
4. Liquidation Scenarios¶
These scenarios validate liquidation logic and failure containment.
Goals¶
- Ensure liquidations trigger correctly and deterministically
- Validate accounting correctness during forced position resolution
Scenarios¶
- Push positions into liquidation through over-borrowing or adverse price movement
- Observe liquidation execution, penalties, and residual balances
- Verify system state after liquidation completes
Unexpected partial states, unclear outcomes, or inconsistent balances should be reported.
5. Stress & Edge Case Scenarios¶
These scenarios explore behavior outside typical usage patterns.
Goals¶
- Identify brittle assumptions
- Surface unexpected interactions or failure modes
Scenarios¶
- Rapid sequences of supply / borrow / repay actions
- Extreme but valid parameter combinations
- Repeated interactions across multiple positions or assets
The goal is not to "break" the system recklessly, but to discover where assumptions stop holding.
6. Reset & Recovery Scenarios¶
These scenarios validate behavior across testnet resets and redeployments.
Goals¶
- Ensure system resets are clean and well-contained
- Validate user understanding of non-persistent state
Scenarios¶
- Observe system behavior before and after testnet resets
- Verify that previous positions and balances do not persist unexpectedly
- Confirm UI and contract states realign after redeployment
Clarity around resets is as important as technical correctness.
Reporting Feedback¶
When reporting issues, include:
- Scenario category
- Steps taken (high-level)
- Expected vs observed behavior
- Relevant transaction hashes or timestamps
Clear, minimal reports are more valuable than exhaustive logs.
What's Next¶
Refer to Testnet Roadmap to understand which scenarios are stable, which are under active iteration, and which behaviors may change in upcoming deployments.