Table of Contents
Bittensor’s Subtensor has merged Release 487 into its main development branch, adding a prepaid billing system for subnet services and support for quantum-resistant wallets. The changes introduce a way to turn service purchases into subnet alpha burns, alongside new options for signing transactions and rotating account keys.
The merged upgrade brings together Gamma service credits, post-quantum account authorization, and changes to staking delegation, dividend accounting, and emissions controls. Gamma and the new wallet authorization modes default to disabled, with separate administrative steps required to activate them.
At the time of writing, Subtensor’s published releases still listed Runtime 486 as the latest release. The merge establishes that the code has entered the main branch, rather than confirming that the new features are available on Bittensor mainnet.
How Gamma Turns Service Purchases Into Alpha Burns
Gamma gives each participating subnet its own dollar-valued service credits. A customer creates those credits by burning the subnet’s alpha, either from an existing stake position or by supplying TAO that buys and burns alpha without creating a stake position. One Gamma is minted for each dollar of alpha burned under the runtime’s valuation rules.
The credits are specific to their subnet. They cannot be redeemed for TAO or alpha, or transferred to another coldkey, the account that controls a customer’s funds. Customers can move Gamma between their own deposits on the same subnet.
Service discovery and billing use a separate hotkey, an operational signing key. Validators with a permit and subnet owners can publish a service URL and billing spender onchain. The URL points customers to information about available services, endpoints, and payment methods.
A customer funds a deposit associated with a hotkey, which signs service requests as an API key. The deposit’s authorized spender then submits charges onchain. Request authentication and service delivery remain the provider’s responsibility; the chain records and enforces spending against the prepaid balance.
The token flow differs from a direct payment to a provider. Alpha is burned when Gamma is created, and Gamma is destroyed when the service charges the deposit. Spending does not transfer TAO or alpha to the provider. The mechanism therefore connects purchases of subnet services to alpha destruction without making the credit balance a redeemable financial asset.
Customers can hold up to 64 deposits per subnet under one coldkey. Optional spending caps replenish continuously over 7,200 blocks, up to the configured limit, while setting a cap to zero pauses spending. An exhausted deposit stays open for refills.
Providers can submit up to 512 billing entries in one transaction. Each entry is charged in full or skipped, with separate events recording the outcome. Request references can connect those charges to individual service requests. A dedicated proxy lets a provider delegate billing without handing over broader account permissions.
Pricing and Activation Controls
Gamma’s dollar denomination depends on two inputs: the alpha token’s value in TAO and a TAO/USD oracle feed.
For minting, the runtime takes the lower of the subnet’s pre-trade alpha spot price and its Gamma reference price. That reference price falls immediately when spot falls but rises gradually when spot increases. The resulting TAO value is converted into dollars through an oracle appointed by root authority.
The accepted TAO/USD price also limits upward movement, while accepting downward adjustments immediately. Minting requires a feed no more than 300 blocks old. Together, these rules constrain how quickly rising token prices can increase the credits minted for a given quantity of burned alpha.
Gamma requires both network-wide and per-subnet enablement. The launch sequence calls for installing the upgrade with Gamma off, configuring the oracle, checking its feeds, and then enabling the system globally. Subnet owners can configure their own enablement setting while the global switch remains off.
Disabling Gamma stops new minting but leaves existing deposits available to spend, move, and close. The implementation also includes runtime mint quotes, deposit and service queries, Python SDK support, and commands for funding and managing balances. Mint previews and minimum-output protection let customers inspect and constrain a funding transaction before submitting it.
Quantum-Resistant Signatures and Rotating Keys
The wallet changes add three post-quantum signing options: ML-DSA-65, Falcon-512, and Falcon-1024. They also introduce optional rotating accounts for those schemes and for the existing Sr25519 and Ed25519 signature types.
The wallet implementation separates the choice of signature scheme from the choice of account mode. Standard ML-DSA and Falcon wallets use permanent SS58 account identities without a registration deposit. Hashed wallets retain their account identity, balances, permissions, and receiving addresses while their signing keys rotate.
Registering a hashed account permanently reserves 0.2 TAO from the registration payer, who can be a sponsor. Ordinary transaction fees are separate. Key rotation occurs when a valid transaction reaches dispatch, even if the operation it attempts fails. Merely submitting a transaction or having it accepted into the transaction pool does not advance the signing authority.
Existing standard Sr25519 and Ed25519 accounts remain valid. Using hashing or rotating their keys does not make their classical signatures quantum-resistant; that property comes from selecting a post-quantum signature scheme.
Release 487 integrates the wallet modes with transfers, staking, validator operations, coldkey and hotkey management, proxies, multisig, orders, contracts, and native EVM calls. Transaction creation requires compatible signers. Under the release’s integration rules, arbitrary message signing and HTTP authentication remain unsupported for ML-DSA and Falcon, which affects applications that use wallet signatures outside onchain transactions.
Hashed and post-quantum authorization are controlled, which defaults to disabled. Enabling the runtime functionality and updating client-side signing tools are therefore distinct parts of making the new account types usable.
Delegated Staking, Dividends, and Emissions
Other changes narrow or extend the authority that account owners can delegate through proxies.
It allows conviction-lock management without permission to add, remove, or transfer stake. That authority can still reduce the stake available for unstaking or enable perpetual locking. Moving a lock between hotkeys owned by different coldkeys forfeits accrued conviction, while clearing perpetual mode resumes decay.
The narrower proxy remains available when an owner wants a delegate to claim dividends without broader staking authority.
Restricted proxies can no longer create deferred proxy announcements. The upgrade also invalidates pre-upgrade announcements while retaining removal and deposit recovery.
Basket accounting changes apply consistent valuation to existing holdings and incoming dividends when minting shares. Pending dividends are settled before changes to root stake, basket ownership, or basket composition, with credits preserved for retry if settlement cannot complete. Price exponential moving averages are also updated for every live dynamic subnet, including those currently ineligible for emissions.
The release enables nonzero burn and recycle emission shares, subject to a combined 33% cap and existing constraints on owner, validator, miner, and root shares. This is a separate allocation control from Gamma’s service-credit burns. It governs emission shares rather than customer purchases of credits.
For maintainers, targeted benchmark runs can select individual runtime modules and functions instead of measuring the entire scope. The tooling records the source commit and measurements, preserves completed results across later failures, and applies only completed results matching the current pull-request revision.
