Direct Message Operations

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:

Terminal window
# 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


# Generic swap (works both directions)
akash tx bme burn-mint <coins-to-burn> <denom-to-mint> --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 500 AKT (from faucet: https://faucet.dev.akash.pub)
  2. Record initial state:
    Terminal window
    akash query bank balances <user-address>
    akash query bme vault-state
    akash query oracle prices | head -n 15
  3. Execute direct MsgMintACT:
    Terminal window
    akash tx bme mint-act 250000000uakt --from <wallet> -y
  4. Check vault state immediately (AKT should be there):
    Terminal window
    akash query bme vault-state
  5. Wait for epoch (~1 minute), then check bank balance:
    Terminal window
    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 250 AKT
    • User ACT balance increased by (250 × oracle_price) ACT
    • vault-state.balances.uact ↑
    • vault-state.remint_credits ↑ by 250 AKT
    • vault-state.total_minted.uact ↑

Proof to Submit:

  • Pre-mint AKT/ACT balances
  • mint-act tx hash
  • Post-epoch ACT balance (showing ACT received)

Test 5.2: 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:

    Terminal window
    akash query bank balances <user-address>
    akash query bme vault-state
    akash query oracle prices | head -n 15

    Note: User AKT/ACT balance, RemintCredits, total_minted, Oracle price

  3. Execute direct MsgBurnACT:

    Terminal window
    akash tx bme burn-act 100000000uact --from <wallet> -y

  4. Wait for epoch (~1 minute):

    Terminal window
    sleep 60

  5. Query post-transaction state:

    Terminal window
    akash query bank balances <user-address>
    akash query bme vault-state

Expected Results:

  • User ACT balance decreased by 100 ACT
  • User AKT balance increased by (100 / P_current) AKT
  • OutstandingACT decreased by 100 ACT
  • RemintCredits decreased (if sufficient) OR total_minted.uakt increased (if shortfall)

Proof to Submit:

  • Pre-burn ACT/AKT balances
  • burn-act tx hash
  • Post-epoch AKT balance (showing AKT received)

Test 5.3: MsgBurnMint - Generic Swap AKT to ACT

Objective: Verify generic BurnMint message works for AKT→ACT

User Actions:

  1. Wallet with AKT balance
  2. Execute MsgBurnMint specifying both denoms:
    Terminal window
    akash tx bme burn-mint 200000000uakt uact --from <wallet> -y
  3. Wait for epoch (~1 minute):
    Terminal window
    sleep 60
  4. Verify same behavior as MsgMintACT:
    Terminal window
    akash query bank balances <user-address>
    akash query bme vault-state

Expected Results:

  • Functionally identical to MsgMintACT
  • ACT minted = 200 AKT × oracle_price
  • Vault state updated correctly

Proof to Submit:

  • Pre/post balances
  • burn-mint tx hash
  • Confirmation behavior matches mint-act

Test 5.4: 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:
    Terminal window
    akash tx bme burn-mint 100000000uact uakt --from <wallet> -y
  3. Wait for epoch (~1 minute):
    Terminal window
    sleep 60
  4. Verify same behavior as MsgBurnACT:
    Terminal window
    akash query bank balances <user-address>
    akash query bme vault-state

Expected Results:

  • Functionally identical to MsgBurnACT
  • AKT received = 100 ACT / oracle_price
  • Vault state updated correctly

Proof to Submit:

  • Pre/post balances
  • burn-mint tx hash
  • Confirmation behavior matches burn-act

Test 5.5: 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 AKT (500 AKT from faucet)
  2. Convert 250 AKT → ACT via MsgMintACT:
    Terminal window
    akash tx bme mint-act 250000000uakt --from <wallet> -y
    sleep 60
  3. Verify user has ~250 AKT and ACT balance:
    Terminal window
    akash query bank balances <user-address>
  4. Create deployment using the pre-funded ACT (see Category 1 for full workflow):
    Terminal window
    akash tx deployment create deploy.yml --deposit 50000000uact --from <wallet> -y
  5. Verify deployment uses existing ACT balance

Expected Results:

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

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

Proof to Submit:

  • Post-mint ACT balance
  • Deployment create tx hash
  • Confirmation ACT balance decreased by deposit amount

Test 5.6: 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:
    Terminal window
    akash tx bme burn-act 25000000uact --from <wallet> -y
  3. Wait for epoch:
    Terminal window
    sleep 60
  4. Verify:
    Terminal window
    akash query bank balances <user-address>
    akash query market lease list --owner <user-address>

Expected Results:

  • Deployment continues running
  • User receives AKT
  • Remaining ACT still available for deployment
  • Partial withdrawal successful

Proof to Submit:

  • Lease list showing deployment still active
  • burn-act tx hash
  • Post-burn AKT balance (showing AKT received)

Test 5.7: Input Validation - Invalid Owner Address

Objective: Verify proper error on invalid owner address

User Actions:

  1. Attempt MsgMintACT with malformed owner address:
    Terminal window
    akash tx bme mint-act 100000000uakt --from invalid_address -y
  2. Observe failure

Expected Results:

  • Error: ErrInvalidAddress: invalid owner address (or similar)
  • No state changes
  • Transaction rejected at validation

Proof to Submit:

  • Error message received

Test 5.8: Input Validation - Invalid Coins

Objective: Verify proper error on invalid coin specification

User Actions:

  1. Attempt MsgMintACT with invalid coins (negative, zero, malformed denom):
    Terminal window
    akash tx bme mint-act 0uakt --from <wallet> -y
    akash tx bme mint-act -100uakt --from <wallet> -y
  2. Observe failure

Expected Results:

  • Error: ErrInvalidCoins: invalid coins (or similar)
  • No state changes

Proof to Submit:

  • Error message(s) received for each invalid input

Test 5.9: Input Validation - Invalid Swap Route

Objective: Verify rejection of unsupported token pairs

User Actions:

  1. Attempt MsgBurnMint with unsupported denom combination:
    Terminal window
    akash tx bme burn-mint 100000000uusdc uact --from <wallet> -y
  2. Observe failure

Expected Results:

  • Error: ErrInvalidDenom: invalid swap route (or similar)
  • Only AKT↔ACT swaps allowed

Proof to Submit:

  • Error message received

Test 5.10: LedgerRecordID Verification

Objective: Verify operations are tracked and can be verified through vault-state

User Actions:

  1. Record initial vault state:
    Terminal window
    akash query bme vault-state
  2. Execute MsgMintACT:
    Terminal window
    akash tx bme mint-act 100000000uakt --from <wallet> -y
  3. Wait for epoch:
    Terminal window
    sleep 60
  4. Verify operation through vault-state changes:
    Terminal window
    akash query bme vault-state

Expected Results:

  • Transaction succeeds
  • Vault-state reflects the operation after epoch
  • total_minted.uact increased
  • remint_credits increased
  • Bank balance shows new ACT

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

Proof to Submit:

  • Pre/post vault-state showing changes
  • mint-act tx hash
  • Post-epoch bank balance

Test 5.11: Consecutive Direct Operations

Objective: Verify multiple direct operations work correctly in sequence

User Actions:

  1. Start with wallet funded with AKT (500 AKT from faucet)
  2. Execute operations in sequence, waiting for epoch between each:
    Terminal window
    # Operation 1: MsgMintACT 200 AKT → ACT
    akash tx bme mint-act 200000000uakt --from <wallet> -y
    sleep 60
    akash query bank balances <user-address>
    

    # Operation 2: MsgMintACT 100 AKT → ACT
    akash tx bme mint-act 100000000uakt --from <wallet> -y
    sleep 60
    akash query bank balances <user-address>
    

    # Operation 3: MsgBurnACT 50 ACT → AKT
    akash tx bme burn-act 50000000uact --from <wallet> -y
    sleep 60
    akash query bank balances <user-address>
    

    # Operation 4: MsgMintACT 50 AKT → ACT
    akash tx bme mint-act 50000000uakt --from <wallet> -y
    sleep 60
    akash query bank balances <user-address>
  3. Record final state:
    Terminal window
    akash query bank balances <user-address>
    akash query bme vault-state

Expected Results:

  • Each operation independent and correct
  • Running totals accurate
  • Final state fully reconciled:
    • AKT decreased by net minted amount (200 + 100 + 50 - burn_return)
    • ACT balance reflects net: minted ACT - 50 ACT burned
    • Vault state reflects cumulative operations

Proof to Submit:

  • Balance after each operation (4 snapshots)
  • Final vault-state
  • All tx hashes

Summary

TestObjectiveKey Verification
5.1MsgMintACT (AKT → ACT)User receives ACT after epoch
5.2MsgBurnACT (ACT → AKT)User receives AKT after epoch
5.3MsgBurnMint (AKT → ACT)Same as MsgMintACT
5.4MsgBurnMint (ACT → AKT)Same as MsgBurnACT
5.5Pre-fund ACT workflowTwo-step funding works
5.6Partial withdrawalBurn ACT while deployment runs
5.7Invalid owner addressError returned, no state change
5.8Invalid coinsError returned, no state change
5.9Invalid swap routeError returned, only AKT↔ACT
5.10Ledger verificationVault-state reflects operation
5.11Consecutive operationsAll ops independent and correct
Edit page on github
Epoch Processing CB Halt Testing