Bittensor Glossary

An independent reference to Bittensor’s terminology, mechanisms and economics. Clear explanations of how the network works, from subnet incentives to decentralized intelligence.

25 terms · Reviewed 11 October 2026 · Primary sources throughout

Network fundamentals

Bittensor

A network that coordinates the production and evaluation of digital services through independent subnets. Miners perform the work, validators assess it, and the Subtensor blockchain records participation and distributes incentives. The work happens primarily off-chain; the blockchain provides the shared accounting and coordination layer.

Bittensor — primary source ↗

Subnet

An independent incentive market within Bittensor, identified by a network identifier, or netuid. A subnet defines the work miners perform and how validators assess it. Non-root subnets have their own alpha tokens and TAO–alpha liquidity pools. Subnets can serve different purposes, including inference, storage and predictions.

Subnet — primary source ↗

Metagraph

A structured view of a subnet’s registered participants and their on-chain state. It exposes information such as participant identities, stake, validator permits, incentives, emissions and advertised endpoints. Developers use it to inspect the network; it is a record of protocol state, rather than an independent audit of service quality.

Metagraph — primary source ↗

Coldkey and hotkey

Bittensor separates financial ownership from day-to-day operation. A coldkey controls funds and signs actions such as transfers, staking and registration. A hotkey identifies a participant and signs operational actions such as submitting weights. One wallet can contain several hotkeys; protecting the coldkey remains essential even when operational keys are used separately.

Coldkey and hotkey — primary source ↗

Participants and incentives

Miner

A registered participant that produces the work requested by a subnet’s incentive mechanism. Depending on the subnet, this might mean generating model outputs, supplying compute or delivering another digital service. Validators evaluate that work, and protocol incentives determine the miner’s reward. Mining here is not simply hashing to produce blockchain blocks.

Miner — primary source ↗

Validator

A subnet participant that evaluates miners and submits relative scores, called weights, to the chain. Participation in consensus requires the relevant validator permit and stake conditions. Validators receive dividends and share them with their stakers after deducting their take—the fraction of rewards the validator retains. These subnet evaluators are distinct from the authorities responsible for blockchain block production.

Validator — primary source ↗

Subnet owner

The account that owns a registered subnet and manages its protocol configuration. The owner defines the incentive mechanism, supports miner and validator participation, and sets permitted subnet parameters. An owner receives a protocol-defined share of participant emissions, but ownership alone does not demonstrate that the subnet produces useful services or customer revenue.

Subnet owner — primary source ↗

Registration

The on-chain process that admits a hotkey to a subnet and assigns it a participant identifier, or UID. Registration costs and conditions depend on the subnet. A full subnet can replace an existing participant according to pruning rules. Some configurations lock part of the registration payment as miner collateral rather than treating all of it as an entry cost.

Registration — primary source ↗

Incentive mechanism

The rules connecting a subnet’s desired output to evaluation and rewards. A mechanism defines the miner task, the interaction between miners and validators, and the scoring model. Miners optimize for those scores, so mechanism design matters: rewarding a benchmark does not automatically mean rewarding the outcome an external customer needs.

Incentive mechanism — primary source ↗

Tokens, staking and liquidity

TAO

The native token of the Subtensor blockchain, commonly represented by τ. TAO pays transaction fees, supports staking and provides the common trading counterpart for subnet tokens. One TAO equals one billion rao, its smallest accounting unit. TAO and a subnet’s alpha token are different assets with different roles and valuations.

TAO — primary source ↗

Alpha tokens

The subnet-specific tokens introduced with Dynamic TAO. Each non-root subnet has its own alpha, used for participant rewards and subnet stake, and traded against TAO in its pool. Alpha balances from different subnets are not interchangeable. A quoted alpha price is a market exchange rate, not a direct measure of the subnet’s service quality.

Alpha tokens — primary source ↗

Dynamic TAO

The architecture that introduced subnet tokens and markets for exchanging them with TAO, replacing the earlier root-validator allocation model. Subnet token markets contribute to network emission allocation, while Yuma Consensus evaluates participants inside subnets. The original dTAO paper explains the design; current documentation describes subsequent changes to pool mechanics and emission rules.

Dynamic TAO — primary source ↗

Staking

Allocating funds to a validator’s hotkey on a particular network. On a non-root subnet, staking swaps TAO for the subnet’s alpha through its pool and credits an alpha stake position; unstaking reverses that trade. Root staking uses TAO directly. Rewards, exchange rates, fees and execution conditions are separate considerations.

Staking — primary source ↗

Delegation

Supporting a validator with stake without operating its evaluation software yourself. Delegators participate in the validator’s reward stream, after deducting the validator’s take (its retained share of rewards), and their stake contributes to its consensus weight under the protocol’s rules. Delegation does not remove exposure to token prices, pool execution conditions or the validator’s performance.

Delegation — primary source ↗

Root network

The special network identified by netuid 0. It accepts TAO stake directly and has no miners, subnet alpha token or miner-evaluation workload. Root stake contributes to validator stake weight across subnets through a protocol weighting factor. Root stake earns cross-subnet dividends through a validator’s basket, with ownership recorded as beta shares.

Root network — primary source ↗

Beta shares

A share count in one validator’s root basket, which holds subnet tokens and may hold TAO. Beta represents a proportional claim on that basket rather than a new network currency. A share count and its TAO value are different: prices can change the value without changing the count. Beta from different validators represents different baskets.

Beta shares — primary source ↗

Subnet liquidity

The TAO and alpha reserves available in a subnet’s trading pool. These reserves support the swaps used for staking and unstaking. Current pools use weighted automated market maker mechanics, with protocol liquidity injections handled separately from user trades. Deeper liquidity generally reduces a given trade’s price impact; it does not guarantee stable prices or successful services.

Subnet liquidity — primary source ↗

Price impact and slippage

Price impact is the change in execution price caused by your own trade against a pool. Slippage is additional movement between the expected and actual execution, including other trades arriving first. A displayed spot valuation therefore differs from what an exit may realize. Protocol swap quotes and price limits address these execution conditions.

Price impact and slippage — primary source ↗

Consensus and network mechanisms

Yuma Consensus

The subnet-level mechanism that combines validators’ miner evaluations with stake weight to determine incentives and dividends. In the standard path, scores above the stake-supported consensus level are clipped before rewards are calculated. Yuma coordinates assessments of useful work; it does not produce or finalize blockchain blocks, which use a separate consensus mechanism.

Yuma Consensus — primary source ↗

Validator weights

Relative scores submitted by validators for miners within an incentive mechanism. The chain applies the subnet’s weight rules before using these scores in consensus. Weights represent an evaluator’s assessment rather than a token transfer. Their usefulness depends on what is tested, how testing resists manipulation, and how recently the assessment was made.

Validator weights — primary source ↗

Commit-reveal

A mechanism that conceals validator weights before they become publicly usable, making immediate copying harder. In the current timelock path, submitted weights are encrypted and the chain reveals them automatically when the designated randomness round arrives. It is subnet-configurable; protection depends partly on miner rankings changing during the concealment period.

Commit-reveal — primary source ↗

Liquid alpha

A configurable mechanism that adjusts how quickly validator–miner bonds respond to changes in evaluations relative to consensus. These bonds are accounting relationships used to calculate validator dividends, not financial debt. Liquid alpha varies their smoothing rate for each pair; it is not a tradable token. It operates only when both liquid alpha and the Yuma3 consensus path are enabled.

Liquid alpha — primary source ↗

Emissions

New tokens issued by the protocol to support network incentives. TAO allocation uses smoothed subnet alpha prices, adjusted for withheld miner incentives and an emission gate that reduces small allocation shares. Alpha accumulates for distribution to subnet participants. Pool liquidity and participant rewards are separate flows. Emissions are protocol subsidies, so they should not be presented as revenue paid by customers.

Emissions — primary source ↗

Tempo and epoch

A tempo is the subnet’s configured interval, measured in blocks, between reward-distribution epochs. At an epoch boundary, the chain resolves evaluations and settles accumulated participant emissions. Subnets can use different intervals, and scheduling can defer settlement. An explorer’s per-epoch payout therefore should not be mistaken for a continuous per-block payment.

Tempo and epoch — primary source ↗

Halving

A reduction in the protocol’s token issuance rate when total issuance reaches a supply threshold. TAO halvings follow issuance milestones rather than a fixed calendar; recycling can affect when those milestones are reached. Subnet alpha tokens have their own issuance schedules. A lower issuance rate is a protocol event, not a prediction of market price.

Halving — primary source ↗

About this reference

Definitions draw on current Bittensor documentation and primary protocol material. Runtime documentation takes precedence over original design papers where mechanisms have changed. Subnet settings vary, and protocol rules evolve; follow each source for implementation details.

Token prices, protocol incentives and customer demand measure different things. This reference explains the mechanisms without treating market prices or emissions as evidence of commercial adoption.

Start with our introduction to Bittensor → · Suggest a correction