Edge Cases & Error Handling

These tests verify BME behavior at boundary conditions and edge cases.

Test 9.1: Zero Amount Operations

Objective: Verify system rejects zero-amount mint/burn operations

User Actions:

1. Attempt to mint zero AKT:

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

2. Attempt to burn zero ACT (if wallet has ACT):

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

3. Observe results

Expected Results:

• Both operations fail with validation error
• Error message indicates invalid/zero amount
• No state changes
• No vault-state modifications

Proof to Submit:

• Error message from zero mint-act attempt
• Error message from zero burn-act attempt

Test 9.2: Dust Amount Operations

Objective: Verify system handles very small (dust) amounts correctly

User Actions:

1. Attempt to mint minimal amount (1 uakt = 0.000001 AKT):

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

2. If successful, wait for epoch and check balance:

   sleep 60
   akash query bank balances <wallet>

3. Attempt to burn minimal ACT amount:

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

Expected Results:

• Either:
  • Operations succeed with dust amounts (system handles micro-amounts)
  • Operations fail with minimum amount error (system enforces minimums)
• If successful, vault-state reflects the tiny changes
• No precision loss or rounding errors that corrupt state

Proof to Submit:

• Result of 1 uakt mint attempt (success or error message)
• If successful, post-epoch balance showing dust ACT amount

Test 9.3: Maximum Amount Operations

Objective: Verify system handles very large amounts correctly

User Actions:

1. Check wallet’s full AKT balance:

   akash query bank balances <wallet>

2. Attempt to mint entire balance (or very large amount):

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

   Note: Leave enough for gas fees

3. Wait for epoch and verify:

   sleep 60
   akash query bank balances <wallet>
   akash query bme vault-state

4. If successful, attempt to burn all ACT:

   akash tx bme burn-act <full-act-balance>uact --from <wallet> -y

Expected Results:

• Large operations complete successfully (no overflow errors)
• Vault-state handles large numbers correctly
• ACT amount calculated correctly at oracle price
• No precision loss with large values

Proof to Submit:

• Pre/post balances showing large amount processed
• Vault-state showing correct handling of large values

Test 9.4: Rapid Sequential Operations

Objective: Verify system handles rapid consecutive operations correctly

User Actions:

1. Fund wallet with sufficient AKT (500 AKT from faucet)

2. Submit multiple operations 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

   Note: Submit sequentially (not in parallel with &). Parallel submissions from the same account will fail with sequence number mismatch errors (code 32) — this is expected Cosmos SDK behavior.

3. Wait for epoch:

   sleep 90

4. Check final state:

   akash query bank balances <wallet>
   akash query bme vault-state

5. Verify all operations were processed:

   # Total minted should be ~150 AKT worth of ACT

Expected Results:

• All sequential operations complete successfully
• Each operation gets unique sequence number
• Final balances reflect all operations
• No state corruption
• Vault-state is consistent

Note on Parallel Transactions: Submitting transactions in parallel (using &) from the same account will cause most to fail with code: 32 (sequence mismatch). This is normal Cosmos SDK behavior — not a BME issue.

Proof to Submit:

• All tx hashes from rapid operations
• Final balance showing all operations processed
• Vault-state showing consistent totals

Test 9.5: SDL with uakt Pricing (Known Validation Gap)

Objective: Document behavior when SDL incorrectly uses uakt instead of uact pricing

Background: With BME enabled, ACT is the compute payment token. SDL pricing should specify uact. Using uakt may bypass BME entirely.

User Actions:

1. Create SDL with incorrect uakt pricing:

   profiles:
     placement:
       akash:
         pricing:
           web:
             denom: uakt    # <-- Should be uact
             amount: 100000

2. Attempt to create deployment with uakt deposit:

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

3. Observe result

Expected Results (Ideal):

• Transaction fails with denom validation error
• Error message indicates uact required
• No deployment created

Current Behavior:

• ✅ Deployment with uakt pricing is correctly rejected
• Error: unsupported denomination uakt: invalid price
• Validation enforces uact as required denomination for BME

Test Outcome:

• Deployment is rejected with clear error message: ✅ PASS

Proof to Submit:

• SDL file showing uakt pricing
• Result of deployment create attempt (rejection error or deployment created)
• If accepted, note this as validation gap