Table of Contents
The Opentensor Foundation has introduced Gamma Tokens, a wallet-based payment standard that lets users and AI agents access Bittensor subnet services without opening separate accounts or obtaining a new API key for every provider.
Gamma turns a subnet’s alpha tokens into dollar-valued prepaid credits. Customers can fund those credits with TAO or existing alpha stake, then use a wallet signing key to request services from providers that adopt the standard. Every purchase of newly minted credits burns the relevant subnet’s alpha.
The system addresses a practical obstacle for applications built across Bittensor: inference, compute, and storage providers can each require their own registration, funding, and authentication process. Gamma gives participating subnets a common billing and access framework while leaving providers in control of their services and prices.
How TAO and Alpha Become Service Credits
Customers have two ways to fund Gamma. A customer can supply TAO, which buys and burns the target subnet’s alpha in one transaction without creating a stake position. Alternatively, the customer can burn alpha already held as stake on that subnet.
In both cases, the protocol calculates the burned alpha’s value in TAO and converts that amount into dollars using an onchain TAO/USD price feed. Alpha valued at $100 under those rules creates 100 Gamma credits.
The valuation uses the lower of the subnet’s alpha spot price before the transaction and a separate Gamma reference price. The reference price falls immediately with spot but rises gradually, at most doubling every 600 blocks. That limits how quickly a sudden alpha price increase can expand the credits minted from a burn.
The TAO/USD feed comes from an oracle appointed by Bittensor’s root authority. Its accepted price also falls immediately when the feed falls, while upward adjustments are limited to roughly 2% an hour. Minting requires a feed no more than 300 blocks, or about an hour, old.
Once minted, the credit balance is denominated in dollars rather than fluctuating with TAO or alpha. Providers still determine how much Gamma a service costs. The credits cannot be redeemed for dollars, TAO, or alpha, transferred to another coldkey, or spent on a different subnet. A coldkey is the account that controls the funds; it can move credits between its own hotkey deposits within the same subnet.
Wallet Keys Handle Access and Spending Controls
A Gamma deposit belongs to a coldkey and is identified by a hotkey, an operational signing key that authenticates service requests. Each deposit also names an authorized spender: the account permitted to deduct credits for the service.
The hotkey takes over the authentication role normally filled by a provider-issued API key. An application signs a request, and the provider’s spender charges the associated deposit onchain before delivering the service. The implementation work in PR #3283 was incorporated through merged PR #3300.
Customers can maintain up to 64 deposits per coldkey on each subnet, separating budgets for different applications or agents. They can change a deposit’s spender, move its balance to another hotkey, or top it up without replacing the signing key.
Optional daily spending caps replenish continuously over 7,200 blocks, up to the configured cap, rather than resetting at a fixed time each day. Setting the cap to zero pauses deductions. Providers can batch up to 512 billing entries in one transaction; each charge either succeeds in full or is skipped if authorization, balance, or spending allowance is insufficient.
The chain enforces those permissions and balances, while the provider handles the request and supplies the service. A named spender can charge a deposit without proving delivery onchain, so selecting the provider and controlling its allowance remain part of the customer’s setup.
How Service Billing Connects to Alpha Burns
The alpha burn happens when credits are created, before a customer consumes the service. Creation and spending produce separate onchain records, allowing applications to track funding and subsequent deductions rather than relying solely on a provider’s private billing ledger.
Spending the resulting Gamma destroys the credits rather than transferring them to the provider. The provider does not receive TAO or alpha from the deduction. The mechanism therefore routes service demand into alpha burns instead of creating a redeemable balance that an operator later cashes out.
In Opentensor’s example, an AI assistant could combine Chutes for inference, Lium for compute, and Hippius for storage using one TAO-funded wallet, once those providers support Gamma. The wallet would fund separate subnet-specific credit balances, not a single Gamma balance spendable interchangeably across all three.
Finding Providers and Enabling Payments
Alongside billing, Gamma introduces onchain service discovery. Validators with a permit and subnet owners can publish a service URL and its authorized spender. The URL points to a document describing what is offered, how applications connect, and which payment methods are supported.
That document can list conventional API endpoints or Model Context Protocol endpoints, which let AI applications connect to external tools and services. Developers and agents can use it to discover both a provider’s capabilities and the spender to authorize on their deposit.
Gamma is included in Runtime 488’s release history, which incorporates the earlier Gamma work and Release 488. Using it for a particular service requires network-wide and per-subnet enablement, a fresh oracle feed for minting, and support from the provider. The flags default to off, and each provider must adopt the standard before customers can use Gamma for its services.
The Gamma tooling provides mint quotes, deposit queries, and commands for funding balances, setting caps, and changing spenders. Turning off an enablement flag stops new minting without preventing existing deposits from being spent, moved, or closed.
