Skip to content

Instantly share code, notes, and snippets.

@gosuri

gosuri/bme-testnet.md

Created February 2, 2026 22:59
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save gosuri/1dbf2ed888b28f9e978996deae766efa to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save gosuri/1dbf2ed888b28f9e978996deae766efa to your computer and use it in GitHub Desktop.
Download ZIP
Akash BME Testnet Instructions
Raw
bme-testnet.md

BME (Burn Mint Equilibrium) Module Test Plan

End-User Integration Testing - v5

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.

Prerequisites

  • Testnet deployed with BME-enabled node version (branch: bme)
  • Oracle module configured with price feeds
  • Testnet faucet available for funding test wallets
  • Akash CLI (akash or provider-services) configured for testnet
  • Console access (if testing credit card / UI flows)
  • Access to query BME state (via CLI or API)
  • Provider(s) running on testnet to accept deployments
  • Ability to manipulate oracle prices for price movement scenarios (testnet admin)
  • Ability to stop/start oracle feeds (for oracle halt testing)

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 --asset-denom uakt Current AKT/USD price

Test Category 0: Pre-Flight Health Checks

Before running functional tests, verify the BME module and dependencies are healthy. These checks establish a baseline and confirm the testnet is ready for testing.

Test 0.1: Node and Network Connectivity

Objective: Verify testnet node is accessible and synced

User Actions:

  1. Check node status: 
    akash status
  2. Verify node is synced (catching_up: false)
  3. Note current block height

Expected Results:

  • Node responds
  • catching_up: false
  • Block height advancing

Test 0.2: BME Module Enabled

Objective: Verify BME module is loaded and responding

User Actions:

  1. Query BME params: 
    akash query bme params
  2. Verify response includes expected parameters

Expected Results:

  • Query succeeds (no "unknown query path" error)
  • Returns: CircuitBreakerWarnThreshold, CircuitBreakerHaltThreshold, MinEpochBlocks, EpochBlocksBackoff

Test 0.3: Oracle Health Check

Objective: Verify oracle is providing price feeds

User Actions:

  1. Query oracle prices: 
    akash query oracle prices
  2. Filter for specific denoms if needed: 
    akash query oracle prices --asset-denom uakt
akash query oracle prices --asset-denom uact
  3. Verify prices are reasonable and recent

Expected Results:

  • AKT price returns valid USD value (e.g., ~0.45 in example)
  • ACT price returns ~$1.00 (pegged)
  • Timestamps are recent (not stale)

Test 0.4: BME Vault State Baseline

Objective: Record initial BME vault state for comparison during testing

User Actions:

  1. Query full BME vault state: 
    akash query bme vault-state
  2. Record baseline values:
    • Balances (VaultAKT)
    • TotalBurned
    • TotalMinted
    • RemintCredits

Expected Results:

  • Query succeeds
  • All fields returned (may be zero on fresh testnet)
  • Document baseline for later comparison

Test 0.5: Collateral Ratio and Status Check

Objective: Verify BME status query returns collateral ratio and system health

User Actions:

  1. Query BME status: 
    akash query bme status

Example Output:

collateral_ratio: "0.999328857700195767"
halt_threshold: "0.900000000000000000"
mints_allowed: true
refunds_allowed: true
status: mint_status_healthy
warn_threshold: "0.950000000000000000"

Expected Results:

  • collateral_ratio: Decimal value (e.g., ~0.99 means 99% collateralized)
  • status: mint_status_healthy (required to proceed with most tests)
  • mints_allowed: true
  • refunds_allowed: true
  • warn_threshold: 0.95 (status changes to warning below this)
  • halt_threshold: 0.90 (mints halt below this)

If status is NOT mint_status_healthy:

  • mint_status_warning: Collateralization Ratio dropped below 0.95 - investigate
  • mint_status_halt_cr: Collateralization Ratio dropped below 0.90 - mints blocked, investigate before proceeding
  • mint_status_halt_oracle: Oracle failure - investigate oracle health (Test 0.3)

Test 0.6: BME Params Check

Objective: Verify BME module parameters are configured

User Actions:

  1. Query BME params: 
    akash query bme params

Expected Results:

  • Query succeeds
  • Returns epoch settings, thresholds, and other BME configuration

Test 0.7: Token Supply Baseline

Objective: Record token supplies for inflation tracking

User Actions:

  1. Query total AKT supply: 
    akash query bank total --denom uakt
  2. Query total ACT supply (OutstandingACT): 
    akash query bank total --denom uact
  3. Document baseline values

Expected Results:

  • AKT supply returned (note for inflation tracking in later tests)
  • ACT supply returned (may be 0 on fresh testnet)

Test 0.8: ACT Supply Baseline

Objective: Record initial ACT supply for tracking during tests

User Actions:

  1. Query total ACT supply: 
    akash query bank total --denom uact
  2. Record the value for comparison during testing

Expected Results:

  • Query succeeds
  • Returns total ACT in circulation (may be 0 on fresh testnet)
  • Document baseline for later comparison

Note: This helps track inflationary events during testing. Compare with vault-state.total_minted.uact.

Test 0.9: Test Wallet Setup

Objective: Prepare test wallet with AKT for subsequent tests

User Actions:

  1. Create a new test wallet:

    akash keys add test-account

    Important: Save the mnemonic phrase securely

  2. Note the wallet address from output

  3. Fund from faucet (testnet faucet provides 100 AKT per request)

  4. Verify balance:

    akash query bank balances <test-wallet-address>

Expected Results:

  • Wallet created successfully
  • After faucet: balance shows 100000000uakt (100 AKT)
  • No ACT balance initially (uact not listed)

Note: Faucet provides 100 AKT per request. For tests requiring more AKT, either:

  • Request from faucet multiple times (if allowed)
  • Transfer from another funded account

Test 0.10: Provider Availability (If Testing Deployments)

Objective: Verify at least one provider is available for deployment tests

User Actions:

  1. Query active providers: 
    akash query provider list
  2. Verify at least one provider is online

Expected Results:

  • At least one provider listed
  • Provider status indicates availability
  • If no providers, deployment tests (Category 1-3) cannot proceed

Test 0.11: Market Params Check (Bid Deposit Denom)

Objective: Verify market module accepts AKT for bid deposits (not ACT)

User Actions:

  1. Query current market params via REST API (CLI not available for this query): 
    curl -s https://testnetapi.akashnet.net/akash/market/v1beta5/params | jq
  2. Check bid_min_deposit denom - should be uakt

Expected Results:

  • Response shows bid_min_deposit.denom is uakt
  • If denom is uact, providers cannot bid - requires governance fix (see below)

Example Response (problematic - needs fix):

{
  "params": {
    "bid_min_deposit": {
      "denom": "uact",   // <-- PROBLEM: should be "uakt"
      "amount": "500000"
    },
    "order_max_bids": 20
  }
}

If Fix Required - Update Market Params via Governance:

  1. Get gov module authority address:

    akash query auth module-account gov

    For BME testnet: akash10d07y265gmmuvt4z0w9aw880jnsr700jhe7z0f

  2. Create proposal JSON file (market-params-fix.json):

    cat > market-params-fix.json << 'EOF'
{
  "messages": [
    {
      "@type": "/akash.market.v1beta5.MsgUpdateParams",
      "authority": "akash10d07y265gmmuvt4z0w9aw880jnsr700jhe7z0f",
      "params": {
        "bid_min_deposit": {
          "denom": "uakt",
          "amount": "500000"
        },
        "order_max_bids": 20
      }
    }
  ],
  "metadata": "ipfs://CID",
  "deposit": "50000000uakt",
  "title": "Fix Market Params - Bid Deposit Denom",
  "summary": "Update bid_min_deposit to use uakt instead of uact. Providers must deposit in AKT, not ACT.",
  "expedited": true
}
EOF

    Important:

    • Type URL must be /akash.market.v1beta5.MsgUpdateParams (not v1)
    • Deposit must be 50000000uakt (50 AKT) to enter voting period

  3. Submit expedited proposal:

    akash tx gov submit-proposal market-params-fix.json \
  --from default \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices 0.025uakt \
  -y

  4. Get proposal ID from tx result, then vote:

    # Find proposal ID
akash query gov proposals --status voting_period

# Vote yes (as validator)
akash tx gov vote <proposal-id> yes \
  --from default \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices 0.025uakt \
  -y

  5. Monitor proposal status (expedited = ~5 min):

    # Check proposal status
akash query gov proposal <proposal-id>

# Watch for status change to PROPOSAL_STATUS_PASSED
watch -n 10 "akash query gov proposal <proposal-id> | grep status"

  6. Verify params updated after proposal passes:

    curl -s https://testnetapi.akashnet.net/akash/market/v1beta5/params | jq

    Confirm bid_min_deposit.denom is now uakt

Note: CLI akash query market params is not implemented. Use REST API for this query.

Test 0.12: ACT Minting Verification

Objective: Verify ACT can be minted from AKT and appears in wallet after epoch processing

User Actions:

  1. Check initial balance:

    akash query bank balances <user-address>

  2. Mint ACT from AKT:

    akash tx bme mint-act 100000000uakt --from <wallet> -y

  3. Check BME vault state immediately:

    akash query bme vault-state

    Note: AKT should appear in vault immediately

  4. Wait for epoch processing (~1 minute / 10 blocks):

    # Check BME status for epoch info
akash query bme status

# Wait, then check balance again
sleep 60
akash query bank balances <user-address>

Expected Results:

  • AKT transferred to vault immediately
  • After epoch: ACT appears in user's bank balance
  • ACT amount = AKT deposited × oracle price
  • vault-state shows: balances.uakt ↑, balances.uact ↑, remint_credits ↑, total_minted.uact ↑

Note: ACT minting is epoch-based. Default min_epoch_blocks = 10 blocks. If Collateralization Ratio drops below 0.95, epoch period increases.

Test Category 1: Deployment Creation (AKT → ACT Conversion)

BME Deployment Flow:

  1. Mint ACT first: User converts AKT to ACT via akash tx bme mint-act
  2. Wait for epoch: ACT appears in balance after ~1 minute
  3. Create deployment: SDL pricing and deposit must use uact (not uakt)
  4. Escrow funded with ACT: User's ACT balance decreases

CRITICAL: SDL Pricing Change With BME enabled, SDL pricing must be specified in uact instead of uakt. Example:

profiles:
  compute:
    web:
      resources:
        cpu:
          units: 0.5
        memory:
          size: 512Mi
        storage:
          size: 1Gi
  placement:
    dcloud:
      pricing:
        web:
          denom: uact    # <-- Must be uact, not uakt
          amount: 1000

ACT Minting Delay ACT mints are processed in epochs (default: every 10 blocks). After akash tx bme mint-act, the ACT will not appear in your bank balance immediately. Wait ~1 minute (10 blocks × ~6 sec/block) then check balance.

Test 1.1: Create Deployment with AKT Wallet (Full Lifecycle)

Objective: Verify complete deployment lifecycle from ACT minting through active lease, validating BME state at each step

Preconditions:

  • Provider is online and bidding
  • Market params allow AKT bid deposits (Test 0.11 passed)
  • User has AKT balance (from faucet)

Step 1.1.0: Mint ACT (Required Before Deployment)

Background: With BME, deployments require ACT for escrow deposits. Users must first convert AKT to ACT.

User Actions:

  1. Mint ACT from AKT:

    akash tx bme mint-act 10000000uakt --from <wallet> -y

    (This converts 10 AKT to ACT)

  2. Wait for epoch processing (~1 minute):

    sleep 60

  3. Verify ACT appeared in balance:

    akash query bank balances <user-address>

Expected Results:

  • AKT balance decreased by ~10 AKT
  • ACT balance appears (amount = 10 × oracle_price)
  • Example: 10 AKT @ $0.46 = ~4.6 ACT (4600000 uact)

Note: If no ACT in balance after 1 minute, wait longer or check bme vault-state for pending detection.

Step 1.1.1: Pre-Deployment Baseline

User Actions:

  1. After Step 1.1.0 (ACT minting), record baseline state:
# Record wallet AKT and ACT balance
akash query bank balances <user-address>

# Record BME vault state
akash query bme vault-state

# Record oracle price
akash query oracle prices | head -n 15

Record These Values:

Metric Baseline Value
User AKT Balance _______
User ACT Balance _______
VaultAKT _______
OutstandingACT (vault balances.uact) _______
RemintCredits _______
Oracle Price (AKT/USD) _______

Important: Ensure ACT balance is sufficient for deployment deposit (at least 5 ACT / 5000000 uact).

Step 1.1.2: Create Deployment

User Actions:

  1. Ensure SDL file (deploy.yml) has uact pricing:

    placement:
  akash:
    pricing:
      web:
        denom: uact    # MUST be uact
        amount: 100000

  2. Submit deployment transaction with uact deposit:

akash tx deployment create deploy.yml \
  --from <wallet> \
  --deposit 5000000uact \
  -y

Note: Deposit MUST be in uact, not uakt. User must have ACT balance from Step 1.1.0.

  1. Note the DSEQ (deployment sequence) from output
  2. Verify deployment created:
akash query deployment get --owner <user-address> --dseq <dseq>

Expected Results:

  • Transaction succeeds
  • Deployment state shows active
  • Order created for the deployment

Step 1.1.3: Verify Provider Bid Received

User Actions:

  1. Wait 10-30 seconds for provider to bid
  2. Query bids:
akash query market bid list --owner <user-address> --dseq <dseq>

Expected Results:

  • At least one bid appears
  • Bid is in open state
  • No provider errors about uact deposit (confirms Test 0.11 fix)

If No Bids:

  • Check provider logs for errors
  • Verify provider is running and connected
  • Confirm market params are correct (Test 0.11)

Step 1.1.4: Accept Bid, Create Lease, and Send Manifest

User Actions:

  1. Accept the bid (creates lease):
akash tx market lease create \
  --dseq <dseq> \
  --provider <provider-address> \
  --from <wallet> \
  -y
  1. Verify lease created:
akash query market lease list --owner <user-address> --dseq <dseq>
  1. Send manifest to provider (required to keep lease active):
provider-services send-manifest deploy.yml \
  --from <wallet> \
  --provider <provider-address>

Expected Results:

  • Lease state shows active
  • Provider address matches accepted bid
  • Manifest send shows status: PASS

Step 1.1.5: Post-Lease Validation

User Actions:

  1. Query updated state:
# Check wallet AKT and ACT balance
akash query bank balances <user-address>

# Check BME vault state
akash query bme vault-state

# Check deployment escrow
akash query deployment get --owner <user-address> --dseq <dseq>

Record Post-Lease Values:

Metric Baseline (from 1.1.1) Post-Lease Change
User AKT Balance _______ _______ Minimal (gas only)
User ACT Balance _______ _______ ↓ ~5 ACT
VaultAKT _______ _______ No change
OutstandingACT _______ _______ No change
RemintCredits _______ _______ No change

Expected Results:

  • User ACT balance decreased by ~5 ACT (escrow deposit)
  • User AKT balance unchanged (minus gas fees)
  • BME vault-state should NOT change at deployment time
    • ACT was already minted in Step 1.1.0
    • Deployment just transfers existing ACT to escrow
  • Deployment escrow shows funded balance in ACT

Key Insight: BME conversion (AKT → ACT) happens at mint time (Step 1.1.0), not at deployment time. Deployment simply uses the user's existing ACT balance.

Step 1.1.6: While Lease Active - Periodic Validation (Optional)

User Actions:

  1. While lease runs, periodically check state:
# Check vault state 
akash query bme vault-state

# Check BME status (should remain Healthy)
akash query bme status

# Verify lease still active
akash query market lease list --owner <user-address> --dseq <dseq>
  1. If running for extended period, note any settlement events in provider logs

Expected Results:

  • MintStatus remains mint_status_healthy
  • Vault state may change during provider settlements (ACT burned, AKT released)
  • RemintCredits may decrease as provider settlements use them
  • Lease remains active

Step 1.1.7: Deployment Summary Verification

Final Checklist:

  • ACT minted successfully (Step 1.1.0)
  • User has ACT balance after epoch
  • Deployment created with uact deposit
  • Provider bid received (no errors)
  • Lease created and active
  • Manifest sent successfully
  • User ACT balance decreased by deposit amount
  • Deployment escrow funded with ACT
  • BME MintStatus is mint_status_healthy

Note: BME vault-state changes at mint time (1.1.0), not at deployment time.

Test 1.2: Create Deployment via Console with Credit Card

⚠️ STATUS: PENDING - Console not yet BME-ready

Objective: Verify credit card payment triggers AKT market buy → ACT mint flow with proper remint credit accrual

Preconditions:

  • Console configured for testnet with BME support
  • Test credit card or payment sandbox available

User Actions:

  1. Log into Console with new account
  2. Record initial BME state: 
    akash query bme vault-state
  3. Create deployment via Console UI
  4. Select credit card payment option
  5. Pay $50 USD for compute credits
  6. Wait for provider bid and accept via Console
  7. Verify lease is active in Console
  8. Query post-deployment BME state: 
    akash query bme vault-state

Expected Results:

  • User sees ~$50 in compute credits (ACT) in Console
  • VaultAKT increased by ($50 / P_mint) AKT
  • OutstandingACT increased by ~50 ACT
  • RemintCredits increased by ($50 / P_mint) AKT
  • Deployment and lease are active

Notes:

  • This tests the card → AKT buy → ACT mint pipeline
  • User should have no direct exposure to AKT mechanics
  • Test blocked until Console BME integration complete

Test 1.3: Top Up Existing Deployment

Objective: Verify adding funds to running deployment triggers additional AKT → ACT conversion and remint credit accrual

Preconditions:

  • Active deployment from Test 1.1 with running lease

Step 1.3.1: Record Pre-Top-Up State

User Actions:

# Record current balances (AKT and ACT)
akash query bank balances <user-address>

# Record BME state
akash query bme vault-state

# Record deployment escrow
akash query deployment get --owner <user-address> --dseq <dseq>

Record Values:

Metric Pre-Top-Up Value
User AKT Balance _______
User ACT Balance _______
VaultAKT _______
OutstandingACT _______
RemintCredits _______
Deployment Escrow (funds) _______

Step 1.3.2: Top Up Deployment

User Actions:

akash tx escrow deposit deployment 2000000uact \
  --owner <user-address> \
  --from <wallet> \
  -y

Note:

  • Command is escrow deposit deployment, not deployment deposit
  • Deposit must be in uact (user needs ACT balance)

Step 1.3.3: Verify Post-Top-Up State

User Actions:

# Check updated balances
akash query bank balances <user-address>

# Check BME state
akash query bme vault-state

# Check deployment escrow increased
akash query deployment get --owner <user-address> --dseq <dseq>

Record Post-Top-Up Values:

Metric Pre-Top-Up Post-Top-Up Change
User ACT Balance _______ _______ ↓ ~2 ACT
Deployment Escrow _______ _______ ↑ ~2 ACT

Expected Results:

  • User ACT balance decreased by ~2 ACT
  • Deployment escrow increased (verify via escrow_account.state.funds)
  • Lease remains active
  • BME vault-state should NOT change (ACT already exists, just transferred to escrow)

Test 1.4: Create Multiple Deployments from Single Wallet

Objective: Verify account-level ACT pool funds multiple deployments with cumulative remint credit accrual

Step 1.4.1: Setup and Baseline

User Actions:

  1. Ensure wallet has at least 50 AKT (may require multiple faucet requests)
  2. Record initial state:
akash query bank balances <user-address>
akash query bme vault-state

Record Baseline:

Metric Baseline Value
User AKT Balance ~50 AKT
VaultAKT _______
OutstandingACT _______
RemintCredits _______

Step 1.4.2: Create Deployment A

User Actions:

akash tx deployment create deploy.yml \
  --from <wallet> \
  --deposit 10000000uakt \
  -y

Wait for bid, create lease, send manifest, verify active.

Record DSEQ-A: _______

Step 1.4.3: Create Deployment B

User Actions:

akash tx deployment create deploy.yml \
  --from <wallet> \
  --deposit 10000000uakt \
  -y

Wait for bid, create lease, send manifest, verify active.

Record DSEQ-B: _______

Step 1.4.4: Create Deployment C

User Actions:

akash tx deployment create deploy.yml \
  --from <wallet> \
  --deposit 10000000uakt \
  -y

Wait for bid, create lease, send manifest, verify active.

Record DSEQ-C: _______

Step 1.4.5: Final State Validation

User Actions:

# Check final wallet balance
akash query bank balances <user-address>

# Check cumulative BME state
akash query bme vault-state

# Verify all deployments active
akash query deployment list --owner <user-address>

# Verify all leases active
akash query market lease list --owner <user-address>

Record Final Values:

Metric Baseline Final Change
User AKT Balance ~50 _______ ↓ ~30 AKT
VaultAKT _______ _______ ↑ ~30 AKT (if BME active)
OutstandingACT _______ _______ ↑ (30 × price)
RemintCredits _______ _______ ↑ ~30 AKT

Expected Results (if BME deployment integration active):

  • User AKT balance: ~20 AKT remaining (minus fees)
  • VaultAKT increased by ~30 AKT total
  • OutstandingACT reflects all three deployments
  • RemintCredits increased by ~30 AKT total
  • All three deployments active with leases

Final Checklist:

  • Deployment A active with lease
  • Deployment B active with lease
  • Deployment C active with lease
  • Cumulative VaultAKT reflects all deposits (if BME active)
  • Cumulative RemintCredits reflects all deposits (if BME active)

Test Category 2: Deployment Closure and Refunds (ACT → AKT Conversion)

Test 2.1: Close Deployment - Price Unchanged - Remint Credits Sufficient

Objective: Verify closing deployment uses remint credits (no new AKT minted)

User Actions:

  1. Create new wallet, fund with 1000 AKT
  2. Record oracle price (P_initial)
  3. Create deployment with 500 AKT deposit
  4. Record RemintCredits after deposit
  5. Let deployment run briefly (1-2 settlement periods)
  6. Confirm oracle price is still ~P_initial
  7. Close deployment: 
    akash tx deployment close --owner <addr> --dseq <seq> --from <wallet>
  8. Query final state

Expected Results:

  • User receives AKT refund for unused portion
  • Refund amount = (Unused ACT) / P_current
  • Since price unchanged: AKT out ≈ AKT in (minus compute used)
  • RemintCredits decreased by refund amount
  • TotalMinted unchanged (no inflationary mint occurred)
  • VaultAKT decreased
  • OutstandingACT decreased

Critical Verification:

  • Check that TotalMinted did NOT increase
  • Confirm refund came from remint credits, not new minting

Test 2.2: Close Deployment - AKT Price Increased - Remint Credits Sufficient

Objective: Verify user receives fewer AKT back when price rose, using only remint credits

User Actions:

  1. Create new wallet, fund with 1000 AKT
  2. Record oracle price: P_initial = $1.00
  3. Create deployment with 500 AKT deposit (user gets 500 ACT worth of credits)
  4. Record RemintCredits (should be ~500 AKT)
  5. Let deployment run minimally (avoid significant compute charges)
  6. [Testnet Admin] Adjust oracle price to P_final = $2.00
  7. Close deployment
  8. Query final user AKT balance and BME state

Expected Results:

  • User deposited: 500 AKT at $1.00 = $500 worth
  • User had ~500 ACT credits (minus minimal usage, say 490 ACT remaining)
  • At withdrawal: 490 ACT / $2.00 = 245 AKT returned
  • User started with 1000 AKT, ends with ~745 AKT
  • RemintCredits decreased by 245 AKT (not 500 AKT)
  • 255 AKT remains in RemintCredits as surplus
  • TotalMinted unchanged (no inflation)

Critical Observations:

  • This confirms USD exposure, not AKT exposure
  • The "deflationary" effect: remint credits surplus remains in system

Test 2.3: Close Deployment - AKT Price Decreased - Remint Credits Insufficient (Inflationary Path)

Objective: Verify system mints new AKT when remint credits are insufficient

User Actions:

  1. Create new wallet, fund with 1000 AKT
  2. Record oracle price: P_initial = $1.00
  3. Create deployment with 500 AKT deposit
  4. Record:
    • RemintCredits (should be ~500 AKT)
    • TotalMinted (baseline)
    • Total AKT supply
  5. Let deployment run minimally
  6. [Testnet Admin] Adjust oracle price to P_final = $0.50
  7. Close deployment
  8. Query final state

Expected Results:

  • User deposited: 500 AKT at $1.00 = $500 worth
  • User had ~490 ACT remaining
  • At withdrawal: 490 ACT / $0.50 = 980 AKT needed
  • RemintCredits only has 500 AKT
  • Shortfall: 480 AKT must be newly minted
  • RemintCredits reduced to 0
  • TotalMinted increased by 480 AKT
  • Total AKT supply increased by 480 AKT
  • User receives full 980 AKT

Critical Verification:

  • Confirm TotalMinted increased (inflationary event)
  • Verify total AKT supply increased
  • This is the inflationary path we discussed earlier

Test 2.4: Close Deployment - Partial Remint Credit Usage

Objective: Verify system uses all available remint credits before minting

User Actions:

  1. Create scenario where RemintCredits = 300 AKT
  2. Create situation requiring 400 AKT payout
  3. Verify:
    • 300 AKT comes from remint credits
    • 100 AKT is newly minted
  4. Query ledger record for this transaction

Expected Results:

  • RemintCredits reduced by 300 (to 0)
  • TotalMinted increased by 100
  • Ledger record shows:
    • RemintCreditIssued: 300 AKT
    • Minted: 100 AKT

Test Category 3: Provider Settlement

Important Clarification on Settlement Flow:

Provider settlement is a two-step process:

  1. Step 1 - Settlement: When deployment closes or settles, provider receives ACT (not AKT directly)
  2. Step 2 - Provider Burn: Provider calls akash tx bme burn-act to convert ACT → AKT

The burn is provider-initiated, not automatic at settlement time. This allows providers to:

  • Accumulate ACT and burn in batches
  • Time their conversions strategically
  • Potentially hold ACT if desired

Note: Provider software will eventually automate the burn-act transaction, but currently it must be done manually.

Provider Burn Command:

akash tx bme burn-act <amount>uact --from <provider-wallet> -y

After Provider Burns ACT:

  • Provider's ACT balance decreases
  • Provider receives AKT (from vault's remint_credits if sufficient, or newly minted)
  • vault-state.total_burned.uact increases
  • vault-state.remint_credits decreases (non-inflationary) or total_minted.uakt increases (inflationary)

Test 3.1: Verify Provider Receives ACT at Settlement

Objective: Confirm providers receive ACT (not AKT) when deployment settles/closes

Preconditions:

  • Active deployment with provider
  • Provider has known ACT/AKT balance

User Actions:

  1. Record provider's balances before close: 
    akash query bank balances <provider-address>
  2. Close deployment (or wait for settlement)
  3. Record provider's balances after: 
    akash query bank balances <provider-address>

Expected Results:

  • Provider ACT balance increases (receives ACT for compute)
  • Provider AKT may increase slightly (bid deposit return)
  • BME vault-state unchanged at this step (no burn yet)

Test 3.2: Provider Burns ACT to Receive AKT (Non-Inflationary)

Objective: Verify provider can convert ACT to AKT using burn-act, paid from remint credits

Preconditions:

  • Provider has ACT balance (from settlement)
  • Vault has sufficient remint_credits

User Actions:

  1. Record pre-burn state:

    # Provider balances
akash query bank balances <provider-address>

# BME vault state
akash query bme vault-state

  2. Provider burns ACT:

    akash tx bme burn-act <amount>uact --from <provider-wallet> -y

  3. Wait for epoch (~1 minute)

  4. Record post-burn state:

    akash query bank balances <provider-address>
akash query bme vault-state

Expected Results:

  • Provider ACT balance decreased by burn amount
  • Provider AKT balance increased (ACT amount / oracle price)
  • vault-state.total_burned.uact increased
  • vault-state.remint_credits decreased
  • vault-state.total_minted.uakt unchanged (non-inflationary)

Test 3.3: Provider Burns ACT When AKT Price Rose

Objective: Verify provider receives fewer AKT when price increased (same USD value)

User Actions:

  1. Record provider's initial AKT balance
  2. Record RemintCredits and TotalMinted
  3. Record oracle price: P_start = $1.00
  4. Create deployment, let it run for known compute cost (e.g., $100 USD worth)
  5. [Testnet Admin] Adjust oracle price to P_settle = $1.25
  6. Wait for settlement epoch
  7. Query provider's AKT balance and BME state

Expected Results:

  • Compute cost: $100 USD
  • At $1.25: Provider receives 100 / 1.25 = 80 AKT
  • RemintCredits decreased by 80 AKT
  • TotalMinted unchanged
  • Provider received correct USD value in AKT terms

Test 3.3: Provider Payment When AKT Price Dropped (Inflationary Path)

Objective: Verify settlement mints new AKT when remint credits insufficient

User Actions:

  1. Record:
    • Provider's initial AKT balance
    • RemintCredits (note the amount)
    • TotalMinted
    • Total AKT supply
  2. Record oracle price: P_start = $1.00
  3. Create deployment with deposit that results in known remint credits
  4. Let it run for compute cost exceeding remint credits at dropped price
  5. [Testnet Admin] Adjust oracle price to P_settle = $0.50
  6. Wait for settlement epoch
  7. Query all metrics

Expected Results:

  • Provider should receive full AKT amount owed
  • RemintCredits depleted (reduced to 0 or near 0)
  • TotalMinted increased by shortfall amount
  • Total AKT supply increased

Critical Verification:

  • This confirms the inflationary path works correctly
  • Compare total supply before/after

Test 3.4: Multiple Settlements - Remint Credit Depletion Over Time

Objective: Verify system behavior as remint credits deplete across multiple settlements

User Actions:

  1. Create deployment with 1000 AKT deposit (1000 remint credits)
  2. [Testnet Admin] Drop price so settlements require more AKT than accrued
  3. Let multiple settlement epochs occur
  4. Track RemintCredits and TotalMinted after each epoch

Expected Results:

  • First settlements use remint credits only
  • Eventually remint credits deplete
  • Later settlements require new minting
  • Clear transition visible in metrics

Test Category 4: Epoch-Based Processing

Understanding Pending Operations:

The BME module processes mint/burn requests in epochs (batches of ~10 blocks / ~1 minute), not immediately. There is no CLI command to directly view pending operations waiting in the queue.

However, pending operations can be inferred from vault-state:

  • Pending mints: When you mint ACT, balances.uakt increases immediately (AKT received by vault), but remint_credits only updates after the epoch completes. The difference indicates pending mints.
  • Pending burns: Similar pattern - ACT is received but AKT isn't released until epoch processes.

To detect pending operations:

# Check vault state
akash query bme vault-state

# If balances.uakt > remint_credits, there are pending mint operations
# The difference = amount of AKT awaiting ACT minting

Tests in this category verify epoch behavior through vault-state and bank balance changes before and after waiting for epoch completion.

Available BME query commands:

  • akash query bme params
  • akash query bme status
  • akash query bme vault-state

Test 4.1: Verify Epoch-Based Processing

Objective: Confirm mint requests are processed in epochs, not immediately

User Actions:

  1. Record initial vault-state: 
    akash query bme vault-state
  2. Submit mint-act request: 
    akash tx bme mint-act 100000000uakt --from <wallet> -y
  3. Immediately query vault-state again: 
    akash query bme vault-state
    Note: AKT should be in vault, but ACT may not yet be minted
  4. Wait for epoch (~1 minute / 10 blocks)
  5. Query vault-state again and bank balance: 
    akash query bme vault-state
akash query bank balances <wallet>

Expected Results:

  • Immediately after tx: vault-state.balances.uakt increases
  • After epoch:
    • vault-state.balances.uact increases
    • vault-state.total_minted.uact increases
    • User's bank balance shows ACT

Test 4.2: Multiple Requests Before Epoch

Objective: Verify multiple requests submitted before epoch are all processed

User Actions:

  1. Record initial state
  2. Submit multiple mint-act requests in rapid succession: 
    akash tx bme mint-act 50000000uakt --from <wallet> -y
akash tx bme mint-act 50000000uakt --from <wallet> -y
akash tx bme mint-act 50000000uakt --from <wallet> -y
  3. Wait for epoch processing (~1 minute)
  4. Verify all requests processed: 
    akash query bme vault-state
akash query bank balances <wallet>

Expected Results:

  • All AKT transfers to vault complete
  • After epoch: Total ACT minted reflects all three requests
  • Final state is consistent (no lost requests)

Test 4.3: Request During Circuit Breaker

Objective: Verify mint requests fail when circuit breaker is active

Preconditions:

  • [Testnet Admin] Trigger circuit breaker (mint_status_halt_cr state)

User Actions:

  1. Verify circuit breaker is active:

    akash query bme status

    Confirm: status: mint_status_halt_cr and mints_allowed: false

  2. Attempt to mint ACT:

    akash tx bme mint-act 100000000uakt --from <wallet> -y

  3. Observe result

Expected Results:

  • Transaction fails with circuit breaker error
  • No AKT transferred to vault
  • refunds_allowed should still be true (users can exit via burn-act)

Test 4.4: Detect Pending Operations via Vault-State

Objective: Verify pending mint operations can be detected before epoch processing

Background: While there's no pending-records CLI command, pending operations can be detected by comparing balances.uakt (updates immediately) with remint_credits (updates after epoch).

User Actions:

  1. Record baseline (should be equal if no pending):

    akash query bme vault-state

    Note: balances.uakt and remint_credits.uakt values

  2. Submit mint request:

    akash tx bme mint-act 25000000uakt --from <wallet> -y

  3. Immediately check vault-state (within 10 seconds):

    akash query bme vault-state

  4. Calculate pending amount:

    Pending = balances.uakt - remint_credits.uakt

  5. Wait for epoch (~1-2 minutes):

    sleep 90
akash query bme vault-state

Expected Results:

Metric Baseline Immediately After After Epoch
balances.uakt X X + 25M (immediate) X + 25M
remint_credits X X (unchanged) X + 25M (caught up)
balances.uact Y Y (unchanged) Y + (25M × price)
total_minted.uact Y Y (unchanged) Y + (25M × price)

Key Insight:

  • balances.uakt > remint_credits indicates pending operations
  • Difference equals the AKT amount awaiting epoch processing
  • After epoch: remint_credits catches up to balances.uakt

Test Category 5: Direct Message Operations (MsgMintACT, MsgBurnACT, MsgBurnMint)

These tests cover direct user invocation of BME conversion messages, independent of the deployment lifecycle.

Important Notes:

  • ACT minting is epoch-based (default: every 10 blocks / ~1 minute)
  • After mint-act tx succeeds, ACT will NOT appear in bank balance immediately
  • Check akash query bme vault-state to see pending state changes
  • Wait for epoch, then check akash query bank balances for ACT

Command Reference:

# Mint ACT (AKT → ACT)
akash tx bme mint-act <amount>uakt --from <wallet> -y

# Burn ACT (ACT → AKT)
akash tx bme burn-act <amount>uact --from <wallet> -y

# Check status
akash query bme status
akash query bme vault-state

Test 5.1: MsgMintACT - Direct AKT to ACT Conversion

Objective: Verify user can directly convert AKT to ACT without creating a deployment

User Actions:

  1. Create new wallet, fund with 1000 AKT
  2. Record initial state: 
    akash query bank balances <user-address>
akash query bme vault-state
akash query oracle prices --asset-denom uakt --limit 1
  3. Execute direct MsgMintACT: 
    akash tx bme mint-act 500000000uakt --from <wallet> -y
  4. Check vault state immediately (AKT should be there): 
    akash query bme vault-state
  5. Wait for epoch (~1 minute), then check bank balance: 
    sleep 60
akash query bank balances <user-address>

Expected Results:

  • Immediately: AKT transferred to vault, vault-state.balances.uakt ↑
  • After epoch:
    • User AKT balance decreased by 500 AKT
    • User ACT balance increased by (500 × oracle_price) ACT
    • vault-state.balances.uact ↑
    • vault-state.remint_credits ↑ by 500 AKT
    • vault-state.total_minted.uact ↑

Test 5.2: MsgMintACT - Convert to Different Recipient

Objective: Verify AKT can be converted to ACT for a different address

User Actions:

  1. Create Wallet A with 1000 AKT
  2. Create Wallet B (empty)
  3. Check if --to flag is supported: 
    akash tx bme mint-act -h
  4. If supported, execute MsgMintACT from A with --to pointing to B: 
    akash tx bme mint-act 300000000uakt --from <wallet-A> --to <wallet-B> -y
  5. Wait for epoch, then query both wallets

Expected Results:

  • Wallet A: AKT decreased by 300
  • Wallet A: ACT unchanged (still 0)
  • Wallet B: ACT balance = (300 × oracle_price) ACT
  • BME state updated correctly

Note: If --to flag not available, ACT goes to sender's address only.

Test 5.3: MsgBurnACT - Direct ACT to AKT Conversion

Objective: Verify user can directly convert ACT back to AKT

User Actions:

  1. Start with wallet that has ACT balance (from Test 5.1 or deployment refund)
  2. Record initial state:
    • User AKT balance
    • User ACT balance
    • RemintCredits
    • TotalMinted
    • Oracle price
  3. Execute direct MsgBurnACT: 
    akash tx bme burn-act --from <wallet> --coins 200uact --to <same-wallet>
  4. Query post-transaction state

Expected Results:

  • User ACT balance decreased by 200 ACT
  • User AKT balance increased by (200 / P_current) AKT
  • OutstandingACT decreased by 200 ACT
  • RemintCredits decreased (if sufficient) OR TotalMinted increased (if shortfall)
  • Response contains valid LedgerRecordID

Test 5.4: MsgBurnACT - Convert to Different Recipient

Objective: Verify ACT can be converted to AKT for a different address

User Actions:

  1. Wallet A has 500 ACT, 0 AKT
  2. Wallet B has 0 ACT, 0 AKT
  3. Execute MsgBurnACT from A with --to pointing to B: 
    akash tx bme burn-act --from <wallet-A> --coins 500uact --to <wallet-B>
  4. Query both wallets

Expected Results:

  • Wallet A: ACT decreased by 500, AKT unchanged
  • Wallet B: AKT balance = (500 / P_current) AKT
  • BME state updated correctly

Test 5.5: MsgBurnMint - Generic Swap AKT to ACT

Objective: Verify generic BurnMint message works for AKT→ACT

User Actions:

  1. Wallet with 1000 AKT
  2. Execute MsgBurnMint specifying both denoms: 
    akash tx bme burn-mint --from <wallet> --coins 400uakt --denom-to-mint uact --to <wallet>
  3. Verify same behavior as MsgMintACT

Expected Results:

  • Functionally identical to MsgMintACT
  • ACT minted = 400 × P_mint
  • Response contains LedgerRecordID

Test 5.6: MsgBurnMint - Generic Swap ACT to AKT

Objective: Verify generic BurnMint message works for ACT→AKT

User Actions:

  1. Wallet with ACT balance
  2. Execute MsgBurnMint specifying both denoms: 
    akash tx bme burn-mint --from <wallet> --coins 200uact --denom-to-mint uakt --to <wallet>
  3. Verify same behavior as MsgBurnACT

Expected Results:

  • Functionally identical to MsgBurnACT
  • AKT received = 200 / P_current
  • Response contains LedgerRecordID

Test 5.7: Pre-Fund ACT Then Create Deployment

Objective: Verify user can pre-fund ACT balance and later use it for deployment

User Actions:

  1. Create wallet with 2000 AKT
  2. Convert 1000 AKT → ACT via MsgMintACT
  3. Verify user has ~1000 AKT and ~(1000 × P) ACT
  4. Create deployment using the pre-funded ACT
  5. Verify deployment uses existing ACT balance

Expected Results:

  • Deployment creation draws from existing ACT
  • No additional AKT→ACT conversion at deployment time (or reduced amount)
  • Two-step funding workflow works correctly

Note: This test validates a new user workflow enabled by direct messages.

Test 5.8: Partial ACT Withdrawal Without Closing Deployment

Objective: Verify user can withdraw excess ACT while deployment runs

User Actions:

  1. Create deployment with large ACT balance
  2. While deployment is running, execute MsgBurnACT for portion of unused ACT
  3. Verify:
    • Deployment continues running
    • User receives AKT
    • Remaining ACT still available for deployment

Expected Results:

  • Deployment unaffected
  • User can manage ACT balance independently
  • Partial withdrawal successful

Test 5.9: Input Validation - Invalid Owner Address

Objective: Verify proper error on invalid owner address

User Actions:

  1. Attempt MsgMintACT with malformed owner address
  2. Observe failure

Expected Results:

  • Error: ErrInvalidAddress: invalid owner address
  • No state changes
  • Transaction rejected at validation

Test 5.10: Input Validation - Invalid To Address

Objective: Verify proper error on invalid recipient address

User Actions:

  1. Attempt MsgMintACT with valid owner but malformed to address
  2. Observe failure

Expected Results:

  • Error: ErrInvalidAddress: invalid to address
  • No state changes

Test 5.11: Input Validation - Invalid Coins

Objective: Verify proper error on invalid coin specification

User Actions:

  1. Attempt MsgMintACT with invalid coins (negative, zero, malformed denom)
  2. Observe failure

Expected Results:

  • Error: ErrInvalidCoins: invalid coins
  • No state changes

Test 5.12: Input Validation - Invalid Swap Route

Objective: Verify rejection of unsupported token pairs

User Actions:

  1. Attempt MsgBurnMint with unsupported denom combination (e.g., USDC → ACT)
  2. Observe failure

Expected Results:

  • Error: ErrInvalidDenom: invalid swap route
  • Only AKT↔ACT swaps allowed

Test 5.13: MsgMintACT During Circuit Breaker Halt

Objective: Verify direct AKT→ACT blocked during circuit breaker

User Actions:

  1. [Testnet Admin] Trigger circuit breaker (HaltCR)
  2. Attempt MsgMintACT
  3. Observe failure

Expected Results:

  • Error: ErrCircuitBreakerActive
  • AKT→ACT blocked (same as deployment flow)
  • User's AKT unchanged

Test 5.14: MsgBurnACT During Circuit Breaker Halt

Objective: Verify ACT→AKT still works during circuit breaker (settlements must continue)

User Actions:

  1. User has ACT balance
  2. [Testnet Admin] Trigger circuit breaker (HaltCR)
  3. Attempt MsgBurnACT
  4. Observe result

Expected Results:

  • MsgBurnACT should succeed (ACT→AKT must continue for settlements)
  • User receives AKT
  • Only new ACT minting is blocked, not ACT burning

Critical Verification:

  • This confirms asymmetric circuit breaker behavior
  • Providers/users can still exit ACT positions during halt

Test 5.15: LedgerRecordID Verification

Objective: Verify response contains valid, queryable LedgerRecordID

User Actions:

  1. Execute MsgMintACT: 
    akash tx bme mint-act 100000000uakt --from <wallet> -y
  2. Examine transaction response/events for LedgerRecordID

Expected Results:

  • Transaction succeeds
  • Response or events may include record tracking information
  • Vault-state reflects the operation after epoch

Note: Direct ledger record queries are not available via CLI. Verify operation through vault-state changes and bank balance updates.

Test 5.16: Consecutive Direct Operations

Objective: Verify multiple direct operations work correctly in sequence

User Actions:

  1. Start with 2000 AKT
  2. MsgMintACT: 500 AKT → ACT
  3. MsgMintACT: 300 AKT → ACT
  4. MsgBurnACT: 200 ACT → AKT
  5. MsgMintACT: 100 AKT → ACT
  6. Reconcile all balances and BME state

Expected Results:

  • Each operation independent and correct
  • Running totals accurate
  • All LedgerRecordIDs unique
  • Final state fully reconciled

Test Category 6: Circuit Breaker and Mint Status

⚠️ REQUIRES AKASH CORE TEAM MEMBER

Circuit breaker testing requires manipulation of the oracle price feed, which can only be done by an Akash core team member with access to the testnet price feeder infrastructure.

Background - Circuit Breaker Mechanics:

The Collateralization Ratio determines system health. It measures whether the vault has enough AKT to back all outstanding ACT:

Collateralization Ratio = (VaultAKT × OraclePrice) / OutstandingACT

Where:

  • VaultAKT = AKT held in vault (backing)
  • OraclePrice = Current AKT/USD price from oracle
  • OutstandingACT = Total ACT in circulation (each ACT ≈ $1 USD)

When AKT price drops dramatically, the vault's USD value drops below the outstanding ACT liability, triggering the circuit breaker.

Current Testnet State Example:

VaultAKT: 205 AKT
OutstandingACT: 95 ACT (~$95 USD)
Current Price: $0.46
Current CR = (205 × $0.46) / 95 = $94.30 / $95 ≈ 0.99 (99%)

Threshold Trigger Prices (based on current testnet state):

Status Threshold Required Price Price Drop
Healthy > 0.95 > $0.44 -
Warning < 0.95 < $0.44 ~4% drop
Halt < 0.90 < $0.42 ~9% drop
Severe Halt < 0.50 < $0.23 ~50% drop

Recommended test price: $0.20 → CR ≈ 0.43 (43%) - clearly in halt territory

Circuit Breaker Testing Phases

Phase 1: Stop Production Price Feeder

When the legitimate price feeder is stopped:

systemctl stop akash-price-feeder

Expected behavior:

  • Oracle stops receiving new prices
  • After staleness threshold, system enters mint_status_halt_oracle
  • This is different from mint_status_halt_cr

Verification:

akash query bme status
# Expected: status: mint_status_halt_oracle, mints_allowed: false

Phase 2: Start Circuit Breaker Simulator (Recovery)

The simulator initially submits real prices to recover from oracle halt:

Expected behavior:

  • Oracle receives fresh prices
  • Status transitions: mint_status_halt_oracle → mint_status_healthy
  • Mints become allowed again
  • System runs healthy for verification window (~3 minutes)

Verification:

akash query bme status
# Expected: status: mint_status_healthy, mints_allowed: true

akash tx bme mint-act 1000000uakt --from test-account -y
# Expected: SUCCESS

Phase 3: Circuit Breaker Active (Price Manipulation)

The simulator submits manipulated low price (e.g., $0.20):

Aspect Expected Behavior
BME Status mint_status_halt_cr
mints_allowed false
refunds_allowed true
New mint-act FAILS - circuit breaker blocks AKT→ACT
Existing burn-act WORKS - providers can still convert ACT→AKT
New deployments with existing ACT WORKS - ACT already minted
Existing deployments CONTINUE running normally
Provider settlements CONTINUE - providers receive ACT

Verification during circuit breaker:

# Status shows halt
akash query bme status
# Expected: status: mint_status_halt_cr, mints_allowed: false, refunds_allowed: true

# Minting FAILS
akash tx bme mint-act 1000000uakt --from test-account -y
# Expected: ERROR - circuit breaker active

# Burning WORKS (if user has ACT)
akash tx bme burn-act 100000uact --from test-account -y
# Expected: SUCCESS

# Deployment with existing ACT WORKS
akash tx deployment create deploy.yml --deposit 1000000uact --from test-account -y
# Expected: SUCCESS

# Existing deployments continue
akash query deployment list --owner <address>
# Expected: state: active

Phase 4: Recovery (Real Prices Restored)

The simulator returns to real prices (or is stopped and production feeder restarted):

Expected behavior:

  • Collateralization Ratio recalculates to healthy level
  • Status transitions: mint_status_halt_cr → mint_status_warning → mint_status_healthy
  • Mints become allowed again
  • No lasting damage to vault state

Verification:

akash query bme status
# Expected: status: mint_status_healthy, mints_allowed: true

akash tx bme mint-act 1000000uakt --from test-account -y
# Expected: SUCCESS

akash query bme vault-state
# Expected: consistent values, no corruption

Circuit Breaker Simulator Script

The simulator script runs through these phases automatically:

  1. Recovery Phase (3 minutes): Submit real Pyth prices
  2. Circuit Breaker Phase (30 minutes): Submit manipulated prices ($0.20)
  3. Recovery Phase (5 minutes): Return to real prices, verify recovery
  4. Shutdown: Log completion

Safety features:

  • Refuses to run on mainnet chain IDs
  • Auto-recovery after timeout (doesn't leave system in broken state)
  • Clear logging of current phase
  • Graceful shutdown handling

Test 6.1: Observe MintStatusHealthy

Objective: Verify healthy status during normal operation

User Actions:

  1. Ensure Collateralization Ratio is above warning threshold
  2. Query mint status: 
    akash query bme status
  3. Perform normal operations (mint-act, create deployment)

Expected Results:

  • MintStatus: mint_status_healthy
  • All operations proceed normally
  • epoch_blocks at minimum value

Test 6.2: Observe MintStatusWarning

Objective: Verify warning status when Collateralization Ratio approaches threshold

Precondition: Akash core team member adjusts oracle price to trigger warning state

User Actions:

  1. Query current status: 
    akash query bme status
  2. [Akash Core Team] Adjust oracle price until Collateralization Ratio between warn and halt thresholds
  3. Query mint status again
  4. Attempt to mint ACT and create new deployment

Expected Results:

  • MintStatus: mint_status_warning
  • New mints and deployments still allowed
  • epoch_blocks increases (settlements slow down)

Test 6.3: MintStatusHaltCR - New Mints Blocked

Objective: Verify new AKT→ACT conversions blocked when Collateralization Ratio below halt threshold

Precondition: Akash core team member triggers circuit breaker

User Actions:

  1. [Akash Core Team] Adjust oracle price until Collateralization Ratio < halt threshold
  2. Query mint status: 
    akash query bme status
  3. Attempt to mint ACT: 
    akash tx bme mint-act 1000000uakt --from test-account -y
  4. Observe failure

Expected Results:

  • MintStatus: mint_status_halt_cr
  • Mint-act transaction fails
  • Error indicates circuit breaker active

Test 6.4: MintStatusHaltOracle - Oracle Failure

Objective: Verify system halts when oracle unavailable (separate from Collateralization Ratio halt)

Precondition: Akash core team member stops price feeder entirely

User Actions:

  1. [Akash Core Team] Stop oracle price feeder completely (no price updates)
  2. Wait for oracle staleness threshold
  3. Query mint status: 
    akash query bme status
  4. Attempt operations

Expected Results:

  • MintStatus: mint_status_halt_oracle
  • Operations fail with oracle error
  • Distinct from mint_status_halt_cr

Test 6.5: Existing Deployments Continue During Halt

Objective: Verify running deployments unaffected by circuit breaker

User Actions:

  1. Create deployment while system is healthy
  2. Confirm deployment running and provider bidding
  3. [Akash Core Team] Trigger circuit breaker (HaltCR)
  4. Verify existing deployment continues running
  5. Verify provider still receives ACT settlement payments
  6. Monitor for multiple settlement epochs

Expected Results:

  • Existing deployments unaffected
  • Providers continue receiving ACT payments
  • Only new ACT minting (AKT→ACT) is blocked
  • Existing ACT can still be used for deployments
  • Provider burn-act still works

Test 6.6: Circuit Breaker Recovery

Objective: Verify system resumes when Collateralization Ratio recovers

User Actions:

  1. Start with circuit breaker in HaltCR state
  2. Confirm new mint-act fails
  3. [Akash Core Team] Restore legitimate price feeder
  4. Wait for price to update and Collateralization Ratio to recover
  5. Query mint status
  6. Attempt to mint ACT

Expected Results:

  • MintStatus transitions: mint_status_halt_cr → mint_status_warning or mint_status_healthy
  • New mints allowed again
  • No manual intervention required beyond restoring price feed

Test 6.7: Mint Status State Transitions

Objective: Verify all valid state transitions

Test Matrix:

From To Trigger
Healthy Warning Collateralization Ratio drops below warn threshold
Warning Healthy Collateralization Ratio rises above warn threshold
Warning HaltCR Collateralization Ratio drops below halt threshold
HaltCR Warning Collateralization Ratio rises above halt threshold
Any HaltOracle Oracle becomes unavailable/stale
HaltOracle Previous Oracle recovers

User Actions:

  • Coordinate with Akash core team to walk through each transition
  • Query status after each change
  • Verify state transitions are logged/emitted

Test Category 7: Observability and State Verification

Note: Direct ledger record queries are not available via CLI. These tests verify BME state changes through available queries (vault-state, status, bank balances) and transaction events.

Available BME query commands:

  • akash query bme params
  • akash query bme status
  • akash query bme vault-state

Test 7.1: Verify State Changes - AKT→ACT (Deposit)

Objective: Confirm vault-state reflects deposit operations

User Actions:

  1. Record initial vault-state: 
    akash query bme vault-state
  2. Create deployment or mint ACT directly
  3. Wait for epoch, then query vault-state again

Expected Results: After epoch, vault-state shows:

  • balances.uakt increased (AKT in vault)
  • balances.uact increased (ACT minted)
  • remint_credits increased (AKT escrowed for future settlements)
  • total_minted.uact increased

Test 7.2: Verify State Changes - ACT→AKT (Refund with Remint)

Objective: Confirm vault-state reflects refund/burn operations using remint credits

User Actions:

  1. Start with ACT balance from previous minting
  2. Record initial vault-state
  3. Burn ACT: 
    akash tx bme burn-act 50000000uact --from <wallet> -y
  4. Wait for epoch, then query vault-state

Expected Results: After epoch, vault-state shows:

  • balances.uact decreased (ACT burned)
  • remint_credits decreased (used for AKT payout)
  • total_minted.uakt unchanged (no new AKT minted - non-inflationary)
  • User's AKT balance increased

Test 7.3: Verify State Changes - ACT→AKT (Inflationary Path)

Objective: Confirm vault-state shows inflationary minting when remint credits insufficient

Preconditions:

  • Low remint credits relative to ACT burn amount
  • Or price drop making remint credits insufficient

User Actions:

  1. Record initial vault-state
  2. Trigger refund/burn that exceeds remint credits
  3. Wait for epoch, then query vault-state

Expected Results: After epoch, vault-state shows:

  • remint_credits decreased (possibly to 0)
  • total_minted.uakt INCREASED (new AKT minted - INFLATIONARY)
  • Total AKT supply increased

Test 7.4: Query BME Vault State

Objective: Verify all BME metrics queryable

User Actions:

  1. Execute BME queries via CLI: 
    akash query bme vault-state
akash query bme status
akash query bme params
  2. Verify all queries return valid data

Expected Results:

  • vault-state returns: Balances, TotalBurned, TotalMinted, RemintCredits
  • status returns: status enum, EpochHeightDiff, PreviousStatus
  • params returns: thresholds, epoch settings

Test 7.5: Event Emission - Mint Status Change

Objective: Verify EventMintStatusChange emitted on transitions

User Actions:

  1. Trigger mint status change (e.g., Healthy → Warning)
  2. Query transaction events

Expected Results:

  • EventMintStatusChange emitted
  • Contains: PreviousStatus, NewStatus, CollateralRatio

Test 7.6: Event Emission - Ledger Record Executed

Objective: Verify EventLedgerRecordExecuted emitted on completion

User Actions:

  1. Create deployment (triggers burn/mint)
  2. Query transaction events

Expected Results:

  • EventLedgerRecordExecuted emitted
  • Contains: ID (LedgerRecordID)

Test Category 8: Edge Cases and Error Handling

Test 8.1: Deployment with Insufficient AKT

Objective: Verify graceful failure when user lacks funds

User Actions:

  1. Create wallet with 10 AKT
  2. Attempt deployment requiring 100 AKT deposit
  3. Observe failure

Expected Results:

  • Transaction fails with insufficient funds error
  • No BME state changes
  • No pending record created
  • User's 10 AKT untouched

Test 8.2: Invalid Swap Route

Objective: Verify rejection of unsupported token conversions

User Actions:

  1. Attempt to swap tokens other than AKT↔ACT (if possible via direct tx)

Expected Results:

  • Error: ErrInvalidDenom: invalid swap route
  • No state changes

Test 8.3: Insufficient ACT Supply for Burn

Objective: Verify error when burning more ACT than exists

User Actions:

  1. Attempt scenario where ACT burn requested > total ACT supply

Expected Results:

  • Error: ErrInsufficientVaultFunds
  • No partial execution

Test 8.4: Concurrent Operations - Queue Integrity

Objective: Verify system handles concurrent requests correctly

User Actions:

  1. Create wallet with 5000 AKT
  2. Submit multiple operations simultaneously:
    • Create Deployment A
    • Create Deployment B
    • Top up existing deployment
  3. Verify all operations complete correctly

Expected Results:

  • Each operation gets unique LedgerRecordID
  • Sequence numbers increment correctly within block
  • No race conditions
  • Final state consistent

Test 8.5: Ledger Record ID Uniqueness

Objective: Verify LedgerRecordID is unique across all records

User Actions:

  1. Perform multiple operations across multiple blocks
  2. Query all ledger records
  3. Verify all IDs unique

Expected Results:

  • Each record has unique combination: (Denom, ToDenom, Source, Height, Sequence)
  • Sequence resets each block (per BeginBlocker)
  • No duplicate IDs

Test 8.6: SDL Pricing Denom Validation - Reject uakt

Objective: Verify deployment creation rejects SDL with uakt pricing (must use uact)

Background: With BME enabled, ACT is the only compute payment token. SDL pricing must specify uact. Using uakt should be rejected.

User Actions:

  1. Create SDL with uakt pricing:

    profiles:
  placement:
    akash:
      pricing:
        web:
          denom: uakt    # <-- INVALID, should be uact
          amount: 100000

  2. Attempt to create deployment:

    akash tx deployment create deploy-uakt.yml --deposit 5000000uakt --from <wallet> -y

  3. Observe result

Expected Results:

  • Transaction fails with denom validation error
  • Error message indicates uact required (not uakt)
  • No deployment created
  • No state changes
  • User's AKT balance unchanged (except gas if tx submitted)

⚠️ Current Status (as of testing):

  • Deployment with uakt pricing is incorrectly accepted
  • This bypasses BME entirely (AKT goes to escrow directly, no ACT conversion)
  • Bug reported - validation check to be added

Why This Matters:

  • Using uakt bypasses the entire BME mechanism
  • No ACT minted, no remint credits accrued
  • Provider settlements would fail or behave unexpectedly
  • Defeats purpose of BME price stability

Test Category 9: End-to-End Scenarios

Test 9.1: Full Deployment Lifecycle - Happy Path

Objective: Complete end-to-end test of typical user journey

User Actions:

  1. Create new wallet
  2. Fund with 2000 AKT from faucet
  3. Record all initial BME state
  4. Create deployment (500 AKT deposit)
  5. Verify deployment running
  6. Top up deployment (200 AKT)
  7. Let deployment run for 1 hour
  8. Query provider payments occurred
  9. Close deployment
  10. Verify refund received
  11. Reconcile all accounting

Expected Results:

  • All steps complete successfully
  • RemintCredits accrued on deposits
  • RemintCredits used on settlements/refund
  • TotalMinted unchanged (if no price drop)
  • Final AKT balance = Initial - compute_used (at varying prices)
  • All ledger records present and accurate

Test 9.2: Full Lifecycle with Price Volatility

Objective: End-to-end test with price movements

User Actions:

  1. Create deployment at P = $1.00
  2. Let run, price rises to $1.50 (settlement at high price)
  3. Price drops to $0.80
  4. Close deployment (refund at low price)
  5. Reconcile all accounting

Expected Results:

  • Settlements during high price: fewer AKT paid, remint credits surplus
  • Refund during low price: may require new minting if surplus insufficient
  • TotalMinted reflects any inflationary events
  • User's final AKT reflects USD exposure, not AKT exposure

Test 9.3: Stress Test - Circuit Breaker Engagement

Objective: Verify system stability during stress

User Actions:

  1. Create multiple active deployments
  2. [Testnet Admin] Gradually drop price toward halt threshold
  3. Observe:
    • Mint status transitions
    • Epoch timing changes
    • Settlement behavior
  4. Trigger HaltCR
  5. Verify existing deployments continue
  6. Verify new deployments blocked
  7. [Testnet Admin] Recover price
  8. Verify system resumes

Expected Results:

  • Graceful degradation as Collateralization Ratio drops
  • No data loss or corruption
  • Clean recovery when Collateralization Ratio improves

Test 9.4: Multi-User Concurrent Activity

Objective: Verify system handles realistic multi-user load

User Actions:

  1. Create 10 test wallets
  2. Fund each with AKT
  3. Each wallet creates 2-3 deployments
  4. Let all run concurrently
  5. Randomly close deployments over time
  6. Verify all accounting correct

Expected Results:

  • All operations succeed
  • No cross-user contamination
  • BME state accurate across all users
  • RemintCredits properly shared/consumed

Summary Checklist

Category Tests Priority
Pre-Flight Health Checks 0.1-0.12 Critical (Run First)
Deployment Creation 1.1-1.4 Critical
Deployment Closure/Refunds 2.1-2.4 Critical
Provider Settlement 3.1-3.5 Critical
Epoch-Based Processing 4.1-4.4 High
Direct Message Operations 5.1-5.16 Critical
Circuit Breaker/Mint Status 6.1-6.7 ⚠️ Requires Akash Core Team
Observability/State Verification 7.1-7.6 Medium
Edge Cases 8.1-8.6 High
End-to-End 9.1-9.4 Critical

Testnet Admin Requirements

Several tests require testnet administrator actions:

Action Tests Requiring
Adjust oracle price 2.2, 2.3, 3.3, 3.4, 6.2, 6.3, 9.2, 9.3
Stop oracle updates 6.4
Trigger specific mint status 4.3, 5.13, 5.14, 6.3, 6.4, 6.5, 6.6, 9.3

Recommendation: Create admin scripts or tooling to easily manipulate oracle prices for testing price movement scenarios.

Key Implementation Details from Code Review

Based on code analysis, testers should be aware of:

  1. Remint Credits are now active - The system tracks credits accrued when AKT enters the vault and uses them before minting new AKT.

  2. Two-phase execution - RequestBurnMint queues operations, executeBurnMint processes them. Verify queue behavior.

  3. Four mint statuses - Healthy, Warning, HaltCR, HaltOracle (oracle-specific halt is separate from Collateralization Ratio halt).

  4. Dynamic epoch timing - calculateBlocksDiff adjusts settlement frequency based on Collateralization Ratio. Lower ratio = slower settlements.

  5. Ledger records track - RemintCreditAccrued, RemintCreditIssued, plus Burned and Minted for complete audit trail.

  6. Direct message operations - Three user-facing messages now available:

    • MsgMintACT - Direct AKT → ACT conversion (convenience wrapper)
    • MsgBurnACT - Direct ACT → AKT conversion (convenience wrapper)
    • MsgBurnMint - Generic swap supporting both directions
    • All return LedgerRecordID for tracking
    • Enables pre-funding ACT and partial withdrawals independent of deployment lifecycle

  7. Asymmetric circuit breaker - During HaltCR:

    • AKT → ACT (MsgMintACT) is blocked
    • ACT → AKT (MsgBurnACT) is allowed (settlements must continue)

Notes for Test Execution

  1. Price Manipulation: Most critical tests require ability to control oracle prices. Coordinate with testnet admins on mechanism.

  2. Settlement Timing: Some tests require waiting for settlement epochs. Note that epoch timing changes with Collateralization Ratio status.

  3. Document USD Exposure: Tests 2.2 and 2.3 specifically validate the behavioral change for AKT users - they now have USD exposure.

  4. Inflationary Path: Tests 2.3 and 3.3 are critical - they validate actual AKT minting when remint credits insufficient.

  5. Oracle vs Collateralization Ratio Halt: Test 6.4 verifies oracle failure is handled distinctly from Collateralization Ratio-based halt.

  6. Provider Coordination: Settlement tests require active providers. Ensure testnet has reliable provider(s) available.

  7. Direct Message CLI Commands: The new direct message operations should be available via CLI:

    akash tx bme mint-act --from <wallet> --coins <amount>uakt --to <recipient>
akash tx bme burn-act --from <wallet> --coins <amount>uact --to <recipient>
akash tx bme burn-mint --from <wallet> --coins <amount><denom> --denom-to-mint <target-denom> --to <recipient>

    Verify exact command syntax with implementation.

  8. Asymmetric Circuit Breaker: Test 5.14 validates that ACT→AKT (MsgBurnACT) continues working during HaltCR while AKT→ACT (MsgMintACT) is blocked. This is critical for allowing users/providers to exit during stress.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment