Burn Mint Equilibrium On Akash

Motivation

AKT is the native cryptocurrency of Akash Network and was initially conceived as the sole payment method. When a lease is established, tenants and providers agree on a price in AKT. These leases are open-ended, continuing until either party terminates them. However, the fluctuating value of AKT presents a challenge. Participants typically anticipate stable pricing equivalent to USD, and AKT’s price instability compromises its utility as a payment mechanism.

To address this challenge, AEP-23 was proposed, approved, and implemented, introducing stablecoin payments alongside AKT. This system enables tenants to utilize whitelisted stablecoins, such as USDC, for both pricing and settlement. A portion of the hosting fees collected during settlement is distributed to AKT stakers, rewarding them for their role in securing the blockchain. While this stable payment solution significantly boosted revenue growth on the Akash network, it also led to a notable drawback: reduced demand for AKT, as the staking incentives proved insufficient to sustain the token’s value.

Maintaining the foundational role of AKT within the Akash ecosystem is crucial. Therefore, revitalizing demand for AKT while simultaneously ensuring stable settlement options is essential.

Goals

1. Restore AKT‑only settlement while preserving tenants’ stable USD experience.
2. Increase structural AKT demand and shrink effective float.
3. Make the mechanism sustainably neutral without hidden taxes; volatility and timing determine net burn/mint, not a fee.

Non Goals

1. Replace or modify consensus/security.
2. Depend on any single off‑chain venue; use diverse liquidity sources (Osmosis TWAP¹ and external oracle aggregation).

Burn-Mint-Equilibrium Overview

The Burn Mint Equilibrium (BME) is a tokenomic model designed to balance supply and demand between a volatile value-accruing token (like AKT) and a stable utility token used for transactions. Inspired by models like those in Factom, Helium, and algorithmic stablecoins, BME creates ongoing demand for the volatile token by requiring it to be burned for minting the stable token, while allowing the reverse process (burning the stable token to mint the volatile one) to maintain equilibrium via arbitrage. This prevents supply bloat, captures usage value in the volatile token, and encourages holding/staking.

In the context of Akash Network, the goal is to preserve stable USD-equivalent payments (building on AEP-23’s success in driving revenue growth) while revitalizing demand for AKT. Currently, AEP-23 allows tenants to use whitelisted stablecoins (e.g., USDC) for lease pricing and settlement, with a percentage of fees distributed to AKT stakers. However, this shifts demand away from AKT. A BME mechanism addresses this by introducing a native stable token backed algorithmically by AKT, making AKT essential for generating stable payment units.

Key Benefits for Akash

• Stable Payments Retained: Leases remain priced and settled in stable units, avoiding AKT volatility for users.
• AKT Demand Revitalized: Minting stable units requires burning AKT, creating buy-and-burn pressure proportional to network usage.
• Deflationary Potential: If network growth leads to more burns than mints, AKT becomes scarcer, benefiting stakers. Helium validated this as its native token HNT became net deflationary recently as adoption grew.
• Compatibility with AEP-23: This can extend the existing stablecoin system by integrating a native BME token as the primary or optional payment method, with fees still flowing to stakers.

Proposal

BME overhauls Akash network lease settlement and tenant payments, improving user experience and tokenomics.

Core Changes

• AKT for Lease Settlement: All leases settle in AKT.
• ACT for Tenant Payments: Tenants prepay with ACT, a non-transferable USD-pegged compute credit, generated by burning AKT. ACT is burned at settlement, and AKT re-minted to providers at the current price, automatically adjusting supply based on AKT demand.

Enhanced User Experience (UX)

• USD Quoting: Console and APIs display costs in USD.
• Flexible Payments: Tenants can pay with credit cards or AKT.
• Credit Card Payments Drive AKT Demand: Credit card payments trigger immediate AKT market buys, which are then burned to mint ACT.

Positive Token Effects

• Increased AKT Demand: Every dollar spent on compute boosts AKT demand.
• ACT as Supply Sink: Outstanding ACT reduces circulating AKT supply between top-up and payout.
• Net Burns from AKT Appreciation: AKT appreciation between top-up and payout results in a net burn of AKT.
• AEP-23 Take-Rate Eliminated: BME removes AEP-23 take-rates, re-centering the economic model on AKT.

Driving AKT Demand and Price Support

• Immediate AKT Market Buy: Every dollar spent on compute directly drives AKT demand.
• Outstanding ACT as Escrowed AKT (BME Vault): ACT held by users acts as escrowed AKT, removing it from liquid supply.
• Favorable Price Drift and Net Burns: If AKT price increases between top-up and settlement, a net burn of AKT occurs at payout.
• Batch Top-ups Deepen AKT Sink: Larger, infrequent top-ups increase outstanding ACT, deepening the AKT sink and reducing circulating supply.

Economic Walkthrough

• Assume the average tenant keeps 7 days of runway in ACT.
• If monthly gross new top‑ups are $10M, that’s an immediate market buy of ~8.77M AKT at USD 1.14² and removal from float until spent.
• If the blended settlement price later averages $1.25, providers receive ~10M USD / 1.25 = 8.00M AKT.
  • Net monthly burn: ~0.77M AKT plus the time‑in‑vault float reduction during the month.

Tokens & Denoms

• AKT (existing): staking token & settlement currency.
• ACT (new): Akash Compute Token.
  • Peg: 1 ACT ≈ $1 of compute credit.
  • Decimals: 6 (denom uact) to match cosmos conventions.
  • Non‑transferable: balance is soulbound to the funding account (tenant, org, or project).
  • Use: only to pay Akash lease invoices; cannot be sent peer‑to‑peer or traded.

Core Mechanics

Let:

• \(P_t\) = 30‑min TWAP AKT/USD price at time t.
• \(B_t\) = AKT burned to mint ACT at time t.
• \(A_t\) = ACT minted at time t.
• \(S_t\) = AKT minted to providers at settlement time t.
• Spread parameters initially 25 bps

Mint ACT (tenant top‑up)

• Tenant supplies AKT or pays by card:
  • AKT path: user sends \(B_t\) AKT → protocol burns (moves to BME vault) → mints
    \(A_t = B_t \cdot P_t\) ACT
  • Card path: Console market‑buys AKT for $X on Osmosis/aggregators, receives \(B_t\) AKT, sends to chain → same burn/mint as above; ACT minted equals net $ received so tenants see precise dollar value.

Settle (provider payday)
When an invoice for A ACT is due, the protocol:

1. Burns \(A\) ACT, and,
2. Mints \(S = \frac{A}{P_{settle}}\) AKT to the provider.

Net supply effect per dollar of usage

• At top‑up: burn \(\frac{1}{P_{mint}}\) AKT.
• At settlement: mint \(\frac{1}{P_{settle}}\) AKT.
• ΔSupply (AKT) = \(\frac{1}{P_{mint}} - \frac{1}{P_{settle}}\).
  • If price rises while credits are outstanding → net burn.
  • If price falls → net mint.
• Between events, AKT float is reduced by the amount sequestered in the BME vault against outstanding ACT.

Concrete Example

• Tenant tops up 1,000 USD ⇒ burn 877.192982 AKT², mint 1,000 ACT.
• If settlement occurs at 1.50 USD ⇒ mint 666.666667 AKT to provider ⇒ net −210.526316 AKT (deflation).
• If settlement at 0.90 USD ⇒ mint 1,111.111111 AKT ⇒ net +233.918129 AKT (inflation). (These deltas balance over time; outstanding ACT acts like an elastic buffer.)

Architecture

Modules

x/bme Burn‑Mint Equilibrium module

• Vault accounting:

  • “Burn” moves AKT into a BME vault module account (circulating supply goes down).
  • The vault maintains a Remint Credit ledger so provider payouts first consume burned AKT; only if short, mint new AKT. This preserves the hard cap framing at the net level.

• Invariants & queries:

  • OutstandingACT(): total ACT supply.
  • VaultAKT(): AKT in vault with remint credits.
  • Collateral ratio: \(CR=\frac{VaultAKT \cdot P}{OutstandingACT}\)
  • Governance thresholds for circuit breakers

• EndBlocker: batch‑settles invoices (e.g., every block, or 1–5 min epochs).

  (Cosmos SDK natively supports bank burns and module accounts; minting can be customized via x/mint’s MintFn to draw down remint credits first.)

x/act Account‑bound compute credits

• Non‑transferable balances keyed by owner (EOA, org, project).
• Messages: MsgMintACT, MsgBurnACT.
• Spend path is only callable by x/market during settlement.

x/oracle Price feeds

• Primary: Osmosis AKT/USDC TWAP (e.g., 30‑min, 0.1% outlier rejection).
• Secondary: external oracle (e.g., Pyth/Chainlink via IBC or relays) with fallback rules & medianization. (Osmosis TWAP exists; Pyth has Cosmos‑SDK deployments; pattern is standard)

console Payments UX (AEP‑31 aligned)

• Card on‑ramp (existing roadmap item) performs immediate AKT buy and calls MsgMintACT so tenants always see $‑exact credit. (Credit‑card payments feature tracked as AEP‑31)
• Auto‑top‑up & batch recharges (configurable days‑of‑runway).

x/market Leases & settlement

• Quotes remain USD‑first in the UI; on chain, settlement pays providers in AKT by consuming ACT.
• Providers optionally auto‑stake a % of payouts (off by default).
• AEP‑23 brought stable payments and take‑rates; with BME we keep the stable UX but remove take‑rates and settle AKT‑only.*

Settlement loop (system flow)

Preconditions

• Lease exists, invoice is due, amount matches act_spend (or ≤ remaining).
• from has ≥ act_spend ACT.
• Oracle healthy (settlement price).
• Circuit breaker may slow but should not block normal settlement unless in extreme halt mode.

Flow

1. Oracle read (settlement price)

• Fetch \(P_{settle}\) = AKT/USD TWAP.

2. Burn ACT
   • act.Burn(from, act_spend)
   • OutstandingACT = act_spend
3. Compute AKT owed
   • akt_out = floor(act_spend / P_settle) (6-decimals)
4. Pay from the vault (deflationary first)
   • use_vault = min(akt_out, RemintCredits)
   • If use_vault > 0:
     • Decrease RemintCredits -= use_vault
     • bank.SendCoins(BME_VAULT:provider, use_vault)
   • shortfall = akt_out - use_vault
5. Inflationary mint for any shortfall
   • If shortfall > 0:
     • mint.MintCoins(provider, shortfall)
     • (No change to VaultAKT; net increase to circulating supply by shortfall.)
6. Finalize lease accounting
   • Mark invoice (partial/complete) as paid for act_spend.
   • Update provider’s earnings ledger.
7. Events & logs
   • event_bme_spend {lease_id, from, provider, act_burn: act_spend, akt_out, P_settle, vault_paid: use_vault, minted: shortfall}
8. Post-conditions / Invariants
   • ACT supply decreased by act_spend.
   • Provider receives akt_out AKT.
   • Net AKT supply changes by: Δ = shortfall - use_vault_vanish (Intuition: if use_vault = akt_out → no inflation, and circulating AKT only re-enters; if price rose since mint, use_vault < akt_in_at_mint, so net burn already happened at the earlier step.)

Failure cases

• Oracle unhealthy → ErrOracle.
• Insufficient ACT → ErrInsufficientACT.
• Lease invariants mismatch / double-spend attempt → ErrInvoiceState

BME Vault

BME Vault is a module account and a ledger (“remint credits”) that holds the AKT created when tenants fund ACT (their dollar-pegged compute credits). Those AKT are out of circulation until providers are paid. At payout, the protocol re-issues AKT (up to what’s owed) using the oracle price at settlement. Net supply moves only by the difference between the AKT burned at top-up and the AKT reminted at payout.

Benefits

1. Structural buy-pressure: Every dollar of usage triggers an AKT market buy (card → buy AKT → burn to mint ACT). That’s constant demand for AKT.
2. Reduced circulating supply (scarcity): The AKT tied to outstanding ACT sits in the vault, not tradable, shrinking liquid float until workloads are settled.
3. Automatic net-burn when price rises: If AKT appreciates between top-up and payout, fewer AKT are needed to pay the provider than were originally burned → net burn (deflationary).
4. Soft landing when price falls If AKT declines: the vault first uses its “remint credits.” Only if that’s insufficient does the system mint the shortfall (inflationary). Circuit-breakers can slow new ACT mints during severe drawdowns—no fee/take-rate needed.
5. Stable UX with AKT-only settlement: Tenants always see exact $ funding; providers always receive AKT. The vault is the bridge that makes those two things compatible.

Key Metrics to Watch

• Outstanding ACT: the protocol’s dollar liability to providers.
• Collateral Ratio (CR): the vault’s AKT value vs. that liability:

• If CR > 1: the vault’s AKT is worth more than the credits outstanding (healthy buffer; likely net burns on payout).
• If CR < 1: the vault will need to remint some AKT on payout (inflationary), so circuit-breakers can kick in to protect the system.

Concrete Example

• Tenant funds 10,000,000 USD in ACT by burning AKT priced at 1.14 USD² → vault receives/burns 8,771,929 AKT.

• If payouts happen at 1.25 USD, the protocol remints $10,000,000 / 1.25 = 8,000,000 AKT to providers.

  • Net effect: −771,929 AKT (deflation).

• If payouts happen at 0.90 USD, the protocol needs 11,111,111 AKT; it reissues the 8.77M from the vault and mints the ~2.34M shortfall (inflation). While those credits are outstanding, that 8.77M AKT is out of circulation. If spot drifts up to $1.20 before payout, the vault’s value vs. the liability becomes:

  \(CR=\frac{8.77M × 1.20}{10M}≈1.053\) - a ~5.3% buffer that will materialize as net burn on payout.

Implementation notes

You can implement the “burn” either as a true burn and later mint, or as escrow in a non-spendable module account with a remint-credits ledger. In both cases, circulating supply drops immediately and only changes net by the price-timing delta.

Because the vault is transparent (on-chain), you get auditable metrics: VaultAKT, OutstandingACT, CR, NetBurn24h/30d.

Risk controls

We avoid per‑lease take‑rates. Instead, we rely on design‑time controls:

• Oracle safety: dual‑feed medianization; TWAP windows (e.g., 30 min); max update drift; pause on disagreement > X%. TWAP mechanics documented by Osmosis.
• Circuit breakers: if \(CR<0.93~\) (configurable), temporary measures engage:
  • Slow mints (shorter settlement epochs),
  • Require new ACT mints to be ≥ N days of run‑rate (encourages batching),
  • If \(CR<0.90\), fallback: pause new ACT mints; tenants can still pay directly in AKT (UI reveals an “AKT direct” path) until CR recovers.
• Initial reserve (one‑time): seed the BME vault with a small AKT volatility buffer via governance/community pool (similar buffers have been budgeted in governance requests). This covers rare fast‑down moves without taxing leases.
• Optional micro‑spread (0–25 bps) on mint only: If governance wants a self‑healing buffer without “fees on providers,” apply a tiny haircut only at ACT mint (tenant side), and send the surplus to the BME vault. This is not a take‑rate on hosting fees and can default to 25 bps at launch.

Governance Parameters

1. Oracle Mechanism: The system utilizes a robust oracle mechanism to determine the precise value for transactions. This mechanism calculates a median price based on two sources: a 30-minute Time-Weighted Average Price (TWAP) from Osmosis, and an external oracle, also sampled over a 30-minute period. To ensure data integrity and prevent manipulation, any price outlier exceeding 1.5% from the median is automatically ignored, ensuring a stable and reliable valuation.

2. Settlement Epoch Options: To optimize for different operational needs, the system offers two distinct settlement epoch options:

   • Per Block Settlement (Fast): This option enables immediate settlement of transactions with every new block validated on the network. This provides the quickest possible finality for operations where speed is paramount.
   • Every 5 Minutes Settlement (Gas-Friendly): For scenarios where gas efficiency is a higher priority than instantaneous settlement, transactions can be batched and settled every five minutes. This approach helps reduce transaction costs by optimizing gas usage.

3. Circuit Breakers for Stability: To safeguard the system against extreme market volatility and maintain stability, two crucial circuit breakers are implemented:

   • CRwarn (Credit Ratio Warning): At a credit ratio of 0.95, a warning is triggered, signaling potential instability and prompting system administrators to monitor the situation closely.
   • CRhalt (Credit Ratio Halt): Should the credit ratio drop further to 0.90, a halt is initiated, temporarily suspending certain operations to prevent further destabilization and allow for corrective measures to be taken.

4. Mint/Settle Spreads: Initially, the system operates with a mint/settle spread of 25 basis points (bps). This spread represents the difference between the price at which new tokens are minted and the price at which they can be settled, contributing to the system’s economic model and liquidity.

5. ACT Expiry and Refundability: Akash Credit Tokens (ACT) are designed without an expiration date, ensuring that credits held by users remain valid indefinitely. Furthermore, ACT are fully refundable back to AKT (Akash Token) at the current oracle price. This feature provides flexibility and liquidity for ACT holders, allowing them to convert their credits back to the native token at any time based on the prevailing market rate.

6. Denomination of ACT: For precision in transactions and system operations, ACT is denominated in uact. The conversion rate is standardized as 1 ACT equal to 1,000,000 uact (1e6 uact), facilitating granular accounting and transaction processing within the ecosystem.

Developer Spec

Messages

MsgMintACT

Mint non-transferable ACT credits by removing AKT from circulation.

Purpose

• Turn AKT → ACT ($1 credits) at the mint TWAP price.
• Two UX paths collapse to the same on-chain flow:
  • AKT path: tenant funds with AKT directly.
  • Card path: console market-buys AKT off-chain and pays on-chain; chain still just sees AKT.

Message

MsgMintACT {
  // who provides AKT (tenant or console wallet)
  payer:   Address
  // whose ACT balance to credit (tenant/org/project)
  owner:   Address
  // AKT amount provided (mutually exclusive with usd_exact)
  akt_in:  sdk.DecCoin
     // optional: request “exact $X ACT”; keeper back-solves AKT
  usd_exact: sdk.DecCoin
  // optional metadata (invoice id, cc receipt id)
  memo: string?
}

Preconditions

• owner is a valid ACT account.
• Oracle is healthy (TWAP within drift limits; price freshness OK).
• Circuit breakers not blocking mints.
• If usd_exact is set, keeper must be able to pull or receive the corresponding AKT from payer.

Flow

1. Ante / auth
   • Verify payer signature (or valid feegrant/authz).
   • Collect fees, increment sequence.
2. Oracle read (mint price)
   • Fetch P_mint = AKT/USD TWAP (e.g., 30-min, medianized).
   • Reject if stale or outside deviation bounds.
3. Determine AKT to pull
   • If akt_in provided → akt_req = akt_in.
   • Else if usd_exact → akt_req = ceil(usd_exact / P_mint) (round up 6-decimals).
   • Guard: akt_req > 0.
4. Funds movement
   • bank.SendCoins(payer → BME_VAULT, akt_req uakt)
   • Increase RemintCredits by akt_req. (This is the book-entry saying “we can later re-issue up to this much without fresh inflation.”)
5. Mint ACT
   • act_out = floor(akt_req * P_mint) (6-decimals).
   • act.Mint(owner, act_out)
6. State updates
   • OutstandingACT += act_out
   • Recompute CR: (VaultAKT * P_ref) / OutstandingACT (P_ref can be P_mint or a moving ref).
7. Events & logs
   • event_bme_mint { payer, owner, akt_in: akt_req, act_out, P_mint }
8. Post-conditions / invariants
   • VaultAKT increased by akt_req.
   • OutstandingACT increased by act_out.
   • Circulating AKT effectively down by akt_req.

Failure Cases

• Oracle unhealthy → ErrOracle.
• Circuit breaker active (CR < halt) → ErrCircuitBreaker.
• Insufficient AKT from payer → ErrInsufficientFunds.

MsgBurnACT

Tenant burns unused ACT and receives AKT back at current price.

Purpose

• Let users unwind credits if they stop using compute.
• Keeps UX fair; also exercises the same safety path as settlement.

Message

MsgBurnACT {
  owner:      Address    // whose ACT to burn
  to:         Address    // who receives AKT (default = owner)
  act_burn:   sdk.DecCoin // ACT to convert back to AKT
}

Preconditions

• owner has ≥ act_burn ACT.
• Oracle healthy (refund price).
• Circuit breaker policy may throttle refunds only under extreme CR stress (configurable), but default is always allow.

Flow

1. Ante / auth
   • Verify owner (or authz).
2. Oracle read (refund price)
   • P_now = AKT/USD TWAP
3. Burn ACT
   • act.Burn(owner, act_burn)
   • OutstandingACT -= act_burn
4. Compute AKT to return
   • akt_out = floor(act_burn / P_now)
5. Pay from the vault first
   • use_vault = min(akt_out, RemintCredits)
   • If use_vault > 0:
     • RemintCredits -= use_vault
     • bank.SendCoins(BME_VAULT → to, use_vault)
   • shortfall = akt_out - use_vault
6. Inflationary mint for shortfall (if any)
   • If shortfall > 0:
     • mint.MintCoins(to, shortfall)
7. Events & logs
   • event_bme_burn_act { owner, to, act_burn, akt_out, P_now, vault_paid: use_vault, minted: shortfall }
8. Post-conditions
   • ACT supply reduced by act_burn.
   • AKT sent to to equals akt_out.
   • Net AKT supply changes only if shortfall > 0.

Failure cases

• Oracle unhealthy → ErrOracle.
• Insufficient ACT → ErrInsufficientACT.

Cross-cutting behavior (all three messages)

• Oracle safety

  • Use median(TWAP_osmosis, TWAP_external) with freshness checks.
  • Reject if feeds disagree > threshold (e.g., 1.5%) or stale.

• Circuit breakers

  • Monitor Collateral Ratio (CR) = (VaultAKT * P_ref) / OutstandingACT.
  • Warn below 0.95, halt new mints below 0.90 (settlements/refunds still allowed; governance may throttle refunds if CR is critically low).

• Events/metrics to expose

  • OutstandingACT, VaultAKT, RemintCredits, CR, NetBurn24h, NetBurn30d.
  • Per-tx: emitted prices, amounts, and whether payout used vault vs. new mint.

• Rounding rules

  • Favor tenant on mint (round ACT down very slightly); favor provider on settlement (round AKT down very slightly) to avoid over-pay; the residuals accrue to the vault as dust and improve CR over time.

• AuthZ / Feegrant

  • Allow org billing wallets or the console to act on behalf of tenants (auto top-ups).

One Concrete Flow

• Mint: Tenant tops up USD 1,000 @ P_mint = $1.14

  • Pull akt_req = 877.192982, send to BME_VAULT
  • Mint act_out = 1,000 ACT
  • RemintCredits += 877.192982

• Spend: Settle later @ P_settle = $1.50

  • Burn 1,000 ACT
  • Owe provider akt_out = 666.666667
  • Pay entirely from vault (use_vault = 666.666667)
  • RemintCredits = 210.526315 remaining
  • Net AKT still out of circulation: 210.526315 (which is the deflation)

• Refund (if tenant cancels remaining $X credits)

  • Same as spend: burn ACT, return AKT using vault first, mint only if needed.

State

• VaultAKT (module account balance) and RemintCredits (book‑entry of burned AKT available to re‑issue).
• TotalACT, per‑account ACT balances.
• CR view.

Invariants

• RemintCredits >= 0 except during a price‑crash path when circuit breaker logic governs shortfall; if RemintCredits < 0, only inflationary mint covers the difference (visible metric).

(Cosmos SDK’s bank/mint facilities support this pattern cleanly)

Provider & Tenant UX

Tenant (Console)

1. Add funds → choose card or AKT.
2. If card: pay $X → console buys AKT on Osmosis, sends to vault; chain mints X ACT.
3. See $ balance, low‑balance alerts, auto‑top‑up (batching default).

Provider

• Price as of today (USD‑first in UI).
• Receive AKT each epoch.
• Optional “auto‑stake N%” toggle.

Interoperability with AEP‑23 & migration

• AEP‑23 kept: USD quoting, whitelisting, and the stable‑payment user journey in docs
• AEP‑23 changed: remove take‑rate on stable settlements, and disable USDC payouts to providers; all payouts are in AKT. The earlier discussions recorded per‑currency take‑rates; we eliminate them here.
• Data migration: existing escrowed stable balances in the console can be one‑time converted: buy AKT → burn → mint ACT at migration block’s oracle price.

Observability & Dashboard

• On‑chain: OutstandingACT, VaultAKT, RemintCredits, CR, NetBurn24h, NetBurn30d.
• Console: “AKT saved from circulation” badge; “Effective AKT purchased”; runway days; min/top‑up size.
• Provider: AKT payout history with oracle prices.

Security & Attack surface

• Oracle manipulation: use multi‑feed medianization with TWAP; cap per‑block price move; pausable by governance multisig in emergencies.
• Liquidity stress: perform console buys via RFQ/aggregator (Osmosis primary) with max slippage. (Osmosis as Cosmos liquidity hub.
• Module integrity: bank burn/mint auditing with supply invariants in end blockers.

Rollout plan

1. Testnet phase (4–6 weeks): enable x/bme and x/act with faucets; fuzz settle/mint under varying volatility; run oracle chaos tests.
2. Shadow launch: mainnet with 25 bps spreads; circuit breakers armed; small governance‑seeded vault buffer.
3. Full launch: migrate console to ACT top‑ups; switch payouts to AKT‑only; deprecate USDC payouts (keep USDC funding path only via card → AKT buy → ACT).
4. Post‑launch: expose metrics; if CR drifts lower in stress, governance can nudge mint‑side bps to rebuild buffer without taxing providers or re‑introducing take‑rates.

Quick FAQ

• Is this deflationary? Over any window where AKT appreciates between top‑up and settlement, yes—net burns occur. In all cases, outstanding ACT removes AKT from float until it’s paid out.
• What if AKT dumps? The seeded vault and circuit breakers cover shortfalls without taxing leases. Worst case, tenants pay AKT directly for a short window while CR recovers.
• Does this harm providers? No. Providers are paid AKT valued at the invoice’s USD amount using the settlement TWAP. No take‑rate applies to their payout.