Category: Guides

  • Dynamic TAO Explained: How Alpha Tokens, Staking and Emissions Work

    Dynamic TAO Explained: How Alpha Tokens, Staking and Emissions Work

    Dynamic TAO connects Bittensor’s subnet markets to its incentive system. Understanding it means separating three things: the tokens you hold, the trades that create a stake position, and the rules that distribute new tokens. They interact, but none is a substitute for evidence that a service has paying customers.

    This guide reviews the protocol material available on 13 October 2026. It explains the current documented architecture rather than treating the original Dynamic TAO design as an unchanged specification. If you are new to the network, start with What is Bittensor?; the Bittensor Glossary provides shorter definitions.

    TAO, alpha and the purpose of Dynamic TAO

    TAO is the native token of Subtensor, Bittensor’s blockchain. A non-root subnet has its own alpha token, traded against TAO. Alpha from two different subnets represents two different assets, even if an interface uses similar symbols. An alpha token is not a share certificate in a company or a contractual claim on customer revenue.

    The Dynamic TAO whitepaper proposed using these markets to inform allocation between subnets, replacing the earlier root-validator voting model. Its constant-product pools and simple price-proportional allocation explain the original design. Subsequent runtime changes added different pool mechanics and allocation filters. The paper is useful background; current implementation material determines how the mechanism works today.

    What staking actually does

    On a non-root subnet, staking exchanges TAO for alpha through the subnet’s pool. The resulting alpha becomes stake associated with your coldkey, the ownership key, and a validator’s hotkey, its operational identity. Unstaking sells alpha back to the pool for TAO. The returned TAO therefore depends on the exchange rate, liquidity and execution costs when you leave.

    Delegation lets you support a validator without operating its evaluation software. Rewards depend on that validator’s earned dividends and retained share, called its take. More alpha rewards do not automatically mean a larger TAO balance: the token’s exchange rate can fall while its quantity grows. A position’s token amount, marked value and executable exit value answer different questions.

    Weighted pools, price impact and slippage

    An automated market maker, or AMM, prices swaps from reserves and a mathematical rule. Current documented subnet pools use a weighted Balancer-style model. With equal weights, the alpha price is the TAO reserve divided by the alpha reserve, and swaps follow constant-product mathematics. With unequal weights, the weight ratio also affects price. Treating every pool as permanently 50/50 can produce an incorrect quote.

    Protocol liquidity additions are handled separately from user swaps. The implementation can adjust weights to accommodate additions while preserving the intended price relationship, within its safeguards. This does not make staking price-neutral: buying alpha consumes reserves and changes the execution price.

    Price impact comes from your own trade. Slippage, more narrowly, is additional movement before execution, such as another trade arriving first. Both matter when comparing a displayed price with a transaction quote.

    A numerical example: staking is a trade

    Imagine an illustrative pool with 1,000 TAO and 20,000 alpha, with equal weights. Its starting price is 0.05 TAO per alpha. For clarity, assume no fees, other trades, rewards or protocol injections during the transaction.

    A 10 TAO stake might appear to buy 200 alpha at that starting price. But the pool’s reserve product must remain 20,000,000. After the trade, its TAO reserve is 1,010, so its alpha reserve becomes 20,000,000 ÷ 1,010, approximately 19,801.98.

    The staker receives approximately 198.02 alpha, at an average cost of 0.0505 TAO per alpha: 1% above the initial spot price. The pool’s ending spot price is different again, approximately 0.051005.

    This is a teaching example, not a current subnet quote. Real transactions use the actual pool weights, fees and execution state. The calculation illustrates why multiplying an entire position by spot price does not establish its realizable value.

    How TAO allocation changed during 2026

    TAO Flow and Net TAO Flow remain useful descriptions of capital movement, but they are not the current allocation formula. Taostats marks TAO Flow as deprecated. Its history records a return to price-based allocation during June 2026, followed by further changes.

    Today’s documented calculation begins with each eligible subnet’s moving alpha price. This is an exponential moving average, or EMA: recent observations gradually update a smoothed value instead of replacing it immediately. The smoothing depends on subnet age, making newly launched subnets adapt particularly slowly. The price entering this calculation is capped at one TAO per alpha.

    The allocation code then adjusts these price shares for withheld miner incentives and applies an emission gate. A momentary price spike is therefore not equivalent to an immediate increase in allocation.

    Miner-burn adjustments and the emission gate

    The miner-burn adjustment uses 1 − MinerBurned. Here, MinerBurned measures the share of miner incentives withheld because they were directed to subnet-owner hotkeys. It is not a deduction based on every token someone burns. The withheld share counts whether it is burned or recycled. Runtime 445, activated in August, restored this scaling after its earlier removal.

    The emission gate, introduced in runtime 440, further reduces small adjusted shares. Under documented rank-mode settings, the 32nd-largest positive share sets the midpoint, recalculated every 360 blocks. This is a gradual curve, not a rule that everyone outside the top 32 receives nothing.

    At the midpoint, half the input weight passes the gate. That does not mean the subnet receives half its former final allocation: all gated weights are normalized again to divide the available emission. A separate emission-enabled switch can also exclude a subnet from TAO-side allocation. Thresholds and parameters are changeable protocol settings.

    TAO issuance and alpha issuance are separate

    The documented TAO emission rate is 0.5 TAO per block following the December 2025 halving. At a nominal twelve-second block interval, that is approximately 3,600 TAO daily. TAO halvings depend on issuance milestones rather than a guaranteed calendar date.

    Subnet alpha follows its own issuance schedule. Two paths matter: alpha_in supports the pool; alpha_out accrues for participants. Participant issuance starts at up to one alpha per block before that subnet’s halving adjustments. A TAO halving does not simply halve every participant’s alpha payment.

    Pool-side alpha injection is capped using the subnet’s root proportion and alpha emission rate. TAO allocation exceeding the corresponding injection capacity can instead buy existing alpha from the pool. The coinbase implementation records this purchased alpha as protocol-owned. A chain buy and newly minted participant rewards are different flows; neither should be counted as external sales revenue.

    How participants receive rewards

    The standard participant split is approximately 18% for the subnet owner, 41% for miners and 41% for validators and their stakers. These percentages concern participant-side alpha, not each subnet receiving those proportions of all network TAO.

    In the standard Yuma Consensus path, validators submit relative assessments of miners. Stake-weighted consensus constrains scores before determining incentives and dividends. Distribution settles at subnet epochs, whose timing depends on the subnet’s tempo. An explorer’s latest epoch payout should not be mistaken for a continuous per-block payment.

    Root stake can contribute to validator influence through a protocol weighting factor alongside alpha stake. Root-related dividends are carved from the validator-side stream, subject to protocol conditions; delegators receive their entitlement after validator take. Pool allocation and participant evaluation are connected layers with different calculations.

    Root Reborn: principal, baskets and beta shares

    Root, identified by netuid 0, accepts TAO stake directly. Adding or removing root principal does not exchange it for subnet alpha through an AMM. Its accrued rewards, however, have exposure to subnet markets.

    Root Reborn, introduced with runtime 441, moved root dividends into per-validator baskets instead of mechanically selling them on arrival. A basket holds subnet alpha and may hold TAO. Beta shares account for a staker’s proportional entitlement to that basket; they are not another subnet currency.

    Unclaimed reward value changes with the holdings’ realizable TAO value. Claiming sells the relevant basket fraction and credits the proceeds as root stake on that validator, rather than directly to free wallet balance. Claim costs, dust handling and possible unlock intervals are separate from the absence of an AMM swap when moving root principal.

    Basket allocation is not subnet emission voting

    The September v461 design removes the earlier basket target-weight vector. Dividends accumulate where earned; direct basket deposits mirror existing holdings; explicit basket trades change composition. The trading facility has governance-controlled activation and freeze switches, alongside price, turnover, liquidity and concentration limits.

    These controls should not be confused with the network’s emission gate. Basket management concerns holdings after dividends have been earned. It does not let a validator vote a chosen subnet into receiving more network TAO. Availability must be checked against deployed runtime and governance state, not inferred from a release description alone.

    Incentives are not evidence of customer demand

    The allocation system’s use of the word “demand” refers to a token-market signal. It does not count paid inference requests, retained customers or commercial revenue. Alpha buying can reflect expectations about rewards and resale value; protocol-funded chain buys are particularly clear examples of activity that is not customer spending.

    To assess a subnet as a service, examine usable products, evaluation quality, external paid usage and dependence on subsidies separately. Our business evaluation guide addresses that evidence. Dynamic TAO explains how capital, issuance and rewards interact. Establishing whether those incentives support a useful, sustainable service requires another set of observations.

    Sources and review notes

    Research reviewed on 13 October 2026. Original design material is distinguished from later runtime documentation. Live settings can change.

  • What is Bittensor?

    What is Bittensor?

    A practical introduction to subnets, incentives and business relevance.

    Bittensor is an open network that coordinates and rewards the production of digital services, including AI inference, computing and other specialised outputs. Its ecosystem is organised into subnets, each focused on a particular task.

    To understand its potential, start with three questions: what work is being produced, how is it evaluated, and why are participants motivated to improve it?

    How a subnet works

    A subnet brings together participants around a defined task and a set of evaluation rules.

    Miners produce the work. Depending on the subnet, they may operate models, provide computing resources or submit specialised agents. “Mining” here refers to contributing to the subnet’s task.

    Validators evaluate performance. They assess miners’ contributions using the subnet’s scoring rules and submit scores to the blockchain.

    Subnet owners design the mechanism. They define the work being requested and maintain the rules used to evaluate it.

    Bittensor’s Yuma Consensus processes validator scores to help determine how rewards are distributed within the subnet.

    Why incentives matter

    Rewards give participants a reason to compete and improve their contributions. But the scoring system determines what “improvement” means.

    If a subnet rewards accurate, useful results, participants have an incentive to produce them. If its evaluation can be manipulated, participants may earn rewards without delivering the intended benefit.

    The important question is whether better scores correspond to better outcomes for users.

    Where TAO fits

    TAO is Bittensor’s native token. Subnets also have their own tokens, commonly called alpha.

    Under Dynamic TAO, subnet participants receive rewards through subnet-specific token economics. This distinction matters: participating in a subnet does not simply mean receiving a fixed payment in TAO.

    Token rewards encourage participation, but their existence alone does not demonstrate customer demand or commercial sustainability.

    A practical example: cybersecurity

    Bitsec documents a subnet model in which miners submit AI security agents that analyse code and report vulnerabilities. Validators run those agents in isolated environments and evaluate their findings against benchmark vulnerabilities.

    A security company could potentially integrate such capabilities into recurring reviews of authorised codebases. Contributors would have an incentive to improve detection, while the company would still need to assess the reliability of findings, protect confidential code and manage remediation.

    This is a concrete mechanism to evaluate—not a guarantee that every deployment will outperform existing tools.

    For companies: understanding protocol fit

    Product–market fit asks whether a product meets customer demand. We use protocol fit to ask whether the work behind that product suits Bittensor’s model of distributed contributions, evaluation and rewards.

    A company exploring this approach should consider:

    • Task clarity: Can contributors work on a clearly defined problem?
    • Verification: Can useful results be distinguished from incorrect or manipulated outputs?
    • Incentive alignment: Does earning a higher score help deliver what customers need?
    • Operational fit: Can the service meet requirements for privacy, reliability and integration?
    • Economics: Is there a credible business case beyond token-funded participation?

    A strong use case needs both customer demand and a mechanism that rewards valuable work.

    What to look at next

    When exploring a subnet, examine its product, evaluation method and evidence of real usage alongside its token metrics.

    The central question is whether its participants are producing something useful—and whether that usefulness survives outside the scoring system.