BME Testnet Test Plan

Overview

This test plan validates BME functionality through real user workflows on testnet. Tests are triggered by user actions (creating deployments, closing deployments, funding wallets) rather than direct message invocation. BME mechanics are verified by observing state changes after user actions complete.

Tester Requirements

The following are your responsibility to set up before testing:

Akash CLI (`akash`)

Required Version: v2.1.0-a17

⚠️ IMPORTANT: The standard CLI installation guide installs the mainnet binary by default. For testnet, you must install the specific testnet version.

Download the correct testnet binary directly from: https://github.com/akash-network/node/releases/tag/v2.1.0-a17

Installation Notes:

Homebrew will NOT work for testnet installation — it installs mainnet binaries only
Follow the manual installation steps from the CLI Installation Guide, but substitute the binary from the testnet release link above
After installation, verify your version:
Terminal window
```
akash version
# Expected output: 2.1.0-a17
```

Provider Services (`provider-services`)

Required Version: v0.10.5

Download from: https://github.com/akash-network/provider/releases/tag/v0.10.5

This binary is required for sending manifests to providers.

provider-services version
# Expected output: v0.10.5

Environment Configuration

Ensure your environment variables are set correctly:

export AKASH_CHAIN_ID=testnet-8
export AKASH_NODE=https://testnetrpc.akashnet.net:443

Verify:

echo $AKASH_CHAIN_ID
# Expected output: testnet-8

echo $AKASH_NODE
# Expected output: https://testnetrpc.akashnet.net:443

MTLS Certificates

MTLS certificates are required for sending manifests to providers.

Follow the certificate setup guide: https://akash.network/docs/developers/deployment/cli/installation-guide/#mtls-certificate-authentication-optional

Funded Test Wallet

Use the testnet faucet to fund your wallet with 500 AKT per request: https://faucet.dev.akash.pub

Network Prerequisites

These are managed by the Akash Core team:

Healthy testnet-8 network running with BME module enabled
Oracle module configured with price feeds
Provider(s) running on testnet to accept deployments
Ability to manipulate oracle prices for circuit breaker testing (Akash Core team only)

Note: All prerequisites are validated in Category 0 pre-flight checks.

Key Metrics to Monitor

These should be queried before and after each test:

Metric	Query Method	Description
`OutstandingACT`	`akash query bme vault-state`	Total ACT supply (system liabilities)
`VaultAKT`	`akash query bme vault-state`	AKT held in BME module account
`RemintCredits`	`akash query bme vault-state`	Available AKT credits before new minting required
`TotalBurned`	`akash query bme vault-state`	Cumulative ACT burned
`TotalMinted`	`akash query bme vault-state`	Cumulative AKT minted (inflationary)
`collateral_ratio`	`akash query bme status`	Collateral Ratio (decimal, e.g., 0.99)
`status`	`akash query bme status`	Current status (mint_status_healthy/warning/halt_cr/halt_oracle)
User AKT Balance	`akash query bank balances <addr>`	User’s AKT and ACT
Oracle Price	`akash query oracle prices \| head -n 15`	Current AKT/USD price

Test Categories

Category 0: Pre-Flight Health Checks

Verify BME module and dependencies are healthy before testing. Run these first!

Node connectivity
BME module enabled
Oracle health
Vault state baseline
Collateral ratio and mint status
Test wallet setup
Provider availability

Category 1: Deployment Creation

Test AKT → ACT conversion through deployment lifecycle.

ACT minting and standard deployment
Insufficient funds handling
Minimum deposit testing
Multiple deployments from single wallet

Category 2: Deployment Closure & Refunds

Test ACT → AKT conversion on deployment close.

Close deployment - ACT returned
Burn ACT to AKT (basic)
Price movement scenarios

Category 3: Provider Settlement

Verify providers receive ACT from deployment payments.

Provider receives ACT from settlement
Lease price matches SDL pricing
Provider payment verification on close

Category 4: Epoch-Based Processing

Test epoch-based mint/burn processing.

Verify request queuing
Multiple queued requests

Category 5: Direct Message Operations

Test direct mint/burn commands (MsgMintACT, MsgBurnACT, MsgBurnMint).

Direct AKT → ACT conversion
Direct ACT → AKT conversion
Generic swap operations
Input validation
Consecutive operations

Category 6: Circuit Breaker HALT State

⚠️ Requires 24-hour CB Halt Testing Window - Tests BME behavior when CR < 90% (halt state).

Verify halt state active (status: mint_status_halt_cr)
Verify mints BLOCKED during halt
Verify burns still work (users can exit positions)
Verify deployment closure works during halt
Verify existing deployments continue running

Category 7: Circuit Breaker WARNING State

⚠️ Requires 24-hour CB Warning Testing Window - Tests BME behavior when 90% ≤ CR < 95% (warning state).

Verify warning state active (status: mint_status_warning)
Verify mints WORK during warning (still allowed)
Verify burns work
Verify deployment creation works during warning

Category 8: Event Emissions & Observability

Verify BME event emissions during operations.

Event emission - MintACT
Event emission - BurnACT
Event emission - Deployment close

Category 9: Edge Cases & Error Handling

Test boundary conditions and edge cases.

Zero amount operations
Dust amount operations
Maximum amount operations
Rapid sequential operations
SDL with uakt pricing validation

Category 10: End-to-End Scenarios

Complete user journeys combining multiple operations.

Full deployment lifecycle
Multi-user concurrent activity

Circuit Breaker State Comparison

Categories 6 and 7 test different circuit breaker states. Here’s how they differ:

State	CR Range	`mints_allowed`	`refunds_allowed`	Key Behavior
Healthy	≥ 95%	`true`	`true`	Normal operation
Warning (Cat 7)	90% - 95%	`true`	`true`	All operations work, system signaling risk
Halt (Cat 6)	< 90%	`false`	`true`	Mints blocked, burns always allowed

Key Principle: The circuit breaker is asymmetric — it protects the system by blocking new ACT creation during stress, but always allows users to exit their positions via burns.

Summary Checklist

Category	Tests	Priority	When to Run
Pre-Flight Health Checks	0.1-0.10	Critical	Run First
Deployment Creation	1.1-1.4	Critical	Anytime (healthy state)
Deployment Closure/Refunds	2.1-2.3	Critical	Anytime (healthy state)
Provider Settlement	3.1-3.3	Critical	Anytime (healthy state)
Epoch-Based Processing	4.1-4.2	High	Anytime (healthy state)
Direct Message Operations	5.1-5.11	Critical	Anytime (healthy state)
CB Halt State (CR < 90%)	6.1-6.5	Critical	⚠️ During 24hr CB Halt Window
CB Warning State (90-95%)	7.1-7.4	Critical	⚠️ During 24hr CB Warning Window
Event Emissions/Observability	8.1-8.3	Medium	Anytime (healthy state)
Edge Cases	9.1-9.5	High	Anytime (healthy state)
End-to-End	10.1-10.2	Critical	Anytime (healthy state)

Total: 52 tests across 11 categories

Circuit Breaker Testing Windows

Categories 6 and 7 require the Akash Core team to manipulate oracle prices to trigger circuit breaker states. There will be two separate 24-hour testing windows:

CB Halt Testing Window (Category 6)

The Akash Core team will announce a 24-hour window when the circuit breaker halt state is active (CR < 90%).

During this window:

BME status will show mint_status_halt_cr
mints_allowed: false
Complete all Category 6 tests

Preparation before the window:

Mint ACT before the window starts (you’ll need ACT for burn tests — mints are blocked during halt)
Create deployments before the window (for closure tests during halt)

Monitor status:

akash query bme status
# Look for: status: mint_status_halt_cr

CB Warning Testing Window (Category 7)

The Akash Core team will announce a separate 24-hour window when the circuit breaker warning state is active (90% ≤ CR < 95%).