Provider Settlement

Provider Settlement Flow:

When a deployment runs on Akash, the provider earns compute payment in ACT. This happens automatically during settlement epochs — no user action required beyond running a deployment.

What testers can verify:

• Provider receives ACT from settlement (observable via balance queries)
• Lease price matches SDL pricing
• Provider ACT balance increases over time during active deployment

Note: Provider conversion of ACT → AKT (burn-act) is the same mechanism tested in Category 2. Since a provider account is functionally identical to any other account, there is no need to duplicate those tests here.

Test 3.1: Provider Receives ACT from Settlement

Objective: Verify provider receives ACT when deployment runs and settles

User Actions:

1. Identify the testnet provider address:

   akash query provider list | head -n 20

   Note a provider address (e.g., akash1...)

2. Record provider’s initial ACT balance:

   akash query bank balances <provider-address>

   Note the uact amount (may be 0 or existing balance).

3. Create deployment with ACT deposit:

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

4. Complete lease creation with the provider:

   # Wait for bids
   sleep 10
   akash query market bid list --owner <user-address> --dseq <dseq>
   
   # Create lease
   akash tx market lease create --dseq <dseq> --gseq 1 --oseq 1 \
     --provider <provider-address> --from <wallet> -y

5. Send manifest and let deployment run (~2-3 minutes for settlement to occur):

   provider-services send-manifest deploy.yml --dseq <dseq> --from <wallet>
   sleep 180

6. Check provider’s ACT balance again:

   akash query bank balances <provider-address>

7. Close deployment:

   akash tx deployment close --dseq <dseq> --from <wallet> -y

8. Final provider balance check:

   akash query bank balances <provider-address>

Expected Results:

• Provider ACT balance increased (received payment for compute)
• User’s escrowed ACT decreased (paid for compute)
• Settlement happened automatically during deployment lifecycle

Proof to Submit:

• Provider address used
• Provider ACT balance before deployment
• Provider ACT balance after deployment ran (showing increase)
• Deployment close tx hash

Test 3.2: Verify Lease Price Matches SDL Pricing

Objective: Confirm the lease is created with pricing that matches SDL specification

User Actions:

1. Review your SDL pricing section:

   profiles:
     placement:
       akash:
         pricing:
           web:
             denom: uact
             amount: 10000

   Note the amount value — this is price per block in uact.

2. Create deployment:

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

3. Wait for bids and query them:

   sleep 10
   akash query market bid list --owner <user-address> --dseq <dseq>

   Note the bid price from the provider.

4. Create lease:

   akash tx market lease create --dseq <dseq> --gseq 1 --oseq 1 \
     --provider <provider-address> --from <wallet> -y

5. Query lease details:

   akash query market lease get --owner <user-address> --dseq <dseq> --gseq 1 --oseq 1 --provider <provider-address>

6. Verify lease price:

   akash query market lease get --owner <user-address> --dseq <dseq> --gseq 1 --oseq 1 --provider <provider-address> -o json | jq '.lease.price'

7. Close deployment when done:

   akash tx deployment close --dseq <dseq> --from <wallet> -y

Expected Results:

• Lease price denom is uact (not uakt)
• Lease price amount is ≤ SDL specified price (provider bid at or below your max)
• BME is being used for compute payments

Proof to Submit:

• SDL pricing section showing uact denom and amount
• Lease query output showing matching denom (uact) and price ≤ SDL max

Test 3.3: Verify Provider Payment on Deployment Close

Objective: Verify provider receives correct ACT payment based on lease rate and duration

User Actions:

1. Record provider’s initial ACT balance:

   akash query bank balances <provider-address>

2. Create deployment:

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

   Note the DSEQ from the output.

3. Create lease and note the created_at block:

   sleep 10
   akash query market bid list --owner <user-address> --dseq <dseq>
   
   akash tx market lease create --dseq <dseq> --gseq 1 --oseq 1 \
     --provider <provider-address> --from <wallet> -y

4. Query lease to get created_at and rate:

   akash query market lease get --owner <user-address> --dseq <dseq> \
     --gseq 1 --oseq 1 --provider <provider-address>

   Write down:

   • lease.created_at (block number)
   • escrow_payment.state.rate.amount (uact per block)

5. Send manifest and let deployment run briefly (~2-5 minutes):

   provider-services send-manifest deploy.yml --dseq <dseq> --from <wallet>
   sleep 180

6. Close deployment:

   akash tx deployment close --dseq <dseq> --from <wallet> -y

7. Query lease state after close:

   akash query market lease get --owner <user-address> --dseq <dseq> \
     --gseq 1 --oseq 1 --provider <provider-address>

   Note the escrow_payment.state.withdrawn.amount value.

8. Check provider’s final ACT balance:

   akash query bank balances <provider-address>

Verification Math:

blocks_run = close_block - created_at
expected_payment = blocks_run × rate

Compare expected_payment to withdrawn amount — they should be approximately equal.

Example:

• created_at: 62100
• close_block: ~62430
• blocks_run: 330
• rate: 0.674561 uact/block
• expected: 330 × 0.674561 = ~222.6 uact
• withdrawn: 223 uact ✅

Expected Results:

• Lease state shows state: closed
• withdrawn amount is > 0
• withdrawn ≈ blocks_run × rate (within rounding)
• Provider ACT balance increased

Proof to Submit (either method):

Option 1 — Lease State (Recommended):

• Lease created_at block
• Lease rate
• Lease state after close showing withdrawn amount
• Calculation showing withdrawn ≈ expected

Option 2 — Provider Balance:

• Provider ACT balance before deployment
• Provider ACT balance after close
• Confirmation balance increased

We recommend Option 1 during busy testnet periods, as it isolates your specific lease payment. Provider balance can change from multiple concurrent deployments, making it harder to attribute the increase to your specific deployment.

Summary

Note: Provider burn-act (ACT → AKT conversion) is functionally identical to user burn-act tested in Category 2. Since provider accounts are standard Cosmos accounts, no additional burn testing is required here.