Skip to content

Testing Scenarios

🧪 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 rather than 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
  • Verify interest accrual, share accounting, and state updates
  • Establish a baseline for later comparison

Suggested Actions

  • 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, not speed or returns.

2. Risk Boundary Scenarios

These scenarios test system behavior as positions approach protocol-defined risk limits.

Goals

  • Validate risk parameter enforcement
  • Observe how near-liquidation states are handled
  • Ensure risk signals remain clear and consistent

Suggested Actions

  • Increase borrow size until approaching liquidation thresholds
  • Observe health factor / risk indicators
  • 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

Suggested Actions

  • Observe position behavior after parameter updates (e.g. LTV or liquidation thresholds)
  • Simulate price movements where applicable
  • Track interest rate changes over time and their effect on positions

Focus on whether state transitions remain 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 resolution

Suggested Actions

  • 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

Suggested Actions

  • Execute rapid sequences of supply / borrow / repay actions
  • Test extreme but valid parameter combinations
  • Interact repeatedly across multiple positions or assets

The goal is not reckless system breaking, but identifying where assumptions stop holding.

6. Reset & Recovery Scenarios

These scenarios validate behavior across testnet resets and redeployments.

Goals

  • Ensure resets are clean and well-contained
  • Validate user understanding of non-persistent state

Suggested Actions

  • Observe system behavior before and after testnet resets
  • Confirm that positions and balances do not persist unexpectedly
  • Verify that UI and contract states realign after redeployment

Clarity around resets is as important as technical correctness.

📋 Reporting Feedback

When reporting issues, please include:

  • Scenario category
  • Steps taken (high-level)
  • Expected vs. observed behavior
  • Relevant transaction hashes or timestamps

Clear and concise 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
  • which behaviors may change in upcoming deployments