Epoch-Based Processing

Understanding Epoch-Based Processing:

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:

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

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

User Actions:

  1. Record initial vault-state:

    Terminal window
    akash query bme vault-state
  2. Submit mint-act request:

    Terminal window
    akash tx bme mint-act 100000000uakt --from <wallet> -y
  3. Immediately query vault-state again (within 10 seconds):

    Terminal window
    akash query bme vault-state

    Note: AKT should be in vault (balances.uakt ↑), but remint_credits may not yet be updated

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

    Terminal window
    sleep 60
  5. Query vault-state again and bank balance:

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

Expected Results:

MetricInitialImmediately AfterAfter Epoch
balances.uaktXX + 100M (immediate)X + 100M
remint_creditsXX (unchanged)X + 100M (caught up)
balances.uactYY (unchanged)Y + (100M × price)
total_minted.uactYY (unchanged)Y + (100M × price)
User ACT balance00Shows ACT

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

Proof to Submit:

  • Initial vault-state
  • Vault-state immediately after mint (showing balances.uakt increased)
  • Vault-state after epoch (showing remint_credits caught up)
  • User balance showing ACT received

Test 4.2: Multiple Queued Requests

Objective: Verify multiple requests submitted before epoch are all processed

User Actions:

  1. Record initial state:

    Terminal window
    akash query bme vault-state
    akash query bank balances <wallet>
  2. Submit multiple mint-act requests in rapid succession:

    Terminal window
    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):

    Terminal window
    sleep 60
  4. Verify all requests processed:

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

Expected Results:

  • All AKT transfers to vault complete (150 AKT total)
  • After epoch: Total ACT minted reflects all three requests
  • User ACT balance = 150 AKT × oracle_price
  • Final state is consistent (no lost requests)

Proof to Submit:

  • Initial vault-state and user balance
  • All three mint tx hashes
  • Final vault-state and user balance (showing all 150 AKT processed)