Gamma service credits + quantum-resistant wallets · Upcoming
Gamma gives subnets a way to charge for services in dollar-valued credits. Customers fund a deposit by burning subnet alpha, use a hotkey as an API key, and authorize a service's spender to charge that deposit for usage. Service demand becomes an alpha burn, while customers can budget their usage in dollars.
One Gamma is minted for each dollar of alpha burned under the runtime's pricing rules. Credits belong to a specific subnet. They cannot be transferred to another coldkey or redeemed for TAO, alpha, or dollars. Each service decides whether to accept Gamma and how much to charge.
This page covers the proposed Release 487, including Gamma and quantum-resistant wallets. Runtime deployment and feature activation are separate steps.
Subnet owners and validators with a permit can publish a service URL and a billing spender on chain. The URL points to a document describing the service's endpoints and payment methods. Customers select its published spender when opening a deposit.
# Replace 51 and SERVICE_HOTKEY with the subnet and service you choose
btcli wallet new-hotkey -H API_KEY
btcli query services --netuid 51
# Buy and burn alpha, naming the service and a 20 Gamma daily spend cap
btcli gamma mint --netuid 51 --hotkey API_KEY --amount-tao 10 \
--service-hotkey SERVICE_HOTKEY --daily-spend-cap-gamma 20
# Or burn alpha already staked to VALIDATOR
btcli gamma mint-with-stake --netuid 51 --hotkey API_KEY \
--origin-hotkey VALIDATOR --amount-alpha 100 \
--service-hotkey SERVICE_HOTKEY --daily-spend-cap-gamma 20Mint previews quote the expected credits and apply minimum-output protection, with a 5% tolerance by default. The result reports exact decimal amounts for the alpha burned, its TAO value, and the Gamma minted, together with the deposit's spender address and optional daily spend cap.
The coldkey owns the credits and can hold up to 64 deposits per subnet. It can refill them, move credits between its own deposits on that subnet, change a spender, and close empty deposits. Spending a deposit down to zero leaves it open for refills; moving its entire balance closes the source.
An optional daily spend cap replenishes continuously over 7,200 blocks, up to the cap. It does not reset at midnight. A zero cap pauses spending. Set the spender and cap when minting to establish the terms from the start; refilling an existing deposit checks any explicitly supplied terms against its current configuration.
btcli gamma show --netuid 51 --hotkey API_KEY
btcli gamma set-cap --netuid 51 --hotkey API_KEY --daily-spend-cap-gamma 0
btcli gamma set-spender --netuid 51 --hotkey API_KEY --service-hotkey SERVICE_HOTKEYProviders can bill up to 512 entries in one transaction. Each entry spends its full amount or is skipped, with events reporting the result and an optional request reference for reconciliation. A GammaSpend proxy lets a provider delegate billing without giving the billing key broader account permissions.
The spender is trusted to bill for the service: the chain enforces the deposit's balance, spender, and cap, but does not verify service delivery. Spending destroys Gamma and pays no TAO or alpha to the spender. The alpha burn happens when the customer funds the credits.
Minting values alpha at the lower of its pre-trade spot price and a subnet Gamma price that falls immediately with spot but rises gradually. A root-appointed oracle converts that TAO value to dollars. Its accepted TAO/USD price has bounded upward movement, and minting requires a feed no older than 300 blocks, about one hour.
TAO value = alpha burned × min(Gamma price, pre-trade spot price)
Gamma minted = TAO value × accepted TAO/USD priceGamma starts disabled. Root must enable it network-wide, and the subnet must enable its own gamma_enabled setting. Turning either switch off stops new mints; existing deposits can still be spent, moved, and closed. Dissolving or pruning the subnet removes its credits without redemption.
The Python SDK and CLI include mint quotes, deposit balances and spending allowances, service discovery, and detailed mint and billing results. See the Gamma guide for the full deposit lifecycle and coldkey-swap behavior, and the services guide for publishing a service.
V487 adds ML-DSA-65, Falcon-512, and Falcon-1024 wallets alongside Sr25519 and Ed25519. All five schemes support standard fixed keys or optional key rotation. Standard post-quantum wallets use familiar SS58 addresses and can receive TAO and sign without account registration, a sponsor, or a registration deposit.
# Standard post-quantum wallets
btcli wallet create --crypto-type ms
btcli wallet create --crypto-type falcon512
btcli wallet create --crypto-type falcon1024
# Add --type hashed for rotation; sr and ed support it too
btcli wallet create --crypto-type ms --type hashed
btcli wallet create --crypto-type falcon512 --type hashed
btcli wallet create --crypto-type falcon1024 --type hashed| Wallet | Address to share | Account registration |
|---|---|---|
| Standard Sr25519 / Ed25519 | SS58 | None |
| Standard ML-DSA / Falcon | SS58 | None |
| Rotating, any of the five schemes | tao_ receiving address | Required; 0.2 TAO permanent reserve by default |
--crypto-type chooses the signature scheme and --type hashed chooses rotation. Standard is the default account mode. Save the scheme and mode with the recovery phrase: using a different choice restores a different account. Existing accounts do not change type automatically.
A rotating wallet keeps its account identity, balances, permissions, and receiving addresses while its signing key changes. Rotation occurs when a valid transaction reaches dispatch, even if the operation fails. Submission or acceptance into the transaction pool alone does not rotate authority. Recovery reads the finalized counter and derives the current key from the same recovery phrase.
The tao_ receiving address contains the public descriptor needed for registration. A transfer can register a rotating recipient atomically, with explicit sponsorship consent for the sender's permanent registration reserve (default 0.2 TAO), separate from the transfer and transaction fees. Sudo can change this shared deposit for future registrations; existing reserves remain unchanged. Registration defaults to MEV Shield. Register and wait for finalization before publicly sharing a new rotating account or assigning it roles.
Rotation does not make Sr25519 or Ed25519 signatures quantum-resistant. Choose ML-DSA or Falcon for post-quantum signatures. Standard ML-DSA and Falcon recipients need no registration or sponsorship.
The new wallets integrate with transfers, staking, neuron and validator operations, coldkey and hotkey operations, proxies, multisig, MEV Shield, orders, contracts, and native EVM calls. Normal fees and operation-specific deposits still apply. Safe multisig, derivative, and pure-proxy accounts use addresses that prevent direct classical signing from bypassing the intended members or parent, without requiring account registration. Their addresses differ from legacy accounts.
Existing Sr25519 and Ed25519 wallets keep their addresses and signed-v4 transaction format. Metadata-aware clients can decode the new transactions, but signing requires compatible wallet software. Hardware wallets and browser extensions need explicit support for the selected scheme. ML-DSA and Falcon wallets approve limit orders through signed authorize_order transactions; arbitrary message signing and HTTP authentication are not supported for these schemes.
Ethereum transactions continue to use ECDSA wallets. Associating one with a native neuron does not merge the wallets or make ECDSA quantum-resistant. Registered rotating accounts can use protected EVM aliases for native calls. Standard EVM gas behavior is preserved, including the 21,000 gas limit for plain transfers; alias lookups are metered through Frontier's external resource accounting.
See the wallet guide for recovery, safe account modes, registration sponsorship, and supported signing interfaces.
A new Lock proxy permits only lock_stake, move_lock, and set_perpetual_lock. It can manage conviction locks without permission to add, remove, or transfer stake. Locking still affects what can be unstaked, and moving a lock between different coldkey owners forfeits conviction. Existing Staking proxies gain claim_root and claim_root_with_hotkey; RootClaim remains the narrower grant.
Restricted proxies can no longer create deferred proxy announcements. Announcements from before the upgrade are invalidated, while removal and deposit recovery remain available. NonCritical proxies no longer permit EVM calls.
Basket dividend shares use consistent valuation for existing holdings and incoming dividends, preserving escrow yield for existing shareholders. Pending dividends settle before root stake, basket ownership, or composition changes, with credits retained for retry when settlement cannot complete. Settlement weights follow each hotkey's pending credits and holdings and refund to actual work.
Subnets can allocate nonzero emission shares to burn and recycle, up to a combined 33%. Existing owner, validator, miner, and root-share constraints remain in force, and partial updates preserve omitted allocations. The emission weights guide and proxy guide cover the updated controls.
Gamma and wallet activation are separate controls. Gamma needs its global and subnet switches plus a fresh oracle price. The root-controlled AdminUtils.sudo_set_hashed_accounts_enabled switch defaults to disabled and gates all rotating wallets and all standard ML-DSA and Falcon wallets. Ordinary standard Sr25519 and Ed25519 signing is unaffected.
Use matching SDK, CLI, and native core releases, refresh metadata after the runtime upgrade, and rebuild offline transaction payloads prepared for the previous runtime. Obtain fresh fee quotes for the chosen signing and submission route. HTTP-auth receivers using Sr25519 or Ed25519 should configure trusted sender schemes with http_auth.configure_verifier; Shield carrier fee estimation now requires the actual call.
Maintainers can run benchmarks for selected pallets and exact functions, retain completed measurements across later failures, and apply only results matching the current PR head. The benchmark guide explains the selection and patch workflow. Gamma, service, and order weights currently include documented local calibration; dedicated reference measurements remain outstanding. The new burn/recycle increment does not resolve the separate full-Null capacity finding.