# Taostats Docs — Bittensor concepts > Taostats is the block explorer, data API and analytics platform for Bittensor and the TAO token. These docs cover the Taostats API, the MCP server, the TypeScript SDK, Bittensor Auth, the apps, and the Bittensor concepts behind them. The "Bittensor concepts" section of https://beta.taostats.io/docs. The index of every docs page is https://beta.taostats.io/llms.txt and the whole corpus is https://beta.taostats.io/llms-full.txt. Each page below is also available on its own at the `_Source:` URL with `.md` appended. --- # Bittensor Concepts Start with what you want to learn. _Source: https://beta.taostats.io/docs/concepts_ _Last reviewed: 2026-09-15_ Start with what you want to learn. Each card below is a category — open it to see every topic in that area. - [Protocol Changes](https://beta.taostats.io/docs/concepts/protocol-changes) — Recent and upcoming protocol-level changes. - [Subnets](https://beta.taostats.io/docs/concepts/subnets) — How subnets are structured, registered, and emit. - [Validators](https://beta.taostats.io/docs/concepts/validators) — Running, measuring, and rewarding validators. - [Miners](https://beta.taostats.io/docs/concepts/miners) — Mining mechanics, weights, and emission. - [Staking](https://beta.taostats.io/docs/concepts/staking) — Stake, yield, and how returns are calculated. - [Tokenomics](https://beta.taostats.io/docs/concepts/tokenomics) — TAO, alpha, emission, halving, and slippage. - [How emission works](https://beta.taostats.io/docs/concepts/how-emission-works) — Where TAO and alpha emissions flow, and to whom. - [Wallets & accounts](https://beta.taostats.io/docs/concepts/wallets-accounts) — Keys, signing, and connecting wallets. - [Chain & runtime](https://beta.taostats.io/docs/concepts/chain-runtime) — How the Bittensor chain runs underneath. - [Security](https://beta.taostats.io/docs/concepts/security) — Staying safe: keys, software, and best practices. - [Legacy / Deprecated](https://beta.taostats.io/docs/concepts/legacy-deprecated) — Older material kept for reference. --- # Protocol Changes Recent and upcoming protocol-level changes on Bittensor, each with a full explainer. _Source: https://beta.taostats.io/docs/concepts/protocol-changes_ _Last reviewed: 2026-09-23_ Recent and upcoming protocol-level changes on Bittensor, each with a full explainer. - [Root Reborn](https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/tldr) — Root dividends held in the validator's basket of subnet alpha, rebalanced by trading. - [Conviction v2](https://beta.taostats.io/docs/concepts/protocol-changes/conviction-v2) — The revised conviction-locking mechanism (PR #2658). - [Price-based emission shares](https://beta.taostats.io/docs/concepts/protocol-changes/price-based-emission-shares) — Subnet emissions switched to price-based shares (PRs #2779 + #2781). - [The emission gate](https://beta.taostats.io/docs/concepts/protocol-changes/emission-gate) — Emission gating mechanics (spec 440). - [Miner collateral](https://beta.taostats.io/docs/concepts/protocol-changes/miner-collateral) — Collateral requirements for miners (PRs #2953 + #2960). - [Runtime 445](https://beta.taostats.io/docs/concepts/protocol-changes/runtime-445) — Fees recycled not paid to authors, miner-burn scaling restored, EVM precompile expansion (spec 445). - [Shorting](https://beta.taostats.io/docs/concepts/protocol-changes/shorting) — Fixed-Liability Covered Continuous-Unwind shorting model (PR #2764). --- # Root Reborn (PR #2968) Root dividends stop cashing out to TAO and are held in the root validator's basket of subnet alpha, which the validator can rebalance and stakers redeem to TAO. _Source: https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn_ _Last reviewed: 2026-09-23_ Root dividends stop cashing out to TAO and are held in the root validator's basket of subnet alpha, which the validator can rebalance by trading (`swap_basket`) and stakers redeem to TAO on demand. See [Root Validator Baskets](https://beta.taostats.io/docs/concepts/staking/root-validator-baskets) for the mechanics. - [TL;DR](https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/tldr) — The short version — what changes and what you actually do. - [Full explainer](https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/explainer) — The complete walkthrough of baskets, claiming, and mechanics. - [Visual demo](https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/demo) — Interactive demonstration of the basket model. --- # Root Reborn — TL;DR Document: Root Reborn — TL;DR _Source: https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/tldr_ _Last reviewed: 2026-09-15_ [Root Reborn — TL;DR](https://s3.hippius.com/rufus/public/root-reborn-tldr-latest.html) --- # Root Reborn — Full explainer Root Reborn — full explainer _Source: https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/explainer_ _Last reviewed: 2026-09-15_ [Root Reborn — full explainer](https://s3.hippius.com/rufus/public/root-reborn-explainer-latest.html) --- # Root Reborn — Visual demo Root Reborn — visual demo _Source: https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/demo_ _Last reviewed: 2026-09-15_ [Root Reborn — visual demo](https://s3.hippius.com/rufus/public/root-reborn-demo-latest.html) --- # Conviction v2 (PR #2658) For the complete explainer — perpetual and decaying locks, the numbers, worked examples, subnet-owner locks, the subnet king mechanism, and the technical… _Source: https://beta.taostats.io/docs/concepts/protocol-changes/conviction-v2_ _Last reviewed: 2026-09-15_ > [!NOTE] > **Now live on chain** > > Conviction v2 is **live on chain** (Subtensor PR [#2658](https://github.com/opentensor/subtensor/pull/2658)). The full explainer has moved into the concept docs. For the complete explainer — perpetual and decaying locks, the numbers, worked examples, subnet-owner locks, the subnet king mechanism, and the technical reference — see: **[Conviction](https://beta.taostats.io/docs/concepts/chain-runtime/conviction-v2)** in Concepts → Chain & runtime. --- # Price-based emission shares (PRs #2779 + #2781) For how emission works now — the live per-block share formula (share_i ∝ price_i × (1 − miner_burned_i)), the miner-burn scaling, the alpha-injection cap, and… _Source: https://beta.taostats.io/docs/concepts/protocol-changes/price-based-emission-shares_ _Last reviewed: 2026-09-15_ > [!WARNING] > **Superseded as the final formula by spec 440** > > As of **spec 440** (2026-07-27), the price-based quantity on this page — > `price × (1 − miner_burned)`, renormalized — is now the **demand input** to a new > [emission gate](https://beta.taostats.io/docs/concepts/protocol-changes/emission-gate), *not* the final > emission share. Emission is no longer proportional to demand. This page still > explains how demand is built; see **[The emission gate (spec 440)](https://beta.taostats.io/docs/concepts/protocol-changes/emission-gate)** > for what happens to it next. > [!NOTE] > **Now live on chain** > > Price-based emission shares are **live on chain** (Subtensor PRs > [#2779](https://github.com/opentensor/subtensor/pull/2779), > [#2781](https://github.com/opentensor/subtensor/pull/2781), and > [#2800](https://github.com/opentensor/subtensor/pull/2800)). The full > explainer has moved into the emission concept docs. For how emission works now — the live per-block share formula (`share_i ∝ price_i × (1 − miner_burned_i)`), the miner-burn scaling, the alpha-injection cap, and worked examples — see: **[Tao Emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission)** in Concepts → Tokenomics → How emission works. --- # The emission gate (spec 440) Every block, the chain hands out TAO emission and each subnet competes for a slice. _Source: https://beta.taostats.io/docs/concepts/protocol-changes/emission-gate_ _Last reviewed: 2026-09-15_ > [!NOTE] > **Live on mainnet (spec 440)** > > This change is **live on mainnet** — spec version **440**, confirmed on Finney > via `state_getRuntimeVersion`. The figures below are a point-in-time snapshot > (block 8,714,269, 2026-07-27) and will drift as demand and the bar θ move. ## The short version Every block, the chain hands out TAO emission and each subnet competes for a slice. **Until spec 440, a subnet's slice was simply proportional to how much the market wanted it** — twice the demand earned twice the emission. Spec 440 adds a **gate**: it draws a line, lets the sought-after subnets keep their full slice, chokes the barely-wanted ones toward zero, and hands the freed-up emission back up to the top. How "wanted" a subnet is — its **demand** — is measured exactly as before. Only how that demand turns into emission changed. > [!NOTE] > **What was the answer is now an input** > > The quantity `price × (1 − miner_burned)`, renormalized — which our > [price-based emission shares](https://beta.taostats.io/docs/concepts/protocol-changes/price-based-emission-shares) > page described as *the* emission share — is now the **demand `s`**: the identical > math, but used as the **input** to the gate instead of being the final answer. ## 1 · Building demand (`s`) — same math as before Demand is built in three steps, unchanged from the price-based-shares design: - **Step A — price.** Each subnet's raw demand is its **moving alpha price** — the EMA of its alpha token's price against TAO from the AMM pool (`get_moving_alpha_price`). Staking TAO into a subnet's pool bids its price up: higher price = more demand. Because it's an EMA, a one-block spike can't game it. - **Step B — normalize into a share.** Divide each subnet's price by the sum of all prices → shares that sum to 1: `sᵢ^price = movingPriceᵢ / Σⱼ movingPriceⱼ`. - **Step C — discount for miner burn, renormalize.** Scale each share by `(1 − miner_burned)` and renormalize: `sᵢ = sᵢ^price·(1 − minerBurnedᵢ) / Σⱼ sⱼ^price·(1 − minerBurnedⱼ)`. A full burner → 0. The result is the **demand share `s`** that feeds the gate. Miner burn is a heavy first-stage filter, not a footnote: in the 2026-07-27 snapshot, 35 of 128 subnets burned 100% of their miner emission (zeroed out before the gate even sees them), 32 burned partially, and mean burn network-wide was ~43%. ## 2 · The bar (θ) — where the line sits **θ ("theta")** is a **q-mass quantile** on demand, recomputed every **360 blocks**: 1. Sort all subnets' demand shares **largest → smallest**. 2. Walk down, accumulating the shares. 3. The moment the running total crosses **q = 0.61** (61% of all demand), stop. The share you're standing on is **θ, the bar**. Because shares sum to 1, "cumulative ≥ 0.61" means the top subnets together own 61% of demand. θ is a property of the demand **distribution**, not the subnet count — spinning up empty subnets adds no demand, so it can't move the bar. ## 3 · The gate — a Hill function $$ gate(s) = \dfrac{s^h}{s^h + \theta^h} = \dfrac{1}{1 + (\theta/s)^h} $$ The two forms are identical; the chain computes the right-hand one because `s^h` underflows fixed-point precision for deep-tail shares, while the ratio `θ/s` stays well-conditioned. `h` (default **3**, sudo-settable 1–8) sets how sharp the cliff is. The gate returns a number in `[0, 1]`: | Your demand `s` vs bar θ | gate(s) | Result | | --- | --- | --- | | well above θ | → 1.0 | keep ~all your emission | | exactly at θ | 0.50 | keep exactly half | | well below θ | → 0.0 | emission choked toward zero | ### Then: renormalize (the redistribution) $$ e_i = \dfrac{s_i \cdot gate(s_i)}{\sum_j s_j \cdot gate(s_j)} $$ Gating shrinks every share, but the block still emits a fixed total. Dividing by the new (smaller) sum scales the survivors back up — this is how the tail's lost emission flows to the winners. **A top subnet ends up emitting more than its raw demand share.** ### Then one more redistribution — emission-enabled subnets only After the gate, the chain checks **`SubnetEmissionEnabled`** for each subnet. Any subnet with it set to `false` has its gated share **zeroed and redistributed to the enabled subnets** (a second renormalize over the enabled set only). This is a **separate switch from miner burn** — a subnet can clear every filter, survive the gate, and still be zeroed here. It's the final stage, and it's why the live emission a subnet actually receives is slightly higher than the gate alone would give. ## 4 · What it means - **Emission is no longer proportional to demand.** Any APY or emission figure that assumes a pro-rata split is now wrong for every subnet — winners are understated, the tail overstated. - **The tail gets crushed.** In the snapshot, ~38% of demand (below-bar subnets) collectively earned ~10% of emission. A low-demand subnet's emission — and its miners'/validators' yield — drops sharply. - **Miner burn is a first-stage filter.** Before the gate runs, `(1 − miner_burned)` zeroes or shrinks a subnet's share. Any model that ignores burn will misplace which subnets earn. - **The bar moves.** θ recomputes every 360 blocks from live prices, so which subnets are "above the line" shifts as demand shifts. A static calculation will drift. - **Two sudo knobs.** `q` (default 0.61, bar height) and `h` (default 3, cliff sharpness) are both root-settable — a governance change to either reshapes every subnet's emission at once. - **A separate emission-enabled switch runs last.** After the gate, any subnet with `SubnetEmissionEnabled = false` is zeroed and its share redistributed to the enabled subnets. It's independent of demand, burn, and the gate — a subnet can survive everything else and still earn nothing. ## Source provenance - **Code:** `pallets/subtensor/src/coinbase/subnet_emissions.rs` (v440 tag): `get_subnets_to_emit_to` / `get_shares` / `maybe_update_emission_gate_bar` / `apply_emission_gate` / `get_subnet_block_emissions`. - **Spec:** runtime version confirmed **440** on Finney (mainnet) via `state_getRuntimeVersion`. - **Snapshot:** demand = moving alpha price × (1 − miner burn), read off-chain at block **8,714,269** (2026-07-27 15:51 UTC), q = 0.61, h = 3, 126 emit-set subnets. θ landed at rank 18 (SN83), 1.339%. Reconciles to the live per-subnet emission Taostats displays (e.g. SN64 = 16.63% vs 16.67%). See also: [Price-based emission shares](https://beta.taostats.io/docs/concepts/protocol-changes/price-based-emission-shares) · [Tao Emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) · [Subnet Emissions](https://beta.taostats.io/docs/concepts/subnets/subnet-emissions) --- # Miner collateral (PRs #2953 + #2960) Miner collateral is a refundable-by-work registration bond for Bittensor subnets. _Source: https://beta.taostats.io/docs/concepts/protocol-changes/miner-collateral_ _Last reviewed: 2026-09-15_ Miner collateral is a refundable-by-work registration bond for Bittensor subnets. Part of your registration fee stops being recycled and instead becomes locked stake you can only recover by earning emission — or by the subnet dissolving. It shipped via the collateral release train ([#2953](https://github.com/RaoFoundation/subtensor/pull/2953) → [#2960](https://github.com/RaoFoundation/subtensor/pull/2960)) and is **live on Finney mainnet at spec 437**. > [!NOTE] > **The one-line version** > > It's a security deposit. A subnet can force part of your registration cost to be staked and frozen as collateral. You get it back slowly as you do validated work — and if you walk away without mining, it sits frozen on your hotkey, earning nothing. ## Is it on? Off by default Miner collateral is **opt-in per subnet, and off everywhere until a subnet switches it on**. The controlling hyperparameter `CollateralLockShare` (**p**) defaults to `0`, and at `p = 0` there is no collateral at all — the entire registration price is recycled exactly as it was pre-feature. A subnet activates it by setting `p > 0` via `sudo_set_collateral_lock_share`, callable only by the subnet owner or root. - **Optional for the subnet** — the owner chooses whether to enable it, and at what strength (`p` up to 95%). - **Mandatory for the miner** — once your subnet runs `p > 0`, every registration on it is split and bonded automatically. There is no per-miner opt-out at registration; if you register, you post the bond. - **Not retroactive** — turning `p` on (or changing it) affects future registrations only; standing collateral is never re-priced. Everything below describes a subnet that has enabled it. On a subnet with `p = 0`, none of it applies — you just pay the normal burn. ## Why it exists Registration on a busy subnet already costs real TAO — but today 100% of that cost is recycled (swapped to alpha, and that alpha removed from supply; the chain labels this the "burn"). Once you're registered, the value is gone to you whether you mine honestly or squat the slot doing nothing. Miner collateral changes the incentive: a subnet owner can redirect part of the registration cost away from the burn and into a locked bond on your own hotkey. Now you have skin in the game. Mine well and the bond flows back to you. Spam-register or go idle and your capital is stuck. It's an anti-spam / commitment mechanism, tuned per subnet. > [!WARNING] > **Misconception to kill first** > > "Registration is cheap (0.001 TAO), so collateral is trivial." Not on collateral subnets. The 0.001 figure is the floor on idle subnets. A subnet that wants collateral deliberately runs a higher registration price and then splits it — that's the whole point. The feature targets those subnets, not the cheap ones. ## The split: burn vs lock Each subnet sets a hyperparameter **p** (`CollateralLockShare`), a fraction from `0` to `0.95`. Your registration cost splits by that ratio: ``` registration cost └─ ALL of it → swap TAO → alpha (into the subnet's pool) ├─ p → stake to your hotkey → LOCK └─ (1 − p) → alpha removed from supply (the "burn") ``` > [!NOTE] > The `(1 − p)` share is often called the "burn," but it's a recycle, and the chain uses that word literally. Your whole payment is swapped TAO → alpha. Two things then happen to the `(1 − p)` share: its TAO stays in the subnet and is tallied in `RAORecycledForRegistration` (the chain's recycled-TAO counter), and the alpha it bought is decremented from `SubnetAlphaOut` — removed from circulating alpha supply. It is not a TAO burn; nothing is destroyed at the TAO level. So it's your registration money that gets locked — not extra money on top. Two things to internalise: - **It's locked as alpha, not TAO.** Your `p` share buys the subnet's alpha token at its moving-average price (with a 5% slippage cap on the buy), and it's the alpha that's locked. Its TAO value floats afterward. - **The "burn" share is always positive.** `p` is capped at 95% (`MaxCollateralLockShare`) so a registration always recycles something — you can never lock 100%. ### Worked example Subnet sets reg cost = 2 TAO at the maximum `p = 0.95`, alpha price = 0.1: | Component | Amount | Fate | |---|---|---| | "Burned" `(1 − p)` | 0.1 TAO | recycled (alpha removed from supply) | | Locked `p` | 1.9 TAO → 19 alpha | frozen on your hotkey | Change the dials and you change the bond: `p = 0.5` on the same 2 TAO reg → burn 1 / lock 1. Note the cap makes a big bond need a big reg cost: to lock ~1 TAO you need reg ≥ ~1.05 TAO, since at most 95% of it can be locked. ## How the lock comes back: drain, not decay The lock does **not** decay on a clock. Sit idle for a year and it's exactly where you left it. The only thing that reduces it is earned emission, settled each tempo: $$ release\_this\_tempo = \min\!\left(k \times emission\_earned,\ locked - min\_locked\right) $$ - **k** = `CollateralDrainRatio` — the per-subnet unlock rate. Default `1.0` (one alpha released per alpha of emission earned), settable up to `10.0`. - Each tempo you earn emission, `k × emission` of alpha unlocks back to your free stake, where you can unstake or transfer it normally. - `k` is snapshotted onto your position at registration. If the owner changes `k` mid-life, your existing bond keeps its original rate — only your next re-registration re-prices it. > [!NOTE] > **Is emission locked? No — it's the opposite** > > A common misread: "does the feature lock my incentive?" No. Your emission pays out normally — and it's the key that unlocks your collateral. Earning emission drains your bond down. The only exception is the floor mechanic below. Since **runtime 437** the drain settles against **full hotkey emission** — miner incentive *and* validator dividends — releasing the lock at rate `k`. (Runtime 435 drained on incentive only, which stranded pure-validator locks; 437 fixed that.) ### The optional floor (`min_locked`) A miner can set a floor (`do_set_min_collateral`) — e.g. to track a per-machine deposit a subnet's validators publish. The lock self-maintains around it: - **Above the floor:** emission drains the lock down toward the floor (and stops there). - **Below the floor (you're deficient):** emission is captured — withheld from you and pushed back into the lock — until the floor is restored. This is the only path where emission doesn't reach your wallet. The chain also tracks `earned` — cumulative lifetime emission per collateral entry — so validators can compare a miner's extraction against the bond still at risk. ## A separate lock from conviction — they stack > [!WARNING] > **Miner collateral is NOT a conviction lock** > > These are two completely independent locks with different storage, purpose, and exit rules. A single stake position can carry both at once, and they stack: when you try to unstake, the chain subtracts both the miner collateral and the conviction lock, and only what's left over is movable. The two behave in opposite ways on the point that matters most — getting your locked stake out. Miner collateral has no transfer exit at all, where [conviction](https://beta.taostats.io/docs/concepts/chain-runtime/conviction-v2) does: | | Conviction lock | Miner collateral | |---|---|---| | Purpose | Voluntary — boost stake weight | Forced — registration bond | | Storage | `Locks` | `MinerCollateral` | | Unstake locked amount | blocked up to lock | blocked up to lock | | Transfer stake | follows the stake (recipient must accept) | blocked — stays on origin | | Hotkey swap | permitted | bond follows the UID via `keep_stake=false`; abandoning the lock (`keep_stake=true`) is refused with `KeepStakeBlockedByCollateral` | | Only exit | time unlock + transfer | earned emission (or subnet dissolution) — a key swap moves the bond, it does not release it | On the hotkey-swap row, **runtime 437 changed the collateral behaviour** (the old flat-revert `HotKeyHasCollateral` error is gone). A hotkey swap now takes a `keep_stake` flag: with `keep_stake=false` the UID and its bonded stake move together to the new hotkey — the collateral follows the UID, and a per-subnet lineage record (`HotkeySuccessor` / `HotkeyRoot`) ties old and new keys to one identity so the bond stays attributable. Only `keep_stake=true` — which would strand the lock on the dead old hotkey while the UID walks off — is refused, with `KeepStakeBlockedByCollateral`. So the bond can't be abandoned by renaming keys, but it is no longer immovable: it travels with a full swap. > [!NOTE] > **Can I stake the frozen alpha to a validator for yield?** > > No. It's welded to the `(netuid, hotkey, coldkey)` position that registered — you can't move it to a validator hotkey. And on your own miner hotkey it earns no passive APY: miner hotkeys only earn incentive for scored work, not dividends. While it's frozen and you're not actively mining, it earns nothing. It is inert, illiquid capital until you mine it free. ## Deregistration & re-registration Getting pruned (neuron deregistration) does not sell or clear your alpha — it only frees your UID slot. Your staked alpha and its lock stay in place. On re-registration, the standing lock is valued at the moving-average price and credited against the new requirement, so you pay only the shortfall. ### Three re-registration cases (same 19 locked alpha, 1.9 TAO requirement) | Scenario | Requirement (1.9 TAO) | You pay | |---|---|---| | Price still 0.1 | 19 alpha = 1.9 TAO → covered | just the ~0.1 burn | | Price rises to 0.2 | 19 alpha = 3.8 TAO → over-covered | just the ~0.1 burn (excess drains out as you mine) | | Price drops to 0.05 | 19 alpha = 0.95 TAO → short 0.95 | buy ~19 more alpha (0.95 TAO) + 0.1 burn | > [!WARNING] > **Fill-or-kill top-up trap** > > The top-up buy is bounded at spot × 1.05 (5% slippage cap). If your top-up would push the pool more than 5% above spot, the whole re-registration reverts — no partial fill. On a thin subnet with a big top-up, add collateral in smaller chunks first (`do_add_collateral`) before re-registering. ## Is it ever truly lost? "Burned forever" is wrong — the collateral is never destroyed (only the small `(1 − p)` burn share is). But "stuck indefinitely" is right in the walk-away case. | What happens | Your collateral | |---|---| | You mine, then stop | drained back to free stake as you earned — mostly recovered | | You re-register that hotkey later | credited against the requirement — reusable | | Subnet is dissolved | all alpha (locked + free) pro-rata converted to free TAO and returned to your coldkey; the lock rows are wiped | | You quit, never mine, never re-reg, subnet lives on | frozen indefinitely — still yours, but non-earning & illiquid | | Value recycled (not returned) | only the `(1 − p)` registration share — swapped to alpha, alpha removed from supply (the "burn") | > [!NOTE] > **Subnet dissolution refunds you** > > On dissolution the chain runs a settlement that values every staker's alpha — collateral included — and pays it out as free TAO to the coldkey, then clears the `MinerCollateral` rows as dead metadata. So on subnet death, you get your money back. The realistic verdict: for a live subnet you walk away from, the collateral is "lost for the foreseeable future" — not burned, not lost to the chain, still your alpha, but frozen, non-earning, and unmovable until you mine it down or re-register. The real cost is opportunity cost, plus alpha-price drift: you get your alpha back, not your TAO. If alpha craters while locked, so does the value you recover. ## What this changes for Taostats: available ≠ total Miner collateral makes a position's displayed stake diverge from its spendable stake. Anyone reading a stake balance on a collateral subnet will overstate liquidity unless collateral is subtracted. | Concept | Source | Meaning | |---|---|---| | Total stake | existing stake storage | what shows on the position today | | Locked collateral | `MinerCollateral (netuid, hotkey, coldkey)` | frozen — can't unstake or transfer; a hotkey swap moves it with the UID but never releases it | | Available | `stake − collateral − conviction lock` | what's actually movable | The chain computes this internally (`available_to_unstake_from_hotkey` does `stake − collateral`, stacking with conviction locks). Surfaces to index (live as of runtime 437): `MinerCollateral`, `ColdkeyMinerCollateral`, `CollateralLockShare` (p), `CollateralDrainRatio` (k); events `CollateralLocked`, `CollateralLockShareSet`, `MinCollateralSet`; plus lineage (`ColdkeyCollateralHotkeys`, `HotkeySuccessor` / `HotkeyRoot`, `ColdkeySuccessor` / `ColdkeyRoot`). ## Who controls the dials | Knob | Set by | Bounds | Notes | |---|---|---|---| | **p** — lock share | root or subnet owner | 0 – 0.95 | future registrations only; standing collateral never re-priced | | **k** — drain ratio | root or subnet owner | >0 – 10.0 (default 1.0) | snapshotted per position at registration | | `min_locked` — floor | the miner (own hotkey) | ≥ 0 (0 = off) | drain stops at floor; emission refills below it | | top-up | the miner | — | `do_add_collateral`; prefers free staked alpha, buys the shortfall; keeps drain snapshot | ## The whole thing in 8 lines 1. A subnet sets **p**: your registration cost splits into a recycled share `(1 − p)` and a locked share `p`. 2. The locked share buys alpha, stakes it to your hotkey, and freezes it as collateral. 3. You recover it by earning emission: since runtime 437 the drain settles against **full hotkey emission** — miner incentive and validator dividends — releasing the lock back to free stake at rate `k`. 4. It doesn't decay on a clock — no work, no unlock. 5. You can't transfer or unstake it; a hotkey swap carries the bond to the new key (via `keep_stake=false` + lineage) but can't abandon it — and it earns no passive APY. 6. Dereg keeps it; re-registration credits it against the new requirement. 7. Subnet dissolution refunds it as free TAO. It's never destroyed — only the `(1 − p)` share is recycled. 8. For Taostats: track `available = total − collateral − conviction lock`, or balances will read too high. ## Source provenance - **Subtensor PRs:** [#2953 — The v435 upgrade: miner registration collateral](https://github.com/RaoFoundation/subtensor/pull/2953) (merged 2026-07-21), [#2960 — Runtime 437: collateral, key lineage, and bonded swap hardening](https://github.com/RaoFoundation/subtensor/pull/2960) (merged 2026-07-22). - **Code locations (branch `main`, spec 437):** `pallets/subtensor/src/subnets/collateral.rs`, `subnets/dissolution.rs`, `coinbase/run_coinbase.rs`, `swap/hotkey_lineage.rs`, `swap/coldkey_lineage.rs`, `pallets/subtensor/src/lib.rs` (bounds & storage), `pallets/admin-utils/src/lib.rs` (setters). - **Status:** live on Finney mainnet — spec 437. - **Original explainer:** prepared by Rufus for the Taostats team. > [!NOTE] > The `#2953` / `#2960` PRs are on the `RaoFoundation/subtensor` fork used for the collateral release train. Runtime numbers: the feature landed at runtime **435** and was hardened at runtime **437** (the live spec) — the emission-based drain and bonded key-swap lineage described above are read from `main` at spec 437. --- # Runtime 445 (release v445) The Bittensor mainnet runtime upgraded to spec version 445. _Source: https://beta.taostats.io/docs/concepts/protocol-changes/runtime-445_ _Last reviewed: 2026-09-15_ The Bittensor mainnet runtime upgraded to **spec version 445**. Unlike the single-feature explainers elsewhere in this section, v445 is a bundled release: it reworks transaction-fee handling, restores miner-burn emission scaling, expands the EVM precompiles, and adds Ledger-style signatures for limit orders, alongside a set of storage-hygiene and proxy/multisig fixes. > [!NOTE] > **Live on mainnet (spec 445)** > > Confirmed on-chain: runtime version **445** activated at block **8,831,003** (2026-08-12 21:06 UTC on Finney), read from the Taostats [runtime version](https://beta.taostats.io/docs/api-reference/chain/get-runtime-version-latest) index. Mainnet went straight from 443 to 445 — spec 444 was never a live mainnet runtime. ## The short version - **Transaction fees are recycled, not paid to block authors.** v445 reverts the earlier "reward the block author" behaviour: the fee is removed from issuance (recycled) instead of being handed to whoever built the block. Alpha-denominated fees are sold and the resulting TAO is recycled the same way. - **Miner-burn emission scaling is back.** The `(1 − miner_burned)` discount on a subnet's emission share — removed earlier — was restored. - **The EVM precompile surface grew.** New readers/getters, a root-claim precompile plus getters for unclaimed value, and runtime-constant exposure. A new rule bars root-privileged calls from being implemented in precompiles. - **Limit orders accept Ledger signatures.** The limit-orders pallet now validates Ledger-style signatures alongside standard formats, and rejects invalid signatures during transaction validation. ## Transaction fees: recycled, not burned, not paid to authors This is the highest-impact user-facing change, and the wording matters. > [!WARNING] > **"Burn" is the wrong word here — it's a recycle** > > v445 removes the transaction fee from `pallet_subtensor::TotalIssuance` (`TransactionFeeHandler::on_nonzero_unbalanced` does `TotalIssuance.saturating_sub(amount)`). On Bittensor, subtracting from `TotalIssuance` is **[recycling](https://beta.taostats.io/docs/concepts/tokenomics/recycling)** — the TAO is removed from circulation now and re-enters the emission pool later, pushing the [halving](https://beta.taostats.io/docs/start-here/glossary#halvinghalvening) further out. It is **not** a permanent [burn](https://beta.taostats.io/docs/concepts/tokenomics/burning); nothing is destroyed. See the [glossary entry on burn vs recycle](https://beta.taostats.io/docs/start-here/glossary#burn). What actually changed: - **Before:** an earlier runtime routed transaction fees to the **block author** (block builder). - **v445:** that is reverted. The fee is recycled — the block author receives nothing. The pallet's own test, `tao_transaction_fees_are_recycled`, asserts the block-builder balance is unchanged and that total issuance drops by exactly the fee charged. Alpha-denominated fees follow the same fate by a different path: the pallet sells the alpha for TAO directly from the subnet account and recycles that TAO (`recycle_tao`), in a single storage transaction so a failed recycle rolls back the alpha withdrawal. **What this means:** any model that assumed transaction fees accrued to validators/block authors as income is now wrong. Fee revenue does not flow to a participant — it leaves circulation and defers the halving, exactly like registration recycle. ## Emissions: miner-burn scaling restored v445 restores the **miner-burn emission scaling** in subnet emission shares (PR [#3071](https://github.com/RaoFoundation/subtensor/pull/3071)) after it had been removed. Net effect: the prior behaviour is back — a subnet's demand share is again discounted by `(1 − miner_burned)` before it competes for emission. This is the same first-stage filter described on the [emission gate](https://beta.taostats.io/docs/concepts/protocol-changes/emission-gate) page: a subnet that burns 100% of its miner emission is zeroed out before the gate even sees it. With the scaling restored, any emission/APY estimate that ignores miner burn will again misplace which subnets actually earn. See [The emission gate](https://beta.taostats.io/docs/concepts/protocol-changes/emission-gate) and [Price-based emission shares](https://beta.taostats.io/docs/concepts/protocol-changes/price-based-emission-shares) for how this discount feeds into the full emission calculation. ## EVM precompiles: expanded and hardened The precompile layer (`precompiles/src`) saw a large expansion: - **New readers and getters** across existing precompiles that were missing them. - **A root-claim precompile**, plus getters that expose unclaimed value, so EVM contracts can read and act on root-claim state. - **Runtime-constant exposure** to the EVM, and no-std import fixes. - **A new invariant:** root-privileged calls must **not** be implemented in precompiles. This is a security boundary, not a feature — it keeps root authority out of the EVM call surface. The EVM interface artifacts were regenerated to match. See [EVM contracts](https://beta.taostats.io/docs/concepts/chain-runtime/evm-contracts) for how the precompiles fit the wider EVM story. ## Limit orders: Ledger signatures The limit-orders pallet now supports **Ledger-style signatures** alongside the standard signature formats. Ledger produces human-friendly signatures and signs a hash of the payload when it exceeds 256 bytes; v445 validates these correctly. Invalid signatures are now **rejected during transaction validation** rather than slipping through, and new test vectors cover the added formats. ## Lower-impact fixes Bundled in the release, less likely to be user-visible but worth noting for anyone indexing chain state: - **Commitments / storage hygiene** — prevalidate commitment failures ([#3040](https://github.com/RaoFoundation/subtensor/pull/3040)); purge neuron commitments when trimming UIDs and on deregistration ([#3062](https://github.com/RaoFoundation/subtensor/pull/3062)); a storage-bloat reduction migration ([#3061](https://github.com/RaoFoundation/subtensor/pull/3061), [#3076](https://github.com/RaoFoundation/subtensor/pull/3076)). Voting-power state is cleared on subnet dissolution, and `TotalVotingPower` was added to SDK metadata. - **Proxy / multisig** — preserve intent safety and wrapper order through multisig dispatch, and propagate/refund inner post-dispatch weight for proxy calls ([#3063](https://github.com/RaoFoundation/subtensor/pull/3063)). - **SDK / generated docs** — refreshed Python SDK metadata, generated transaction links, error pages, and query docs for the new spec. ## Source provenance - **Release:** [`RaoFoundation/subtensor` v445](https://github.com/RaoFoundation/subtensor/releases/tag/v445). The release body itself is deployment/multisig boilerplate; the changes above are reconstructed from the `v443...v445` commit range and merged PRs, then verified against source at the `v445` tag. - **On-chain confirmation:** runtime version **445** at block **8,831,003** (2026-08-12 21:06 UTC), Finney, via the Taostats runtime-version index. - **Transaction fees (verified at `v445`):** `pallets/transaction-fee/src/lib.rs` — `TransactionFeeHandler::on_nonzero_unbalanced` subtracts the fee from `pallet_subtensor::TotalIssuance` (recycle); the alpha path calls `recycle_tao`. Confirmed by the pallet test `tao_transaction_fees_are_recycled` (`pallets/transaction-fee/src/tests/recycling.rs`), which asserts the block author is not paid. - **Emissions:** miner-burn scaling restored via PR [#3071](https://github.com/RaoFoundation/subtensor/pull/3071). > [!NOTE] > The v445 release train lives on the `RaoFoundation/subtensor` repository (the former `opentensor/subtensor`, now redirected). PR numbers reference that repository. See also: [Recycling](https://beta.taostats.io/docs/concepts/tokenomics/recycling) · [Burning](https://beta.taostats.io/docs/concepts/tokenomics/burning) · [The emission gate](https://beta.taostats.io/docs/concepts/protocol-changes/emission-gate) · [EVM contracts](https://beta.taostats.io/docs/concepts/chain-runtime/evm-contracts) --- # Runtime 447 (release v447) The Bittensor mainnet runtime upgraded to spec version 447. _Source: https://beta.taostats.io/docs/concepts/protocol-changes/runtime-447_ _Last reviewed: 2026-09-15_ The Bittensor mainnet runtime upgraded to **spec version 447**. Unlike the bundled [runtime 445](https://beta.taostats.io/docs/concepts/protocol-changes/runtime-445) release, v447 is a single-feature change: it retunes the **conviction-based subnet-ownership takeover rule** (the [subnet king](https://beta.taostats.io/docs/concepts/chain-runtime/conviction-v2#7-subnet-king-mechanism) mechanism), replacing a subnet-wide 10% quorum with an 18% bar on a single hotkey. > [!NOTE] > **Live on mainnet (spec 447)** > > Confirmed on-chain: runtime version **447** activated at block **8,844,992** (2026-08-14 19:44 UTC on Finney), read from the Taostats [runtime version](https://beta.taostats.io/docs/api-reference/chain/get-runtime-version-latest) index. ## The short version - **Ownership now transfers on one hotkey's own conviction, not the subnet-wide total.** Before v447, a subnet's ownership moved to the highest-conviction hotkey once the **total** rolled conviction across the whole subnet (every hotkey and coldkey, including the incumbent owner) reached **10% of eligible alpha**. From v447, ownership transfers only when a **single hotkey's own rolled aggregate conviction exceeds 18% of eligible alpha, by itself**. - **The subnet-wide sum no longer counts.** Other keys' locks — including the owner's — no longer add to a challenger's threshold. Only conviction locked toward the winning hotkey counts toward its bar. - **Everything else is unchanged.** Eligible alpha is still `SubnetAlphaOut − SubnetProtocolAlpha − AlphaBurned` (saturating at zero), the subnet must still be at least `ONE_YEAR` (2,629,800 blocks) old, and a zero eligible balance still cannot trigger a transfer. ## Why the rule changed Summing conviction across every locker meant unrelated stakers — and even the incumbent owner's own locked alpha — could inadvertently supply a challenger's quorum. A subnet could cross the 10% subnet-wide bar without any single party actually committing enough conviction to warrant taking ownership. v447 closes that path by measuring only the **winning hotkey's own conviction**. Coalitions still work exactly as before: backers who want to support a challenger lock directly to that challenger's hotkey, so their conviction lands in that hotkey's own aggregate and counts toward the 18% bar. What no longer counts is conviction locked elsewhere on the subnet. ## What actually changed in the gate Both the winner selection and the admission check now run through one shared computation (`subnet_king_with_conviction`), so the gate can never disagree with the hotkey it examined: - **Before (spec 446):** `get_total_conviction(netuid) × 10 ≥ eligible_alpha` — a subnet-wide sum against a **10%** bar (`≥`). - **From spec 447:** `king_conviction × 100 > eligible_alpha × 18` — the **single winning hotkey's** conviction against an **18%** bar, strict (`>`). The comparison is cross-multiplied in 256-bit integers over the raw `U64F64` bits so a high-range takeover can't saturate and get wrongly rejected. The full mechanism — how conviction is rolled forward per hotkey, how the aggregate buckets swap on transfer, and the worked numbers — is documented in the [Conviction](https://beta.taostats.io/docs/concepts/chain-runtime/conviction-v2) concept page. ## What this means - Any estimate of when a subnet becomes takeover-eligible must now project a **single hotkey reaching 18% of eligible alpha on its own**, not the subnet-wide total reaching 10%. In practice this raises the effective bar for a takeover on most subnets, because the incumbent owner's and unrelated stakers' locks no longer contribute. - Tools and dashboards that surfaced "subnet-wide conviction vs. 10%" as a takeover-readiness signal are now measuring the wrong quantity; the readiness signal is the **leading hotkey's own conviction vs. 18%**. ## Source provenance - **Release:** [`RaoFoundation/subtensor` v447](https://github.com/RaoFoundation/subtensor/releases/tag/v447), single PR [#3083](https://github.com/RaoFoundation/subtensor/pull/3083) ("Conviction normalization: single-hotkey 18% takeover gate"). - **On-chain confirmation:** runtime version **447** at block **8,844,992** (2026-08-14 19:44 UTC), Finney, via the Taostats runtime-version index. - **Gate (verified at `v447`):** `pallets/subtensor/src/staking/lock.rs` — `change_subnet_owner_if_needed` (L1180) gates on `king_conviction × 100 > eligible_alpha × 18`, where `king_conviction` comes from `subnet_king_with_conviction` (L1093, the winning hotkey's rolled aggregate). Compared against `v446`, which gated on `get_total_conviction(netuid) × 10 ≥ eligible_alpha` (subnet-wide sum, 10%). `eligible_alpha` and the `ONE_YEAR` age gate are byte-for-byte unchanged between the two tags. > [!NOTE] > The v447 release train lives on the `RaoFoundation/subtensor` repository (the former `opentensor/subtensor`, now redirected). PR numbers reference that repository. See also: [Conviction](https://beta.taostats.io/docs/concepts/chain-runtime/conviction-v2) · [Runtime 445](https://beta.taostats.io/docs/concepts/protocol-changes/runtime-445) · [Protocol changes overview](https://beta.taostats.io/docs/concepts/protocol-changes) --- # Shorting (PR #2764) — Fixed-Liability Covered Continuous-Unwind Model A covered short on Bittensor is a leveraged bearish bet on a subnet's alpha token. _Source: https://beta.taostats.io/docs/concepts/protocol-changes/shorting_ _Last reviewed: 2026-09-15_ > [!NOTE] > **Status:** pending · **Last reviewed:** 2026-06-27 · [Source PR](https://github.com/opentensor/subtensor/pull/2764) > [!WARNING] > **Not live on mainnet** > > This page describes Subtensor PR #2764, the v3.6.1 **Fixed-Liability Covered > Continuous-Unwind Model** for shorting alpha tokens. The runtime flag > `ShortsEnabled` defaults to `false` and the feature is gated behind the > trading-games activation. Do not make production decisions assuming shorts > are available on mainnet. When the flag flips, this section will be > re-reviewed and cross-cut into tokenomics, staking, and chain pages. ## What covered shorting is A **covered short** on Bittensor is a leveraged bearish bet on a subnet's alpha token. You fund a TAO floor `P` (your max loss), borrow a fixed quantity of alpha `Q` from the subnet pool at today's price, and profit if alpha depreciates. To close, you buy `Q` back from the pool — if the price fell, the buyback costs less than your retained buffer `R` and you keep the difference. If the price rose, the buyback eats into `R` and then into `P`. Crucially, there is **no margin liquidation**. There is no liquidation price to target, no short squeeze, no MEV-driven forced close. Default happens only on time — when the retained buffer decays to a dust threshold — or on subnet deregistration. Your maximum loss is capped at the floor `P` you funded at open. The model matters for subnet economics because it injects discipline without leaving TAO stranded. Every τ removed from the pool at open is returned: via daily decay (`R` and `E` drift back into reserves over the position's life), via the close settlement, or — if the trader abandons — via recycling `P` into the TAO emission pool as `tao_in`. There is no path that permanently drains pool reserves. ## Pages in this section - [Explainer](https://beta.taostats.io/docs/concepts/protocol-changes/shorting/explainer) — conceptual walkthrough: the letter glossary, opening a short, daily decay, the three close scenarios, how you lose, and why subnets benefit from this model. - [Flow — ledger story](https://beta.taostats.io/docs/concepts/protocol-changes/shorting/flow) — the same short followed in three parts (open / decay / three closes) with full TAO/α/Price/P/E/R/Q ledger tables and the close-decision rule at the end. - [Technical reference](https://beta.taostats.io/docs/concepts/protocol-changes/shorting/technical) — spec-to-Subtensor notation map, closed-form open math, per-block decay pseudocode, the three close paths, storage layout (`ShortPosition` and `ShortAgg` Rust structs), governance parameters, the four extrinsics (call indices 139–142), reserve accounting model, and terminal deregistration settlement. - [Simulator](https://beta.taostats.io/docs/concepts/protocol-changes/shorting/sim) — interactive simulator for opens, closes, and decay trajectories. Loads Chart.js from a CDN; otherwise self-contained. ## Source These pages are the canonical migration of Rufus's HTML explainers, authored against the PR #2764 specification (`DESIGN.md` §1–17 and `IMPLEMENTATION_PLAN.md`). Where wording works, it has been preserved lock, stock, and barrel. --- # Bittensor shorting — Explainer Shorting explainer — conceptual walkthrough (canonical document by Rufus) _Source: https://beta.taostats.io/docs/concepts/protocol-changes/shorting/explainer_ _Last reviewed: 2026-09-15_ [Shorting explainer — conceptual walkthrough (canonical document by Rufus)](https://s3.hippius.com/rufus/public/shorting-explainer.html) --- # Bittensor shorting — Flow (ledger story) Shorting flow — ledger story (canonical diagram by Rufus) _Source: https://beta.taostats.io/docs/concepts/protocol-changes/shorting/flow_ _Last reviewed: 2026-09-15_ [Shorting flow — ledger story (canonical diagram by Rufus)](https://s3.hippius.com/rufus/public/shorting-flow-diagram.html) --- # Bittensor shorting — Simulator Shorting simulator (canonical interactive tool by Rufus) _Source: https://beta.taostats.io/docs/concepts/protocol-changes/shorting/sim_ _Last reviewed: 2026-09-15_ [Shorting simulator (canonical interactive tool by Rufus)](https://s3.hippius.com/rufus/public/shorting-sim.html) --- # Bittensor shorting — Technical reference Shorting technical reference (canonical document by Rufus) _Source: https://beta.taostats.io/docs/concepts/protocol-changes/shorting/technical_ _Last reviewed: 2026-09-15_ [Shorting technical reference (canonical document by Rufus)](https://s3.hippius.com/rufus/public/shorting-technical.html) --- # Subnets Subnets: Subnet architecture, Subnet pools, Subnet parameters, Subnet registration, Subnet deregistration, Subnet owner, Subnet owner startup guide, Subnet… _Source: https://beta.taostats.io/docs/concepts/subnets_ _Last reviewed: 2026-09-15_ - [Subnet architecture](https://beta.taostats.io/docs/concepts/subnets/subnet) - [Subnet pools](https://beta.taostats.io/docs/concepts/subnets/subnet-pools) - [Subnet parameters](https://beta.taostats.io/docs/concepts/subnets/subnet-parameters) - [Subnet registration](https://beta.taostats.io/docs/concepts/subnets/subnet-registration) - [Subnet deregistration](https://beta.taostats.io/docs/concepts/subnets/subnet-deregistration) - [Subnet owner](https://beta.taostats.io/docs/concepts/subnets/subnet-owner) - [Subnet owner startup guide](https://beta.taostats.io/docs/concepts/subnets/subnet-owner-startup-guide) - [Subnet Emissions (TAO / Pool)](https://beta.taostats.io/docs/concepts/subnets/subnet-emissions) - [Subnet Emissions (Alpha)](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out) - [Subnet Mechanisms](https://beta.taostats.io/docs/concepts/subnets/subnet-mechanisms) --- # Subnet architecture The Bittensor network's primary division is into a group of subnets. _Source: https://beta.taostats.io/docs/concepts/subnets/subnet_ _Last reviewed: 2026-09-15_ How do Subnets work? The Bittensor network's primary division is into a group of subnets. The subnets are numbered, and there is theoretically no limit to the number of subnets that can exist. Each Subnet runs a self-contained codebase on top of the Bittensor code, each defining a unique context for the incentivised generation of value. Although each subnet is unique and runs with independent sets of participants, the interface with the Bittensor network and use of Yuma Consensus is common across all subnets. (There is also a subnet 0: the [Root Subnet](https://beta.taostats.io/docs/concepts/subnets/root-subnet)). ## Architecture of Subnets ### Subnet Mechanisms (Formerly Subsubnets) Each subnet has a task or mechanism that is performed by the participants. It is now possible for subnets to have **multiple** mechanisms inside a single subnet. These were formerly called subsubnets. At launch: * At launch, a maximum of 2 subnet mechanisms can be implemented, with the ceiling rising to up to 8 mechanisms over time. * Miners and Validators can participate in all mechanisms with a single UID. * Subnet owners can split the emission distribution amongst mechanisms (50:50, 90:10, etc.) * Subnet emission to miners will be based on consensus/incentive on each mechanism, multiplied by the mechanism distribution. * 50:50 split: Miner has 2 incentives 0.1 and 0.2. 0.1 *.5 + 0.2*.5 = 0.15 incentive overall. * 90:10 split: Miner has 2 incentives 0.1 and 0.2. 0.1 *.9 + 0.2*.1 = 0.11 incentive overall. * Subnet emission to validators will be based on Vtrust and Dividends in each subnet mechanism, multiplied by the mechanism distribution. Each subnet reports its mechanism configuration through the [Get Subnets](https://beta.taostats.io/docs/api-reference/subnet/get-subnet-latest) endpoint, via the `sub_subnet_count` (number of mechanisms) and `sub_subnet_emission_split` (per-mechanism emission distribution) fields. ### Mechanism architecture Subnets can have 256 [neurons](https://beta.taostats.io/docs/start-here/glossary#neurons) (netuids 0 and 1 are exceptions to this rule), set in the subnet [hyperparameters](). In time, this will be a custom configurable value. The neurons are a mix of validators and miners with 64 slots reserved for validators and the remainder slots reserved for miners. If validator slots are left unused they can be utilised by miners. In practice, most subnets have 5-15 validators, and the remaining slots are used by miners. > [!NOTE] > **Nervous System Analogy** > > As you dig deeper into Bittensor and AI you will come across vocabulary references to the nervous system such as neurons. Neurons have axons, dendrites and synapses. Since neurons are the way the nervous system transmits data, it is a convenient analogy to describe how data is transmitted through the subnet. > > Easy mode: > > * **Neurons** are nodes or servers running on a subnet. > * **Synapse**: Data sent between neurons > * **Axons**: receives message (server). The neuron's IP:port is considered the axon. > * **Dendrite**: sends message (client) #### Validators Validators are nodes in the subnet that perform two roles. 1. **Validation of miner output**. This is typically done by sending regular requests to each miner and then assigning a value/score to the response. These scores are usually added to a moving average of the miners performance which enables a score (weights) to be set at regular intervals on the blockchain for all miners by that validator. These weights form part of the incentive landscape which when combined with the weights of the other validators using [Yuma Consensus](https://beta.taostats.io/docs/concepts/chain-runtime/consensus) are then used to define and distribute emissions. 2. **Gateway access to the network**. The only way a user or application can query a subnet is through the hotkey of an active validator - therefore validators also act as trusted gateways to the miners which in turn allows miners to prioritise queries based on a stake. ##### Delegated Stake Tao holders can stake their tao with validators. Validators with higher stake receive higher emissions (that are shared with the stakeholders). The weights set by validators is also influenced by the amount of stake held. The amount of tao a validator has as delegated stake defines both the value of the weights they set for miners and as a result allows for a natural market prioritisation of access to form. * [Validator (Architecture)](https://beta.taostats.io/docs/concepts/validators/validation) * [Validator (Persona)](https://beta.taostats.io/docs/concepts/validators/validator) * [Emissions for Validators](https://beta.taostats.io/docs/concepts/validators/dividends-for-validators) #### Miners Miners produce output as defined by the subnet code. This work is usually performed by running code in order to complete tasks. Each subnet has different mechanisms, requiring different expertise and hardware. Although the mechanisms can vary from subnet to subnet, the power of distributed compute is one of the key values of the network. The validators then request this output for both the rewards mechanism and to satisfy any external queries. Miners are ranked by validators and given an incentive score. Miners with higher incentive values receive higher [emissions](https://beta.taostats.io/docs/start-here/glossary#emissions). * [Miner (Architecture)](https://beta.taostats.io/docs/concepts/miners/mining) * [Miner (Persona)](https://beta.taostats.io/docs/concepts/miners/miner) * [Emission for Miners](https://beta.taostats.io/docs/concepts/miners/consensus-for-miners) #### Consensus Each subnet undertakes a specific task. In order to evaluate how the task is being performed, an incentive mechanism is used by validators to evaluate work performed by the miners. The validators score each miner, and set weights on-chain each epoch. These weights are aggregated by [Yuma Consensus](https://beta.taostats.io/docs/concepts/chain-runtime/consensus) to form an overall incentive landscape upon which trust values are calculated to determine emissions. ## Subnet Registration Anyone can register a new subnet provided they have a wallet containing the current subnet registration cost in tao. Once a Subnet is registered, it set to an inactive state. This period allows the new subnet to iron out the last steps, and begin building relationships with miners and validators. There is no emission when a subnet is inactive. In practice, many subnets build in the testnet prior to going "live" on the main bittensor chain. This allows miners and validators to test out the code, and find any issues that might arise. It also allows the subnet team to build awareness of the project, ensuring faster acceptance on chain, and (hopefully) higher emissions. ### Subnet Pool at registration When a new subnet is registered, its [Subnet Pool](https://beta.taostats.io/docs/concepts/subnets/subnet-pools) is seeded from the registration cost: a portion of the lock cost is paid into the pool as TAO, and a matching amount of alpha is minted to set the opening price. The remainder of the lock cost is recycled. ### Registration Cost There is a cost to register a new subnet. The cost for a new registration is based on the demand of subnets - more frequent registrations raise the cost, and then the cost goes down over time. A portion of the lock cost is paid into the [Subnet Pools](https://beta.taostats.io/docs/concepts/subnets/subnet-pools). The remainder is recycled. You can determine the current price using the [Bittensor CLI](https://beta.taostats.io/docs/concepts/command-line-tool): ``` btcli subnet lock_cost >> Subnet lock cost: τ3,796.780457067 ``` Or you can view a historical chart of registration cost at [Taostats](https://taostats.io/subnets). ![A screenshot of the Subnet registration cost over time.](https://beta.taostats.io/images/docs/concepts/dc48e04e-Screenshot_2024-09-03_at_17.35.05.jpg) ### Subnet immunity New subnets have 4 months of immunity from being de-registered. ### Subnet activation New subnets are default not active, and receive no emission. When ready, the subnet owner can "turn on" the subnet, starting emission, and letting validators and miners begin earning emission. `btcli s start` ## Subnet Emission See [Subnet Emission tao and alpha](https://beta.taostats.io/docs/concepts/subnets/subnet-emissions) ## Subnet de-registration In September 2025, subnet deregistration was re-added. The subnet with the lowest moving average price will be deregistered when a new subnet is created. * All alpha is liquidated. All holders of alpha will be given a weighted % of the tao remaining in the subnet pool. This will appear on their coldkey, as unstaked tao. * The new subnet will take over the netuid. --- # Root Subnet The root subnet is netuid 0 — the coordinating subnet at the centre of Bittensor. _Source: https://beta.taostats.io/docs/concepts/subnets/root-subnet_ _Last reviewed: 2026-09-23_ The **root subnet** is netuid 0 — the coordinating subnet at the centre of Bittensor. Staking to root delegates TAO to root validators, who earn dividends from every subnet they validate on. ## Key points * Root uses **only TAO** — there is no alpha token and your root stake carries no subnet-pool price risk. Unclaimed rewards are held as subnet alpha in your validator's basket until you claim. * Root staking is the "safe" option, but root's share of total emissions [decreases over time by design](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha) as subnets mature. * Under [Root Reborn](https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/explainer), root dividends are handled through [validator baskets](https://beta.taostats.io/docs/concepts/staking/root-validator-baskets) and redeemed with a manual `claim_root`. ## Related * [Staking in dTao](https://beta.taostats.io/docs/concepts/staking/staking-in-dtao) * [Root Validator Baskets](https://beta.taostats.io/docs/concepts/staking/root-validator-baskets) * [Emissions: Root vs. Alpha Stake](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha) --- # List of Subnets Bittensor is made up of many subnets, each with its own purpose, token, and emissions. _Source: https://beta.taostats.io/docs/concepts/subnets/list-of-subnets_ _Last reviewed: 2026-09-15_ Bittensor is made up of many subnets, each with its own purpose, token, and emissions. Taostats tracks every subnet with live and historical data. > [!NOTE] > The subnet count and rankings change constantly, so there is no static list here to go stale. For the live, sortable list of every subnet — with emissions, price, and validator data — see the [Subnets explorer on Taostats](https://taostats.io/subnets). ## Explore subnets * **Live data:** [taostats.io/subnets](https://taostats.io/subnets) — every subnet, sortable by emission, price, and activity. * **How subnets work:** [Subnets](https://beta.taostats.io/docs/understanding-taostats/subnets/subnets) * **Subnet pools & pricing:** [Subnet Pools](https://beta.taostats.io/docs/concepts/subnets/subnet-pools) ## Related * [Subnets](https://beta.taostats.io/docs/understanding-taostats/subnets/subnets) * [Subnet emission overview](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out) --- # Subnet pools Subnet pools are liquidity pools that are used to exchange tao for alpha tokens _Source: https://beta.taostats.io/docs/concepts/subnets/subnet-pools_ _Last reviewed: 2026-09-15_ Subnet pools are liquidity pools that are used to exchange tao for alpha tokens ## What is a Subnet Liquidity Pool? A subnet pool (AKA liquidity pool) is a way to exchange between two currencies. In the case of subnet pools, they are used to exchange tao into the subnet's alpha token. There are two values in the subnet pool: `alpha_in` and `tao_in` * **alpha\_in**: The amount of alpha currently in the subnet pool * **tao\_in**: The amount to tao currently in the subnet pool. Inside the pool, the tao/alpha ratio sets the price. In the simplest case the pool behaves like a constant-product AMM — the product of the two reserves is a constant k: $$ k = \alpha_{pool} \cdot tao_{pool} $$ > [!NOTE] > **Example subnet pool (shown in yellow) with 100τ and 100α.** > > ![Diagram of a two-sided subnet pool with a tau reserve container and an alpha reserve container meeting at a highlighted pooled-reserve region](https://beta.taostats.io/images/docs/concepts/taostats-subnet-pool-reserves-diagram.png) > > k = 100\* 100 = 10,000 ### Emissions Each block, tao and alpha are emitted into the liquidity pool. * [Tao emission](https://beta.taostats.io/docs/concepts/tokenomics/tao#distribution-of-emitted-tao) * [Alpha Emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission) Note that the value of k will change with each block as a result of this emission. ### Alpha Price The subnet pool determines the alpha price (shown in tao). $$ \alpha_{price} = \dfrac{\tau_{pool}}{\alpha_{pool}} $$ > [!NOTE] > **If there is 100 tao\_in, and 100 alpha\_in, the α\_price will be 1 tao.** ### Subnet Pool Initialization When a new subnet is registered, the pool is seeded from the [registration cost](https://beta.taostats.io/docs/concepts/subnets/subnet-registration): a portion of the lock cost is paid in as TAO (`tao_in`), and a matching amount of alpha is minted (`alpha_in`) to set the opening price. The remainder of the lock cost is recycled. The starting `alpha_price` is therefore the ratio of the seeded reserves. --- # Subnet parameters In addition to miners and validator code, each subnet has a set of hyperparameters that define how it will interact with the bittensor network. _Source: https://beta.taostats.io/docs/concepts/subnets/subnet-parameters_ _Last reviewed: 2026-09-15_ In addition to miners and validator code, each subnet has a set of hyperparameters that define how it will interact with the bittensor network. ### Full hyperparameter reference The canonical, current list of subnet hyperparameters (as of the latest chain release). **Owner-settable** shows whether the subnet owner can change the value themselves (`✅ yes`) or whether it is `sudo only` (governance / sudo-controlled). Read the live values for a subnet with `btcli sudo get --netuid `; owners change the owner-settable ones with `btcli sudo set`. > [!NOTE] > This table is reconciled against the official chain docs ([RaoFoundation/subtensor](https://github.com/RaoFoundation/subtensor)) and regenerated on each chain release. If a parameter here doesn't match what `btcli` returns, the chain is the source of truth — flag it and we'll re-sync. | Hyperparameter | Unit | Owner-settable | What it controls | |---|---|---|---| | `rho` | integer | ✅ yes | trust curve steepness | | `kappa` | fraction (u16, 65535 = 1.0) | sudo only | consensus majority-stake threshold | | `immunity_period` | blocks (12s) | ✅ yes | prune-immunity window for new neurons | | `min_allowed_weights` | integer | ✅ yes | minimum weights per submission | | `max_weights_limit` | fraction (u16, 65535 = 1.0) | sudo only | cap on a single miner's weight | | `tempo` | blocks (12s) | ✅ yes | blocks per consensus epoch | | `min_difficulty` | PoW difficulty (u64) | sudo only | PoW registration difficulty floor | | `max_difficulty` | PoW difficulty (u64) | ✅ yes | PoW registration difficulty ceiling | | `difficulty` | PoW difficulty (u64) | sudo only | current PoW registration difficulty | | `weights_version` | integer | ✅ yes | minimum version key for set_weights | | `weights_rate_limit` | blocks (12s) | sudo only | wait between weight submissions | | `adjustment_interval` | blocks (12s) | sudo only | difficulty/burn adjustment cadence | | `activity_cutoff` | blocks (12s) | sudo only | no-weights window before inactive | | `activity_cutoff_factor` | integer | ✅ yes | activity cutoff, per-mille of tempo | | `registration_allowed` | flag | sudo only | new neuron registrations allowed | | `network_pow_registration_allowed` | flag | ✅ yes | PoW registration toggle | | `target_regs_per_interval` | integer | sudo only | registration-rate controller target | | `min_burn` | TAO amount in rao | ✅ yes | burned-registration cost floor | | `max_burn` | TAO amount in rao | ✅ yes | burned-registration cost ceiling | | `bonds_moving_avg` | fraction (1,000,000 = 1.0) | ✅ yes | bonds EMA smoothing factor | | `max_regs_per_block` | integer | sudo only | per-block registration cap | | `serving_rate_limit` | blocks (12s) | ✅ yes | cooldown between axon serve calls | | `max_validators` | integer | sudo only | top-stake validator permit cap | | `adjustment_alpha` | fraction (u64, u64::MAX = 1.0) | ✅ yes | difficulty/burn adjust smoothing | | `commit_reveal_period` | epochs (tempos) | ✅ yes | weight commit-to-reveal delay | | `commit_reveal_weights_enabled` | flag | ✅ yes | commit-reveal weights toggle | | `alpha_high` | fraction (u16, 65535 = 1.0) | ✅ yes | liquid-alpha smoothing upper bound | | `alpha_low` | fraction (u16, 65535 = 1.0) | ✅ yes | liquid-alpha smoothing lower bound | | `liquid_alpha_enabled` | flag | ✅ yes | per-weight bonds EMA (liquid alpha) | | `bonds_penalty` | fraction (u16, 65535 = 1.0) | ✅ yes | penalty on out-of-consensus bonds | | `alpha_sigmoid_steepness` | integer | ✅ yes | liquid-alpha sigmoid steepness | | `min_childkey_take` | fraction (u16, 65535 = 1.0) | ✅ yes | floor for childkey take | | `owner_immune_neuron_limit` | integer | ✅ yes | owner-designated prune-immune UIDs | | `max_allowed_uids` | integer | ✅ yes | neuron slot capacity before pruning | | `burn_increase_mult` | multiplier (U64F64 bits / 2^64) | ✅ yes | burn cost bump per registration | | `burn_half_life` | blocks (12s) | ✅ yes | burn cost decay half-life | | `collateral_lock_share` | fraction (u16, 65535 = 1.0) | ✅ yes | registration price share locked | | `collateral_drain_ratio` | multiplier (U64F64 bits / 2^64) | ✅ yes | collateral released per α earned | | `yuma3_enabled` | flag | ✅ yes | yuma3 consensus variant toggle | | `yuma_version` | integer | sudo only | epoch consensus variant (2 or 3) | | `subnet_is_active` | flag | sudo only | subnet started (staking + emissions) | | `subnet_emission_enabled` | flag | sudo only | root switch for TAO emission share | | `user_liquidity_enabled` | flag | sudo only | legacy user-LP flag (always false) | | `bonds_reset_enabled` | flag | ✅ yes | bonds reset on metadata commit | | `transfers_enabled` | flag | ✅ yes | stake transfers between coldkeys | | `owner_cut_enabled` | flag | ✅ yes | owner emission cut toggle | | `owner_cut_auto_lock_enabled` | flag | ✅ yes | auto-lock the owner's emission cut | ### Taostats Each subnet tab lists pertinent hyperparameters: ![Dark-themed subnet metagraph tab with a Settings & Metrics grid of hyperparameter label-value cards including UID counts, validator/miner counts, and epoch countdowns](https://beta.taostats.io/images/docs/concepts/taostats-subnet-hyperparameters-metrics-panel.png) The full list can be found at: [https://taostats.io/settings?subnet=19](https://taostats.io/settings?subnet=19) (update the subnet number for the specific subnet parameters) ### Using CLI To see the parameters of a subnet, use the `btcli su get`**or** `btcli s hyperparameters` Here are example parameters from Subnet 15 at the time of writing: ``` btcli s hyperparameters Netuid: 19 Subnet Hyperparameters NETUID: 19 - Network: finney HYPERPARAMETER VALUE NORMALIZED ───────────────────────────────────────────────────────────────────────── rho 10 10 kappa 32767 0.4999923705 immunity_period 7000 7000 min_allowed_weights 1 1 max_weight_limit 65535 1 tempo 360 360 min_difficulty 18446744073709551615 1 max_difficulty 18446744073709551615 1 weights_version 60000 60000 weights_rate_limit 100 100 adjustment_interval 360 360 activity_cutoff 20000 20000 registration_allowed True True target_regs_per_interval 1 1 min_burn 100 τ0.000000100 max_burn 100000000000 τ100.000000000 bonds_moving_avg 900000 4.878909776e-14 max_regs_per_block 1 1 serving_rate_limit 50 50 max_validators 64 64 adjustment_alpha 14757395258967642112 0.8 difficulty 18446744073709551615 1 commit_reveal_weights_interval 1 1 commit_reveal_weights_enabled False False alpha_high 58982 0.9000076295 alpha_low 45875 0.7000076295 liquid_alpha_enabled False False ───────────────────────────────────────────────────────────────────────── ``` ## Hyperparameter descriptions * **rho**: 10 for all subnets. [Rho](https://github.com/opentensor/bittensor/blob/0759f6a584a05e0d1dcbbf2baf54ae80b36e26cb/bittensor/subtensor.py#L2647_) (p) is calculated based on the network's target inflation and actual neuron staking. It adjusts the emission rate of the TAO token to balance the network's economy and dynamics. The formula for Rho is defined as: p = (Staking\_Target / Staking\_Actual) \* Inflation\_Target. Here, Staking\_Target and Staking\_Actual represent the desired and actual total stakes in the network, while Inflation\_Target is the predefined inflation rate goal. * **kappa**: 32767 for all subnets. [Kappa](https://github.com/opentensor/bittensor/blob/0759f6a584a05e0d1dcbbf2baf54ae80b36e26cb/bittensor/subtensor.py#L2661C13-L2665C115) (κ) is used in the calculation of neuron ranks, which determine their share of network incentives. It is derived from the softmax function applied to the inter-neuronal weights set by each neuron. The formula for Kappa is: κ\_i = exp(w\_i) / Σ(exp(w\_j)), where w\_i represents the weight set by neuron i, and the denominator is the sum of exponential weights set by all neurons. This mechanism ensures a normalized and probabilistic distribution of ranks based on relative weights. * **Immunity Period**: This parameter defines the duration during which new neurons are protected from certain network penalties or restrictions. (At 12 s/block, 1000 blocks is \~ 3.3 hours.) * **Min Allowed Weights**: The minimum number of UIDs a subnet validator must set weights on, before the subnet validator is allowed to set weights on the blockchain. * **Max Weight Limit**: Highest weight value that can be set by a validator. This is a float value. * **Tempo**: Cadence of updates, in blocks. * **min\_difficulty / max\_difficulty / difficulty**: PoW registration difficulty floor, ceiling, and current value. Only relevant on subnets that allow proof-of-work registration (`network_pow_registration_allowed`); most subnets use burned registration instead. * **weights version**: Sets the minimum version of validator code that a validator can use (and still set weights). * **weights rate limit**: time (in blocks) that a validator may update weights. * **adjustment\_interval**: Time (in blocks) after which the node registration cost is re-evaluated. If the number of actual registrations that occurred in the last `adjustment_interval` is higher than the [`target_regs_per_interval`](#target_regs_per_interval), then the blockchain will raise the recycle register cost, by increasing the [`min_burn`](#min_burn-max_burn) value by a certain amount, in order to slow down the actual registrations and bring them back to `target_regs_per_interval` value. * **[activity cutoff](https://github.com/opentensor/developer-docs/blob/4d0319415d96462c1ffc48c76f2f9c913df5707e/docs/subnets/subnet-hyperparameters.md?plain=1#L219):** * Expressed in number of blocks. If a subnet validator has not set weights on the blockchain for `activity_cutoff` duration, then the Yuma Consensus will consider this subnet validator as offline, i.e., turned off. The weights of this subnet validator are considered too old to be useful. The weights of this subnet validator slowly lose their impact over time and eventually will no longer be considered for consensus calculation. * **registration\_allowed**: When a subnet updates or there is an issue - the subnet owner may pause registrations to allow for all miners and validators to update their servers without the risk of deregistration. When registration is turned off, emission to the subnet is recycled, and no participants receive emission. * **target\_regs\_per\_interval**: Number of nodes that can be registered per epoch. In the example above, just one node can be registered per interval. * **min\_burn/max\_burn**: Node registration costs (in rao - 1e-9 tao). The right column shows the value in tao. * **serving\_rate\_limit**: Determines how often you can change your node's IP address on the blockchain. Expressed in number of blocks. Applies to both subnet validator and subnet miner nodes. Used when you move your node to a new machine. * **[Bonds Moving Avg](https://github.com/opentensor/developer-docs/blob/4d0319415d96462c1ffc48c76f2f9c913df5707e/docs/subnets/subnet-hyperparameters.md?plain=1#L289)** : * This parameter controls how fast bonds will decay in the entire subnet. This is a unitless number. This number has a direct impact on subnet validator. The faster the bonds decay the quicker a subnet validator will lose its dividends after the subnet validator is out of the `activity_cutoff`.\ If this `bonds_moving_avg` value is low, then the moving average of the bonds will decay slowly. This will allow the subnet validator to become active again, start setting new weights and start earning new bonds.\ If this `bonds_moving_avg` value is high, then bonds in the subnet decay quickly. As a result, a subnet validator who has fallen out of the `activity_cutoff` and hence is running the risk of being viewed as "turned off", may not be able to become active again. * **Max Validators**: The number of validator slots available in the subnet. * **Adjustment alpha:** Larger numbers smooth the registration burn costs epoch to epoch. * **Commit Reveal Period**: Weights are encrypted for this many epochs (tempos) before auto-reveal, to prevent [Weight Copying](https://beta.taostats.io/docs/concepts/validators/weight-copying). (Formerly `commit_reveal_weights_interval`, measured in blocks.) * **Commit Reveal Weights Enabled**: Boolean if commit reveal is on or off. * **alpha\_high/alpha\_low**: used in Liquid alpha math. Not related to the alpha token * **Liquid Alpha Enabled**: Liquid alpha allows for a Consensus based weights. --- # Subnet registration Subnet registration and deregistration are live on the chain. _Source: https://beta.taostats.io/docs/concepts/subnets/subnet-registration_ _Last reviewed: 2026-09-15_ Subnet registration and deregistration are live on the chain. ## Subnet Registration Anyone can register a new subnet by paying the current registration (lock) cost in TAO. The cost is demand-based: it rises as registrations become more frequent and decays back down over time. ### Current registration cost Read the current lock cost with the [Bittensor CLI](https://beta.taostats.io/docs/concepts/command-line-tool): ``` btcli subnet lock_cost >> Subnet lock cost: τ3,796.780457067 ``` The live and historical cost is also available programmatically: * [Get Subnet Registration Cost (latest)](https://beta.taostats.io/docs/api-reference/subnet/get-subnet-registration-cost-latest) * [Get Subnet Registration Cost (history)](https://beta.taostats.io/docs/api-reference/subnet/get-subnet-registration-cost-history) Or view the historical chart on the [Subnet Home](https://taostats.io/subnets). ### Where the cost goes A portion of the registration cost is paid into the subnet's liquidity pool (with a matching amount of alpha minted to hold the price); the remainder is recycled. The registering owner does *not* receive a matching alpha allocation. The earlier "alpha-to-owner" mechanic — where the subnet owner was minted alpha equal to the lock cost at registration — has been removed. Owners now participate in their subnet's economics through the dTao market like any other holder. ### Registration cadence and cap Once a subnet is registered, there is a 4-day window before the next registration can occur. If the current maximum number of subnets has been reached, registering a new subnet deregisters the lowest-priced subnet (subject to immunity — see below). ### Immunity New subnets have 4 months of immunity from deregistration. ### Deregistration For how a subnet is chosen for deregistration and how alpha holders are paid out, see [Subnet Deregistration](https://beta.taostats.io/docs/concepts/subnets/subnet-deregistration). --- # Subnet deregistration When a subnet is deregistered, its entire TAO reserve is drained and paid out pro-rata by alpha across everyone with a claim on the pool. _Source: https://beta.taostats.io/docs/concepts/subnets/subnet-deregistration_ _Last reviewed: 2026-09-15_ When a subnet is deregistered, its entire TAO reserve is drained and paid out pro-rata by alpha across everyone with a claim on the pool. TAO you receive lands in your coldkey free balance. Since runtime 415 (subtensor v3.4.2-415), not all of that TAO reaches stakers. A portion is withheld from the pool and recycled (removed from circulation), and that portion is baked into the per-alpha payout you see as the subnet's liquidation price on [taostats.io/subnets](https://taostats.io/subnets). ## The deregistration → registration timeline Deregistration and the registration that triggers it happen close together but are distinct on-chain events: 1. **Block *x* — the old subnet is dissolved.** The chain drains the subnet's entire `SubnetTAO` pot and computes each holder's share (see [What actually happens](#what-actually-happens-on-deregistration) below). All alpha holdings are effectively sold at the liquidation price. 2. **Blocks between *x* and *y* — TAO is paid out.** Each holder's TAO share is transferred from the subnet's protocol address to their coldkey free balance. These land as ordinary `Balances.transfer` events from the protocol address. 3. **Block *y* — the new subnet is created.** The incoming registration that pushed the subnet count over the cap takes the freed netuid slot. ## Two ways to find the TAO a holder received **Method 1 — map the transfer events (empirical).** Walk every `Balances.transfer` event out of the subnet's protocol address from block *x* to block *y* and sum the amounts to each coldkey. This is the ground truth of what actually landed, and Taostats indexes these transfers via the [events API](https://beta.taostats.io/docs/understanding-taostats/events/events-detail). Use this when you want the exact figure a specific coldkey received. **Method 2 — compute from the liquidation price (analytical).** Multiply the holder's alpha by the liquidation price. This reconstructs the same number from chain state without walking events: $$ \text{tao received} = \text{your }\alpha \times \text{liq price} $$ where the liquidation price depends on when the subnet was registered: $$ \text{registration\_block} \le 8{,}334{,}450:\quad \text{liq price} = \dfrac{\text{total\_tao}}{\alpha_{staked} + \alpha_{protocol}} $$ $$ \text{registration\_block} > 8{,}334{,}450:\quad \text{liq price} = \dfrac{\text{total\_tao}}{\alpha_{staked} + \alpha_{protocol} + \alpha_{in}} $$ $\alpha_{staked}$ is the sum of every staker's actual alpha (per hotkey, per coldkey share-pool value). $\alpha_{protocol}$ is `SubnetProtocolAlpha`; $\alpha_{in}$ is `SubnetAlphaIn`. The gate block 8,334,450 is `TaoInRefundDeploymentBlock` on finney. Method 2 matches Method 1 for staker payouts; it will not show the withheld protocol/pool-reserve slice, because that TAO is recycled rather than transferred to anyone. ## When does a subnet get deregistered? For a subnet to be deregistered, it must be: 1. Out of immunity (subnets have 4 months of immunity from registration). 2. The lowest-priced subnet at the time a new registration would push the count over the cap. If two subnets tie on the lowest price, the older one is deregistered. ## Who has a claim on the pool At deregistration, the total alpha the TAO pot is divided against is the sum of: - Every staker's alpha (per hotkey, per coldkey). - `SubnetProtocolAlpha` — protocol-owned alpha accumulated from per-block chain buys. Always included. - `SubnetAlphaIn` — the AMM pool-reserve alpha paired against `SubnetTAO`. Included for new subnets only (see the gate below). Three distinct pools of alpha share the denominator: **Staker alpha.** Alpha you hold, tracked in per-(hotkey, coldkey) share pools. Always in the denominator; stakers get their pro-rata TAO share into their coldkey free balance. **Protocol alpha (`SubnetProtocolAlpha`).** Alpha the protocol accumulates from per-block chain buys. Always in the denominator; its TAO share is not paid out — it is recycled. **Pool-reserve alpha (`SubnetAlphaIn`).** The AMM reserve alpha paired against `SubnetTAO`. In the denominator for new subnets only; its TAO share is also recycled. ### Where `SubnetProtocolAlpha` comes from Each block, a subnet's excess TAO is swapped TAO to alpha by the coinbase. Before runtime 415 that chain-bought alpha was recycled immediately. Since runtime 415, it is retained in `SubnetProtocolAlpha` and only settled at deregistration. ## Legacy vs. new subnets Whether `SubnetAlphaIn` is included in the denominator depends on when the subnet was registered: - If the subnet was registered after `TaoInRefundDeploymentBlock`, it is a new subnet: the denominator includes `SubnetAlphaIn` and `SubnetProtocolAlpha`. - Otherwise it is a legacy subnet: the denominator includes `SubnetProtocolAlpha` only. `TaoInRefundDeploymentBlock` was stamped at the block runtime 415 activated. On finney it is block 8,334,450. Both legacy and new subnets distribute `SubnetProtocolAlpha`. The gate only toggles pool-reserve alpha. Not to be confused with `NetworkRegistrationStartBlock` (6,573,966), which governs the owner lock-cost refund path — a separate mechanism described below. ## What actually happens on deregistration When the chain dissolves a subnet, it: 1. Finalizes root dividends for the subnet. 2. Computes the total alpha denominator using the rules above. 3. Removes the full `SubnetTAO` pot from the subnet and from `TotalStake`. 4. Splits the pot pro-rata using the largest-remainder method. Each staker's share goes to their coldkey free balance. The `SubnetProtocolAlpha` share (and `SubnetAlphaIn` share on new subnets) is accumulated into an internal protocol TAO share and is not paid to any staker. 5. Destroys all per-key alpha, hotkey share-pool totals, and the `SubnetAlphaIn`, `SubnetAlphaOut`, and `SubnetProtocolAlpha` counters. 6. Applies the owner lock refund on legacy subnets registered before `NetworkRegistrationStartBlock`. The refund is `max(0, lock_cost − owner_received_emission_in_tao)` and cannot draw from the withheld protocol TAO share. 7. Recycles any TAO left on the subnet account — including the withheld protocol TAO share — via `recycle_tao`. That TAO is burned back and recorded in `RAORecycledForRegistration`. 8. Clears the remaining subnet storage (params, weights, emissions, locks, token symbol, mechanism) and emits `NetworkRemoved`. ## Why per-alpha payout is lower than "pot divided by staker alpha" The protocol's alpha stays in the denominator on purpose. It dilutes the per-alpha payout so the number you see reflects that some of the pot leaves the holder pool entirely. Worked example. Suppose at deregistration a subnet has `SubnetTAO = 100 τ` and: - Stakers hold 70 alpha in total. - Protocol alpha (`SubnetProtocolAlpha` plus `SubnetAlphaIn` where applicable) is 30 alpha. - Total denominator is 100 alpha. Then: - Per-alpha price is 100 τ / 100 alpha = 1 τ per alpha. - Stakers collectively receive 70 × 1 = 70 τ, split by individual alpha. - The protocol's 30 τ slice is withheld and recycled — it does not reach stakers. Dividing 100 τ by only the 70 staker alpha would give 1.43 τ per alpha and overstate every holder's payout by about 43%. The live liquidation price shown on each [subnet page](https://taostats.io/subnets) already accounts for the full denominator. **New subnets** (registered after block 8,334,450): $$ \text{liq price} = \dfrac{\text{total\_tao}}{\alpha_{staked} + \alpha_{protocol} + \alpha_{in}} $$ **Legacy subnets** (registered at or before block 8,334,450): $$ \text{liq price} = \dfrac{\text{total\_tao}}{\alpha_{staked} + \alpha_{protocol}} $$ Here $\alpha_{staked}$ is the sum of every staker's actual alpha share-pool value (summed per hotkey, per coldkey at dissolve) — **not** the `SubnetAlphaOut` issuance counter, which the payout math does not use. $\alpha_{protocol}$ is `SubnetProtocolAlpha` and $\alpha_{in}$ is `SubnetAlphaIn`. Your own payout is $\text{liq price} \times \text{your }\alpha$. ## Liquidation price vs. market price The liquidation price is the effective per-alpha TAO you receive from draining the pool, after the denominator dilution above. - If the liquidation price is above the current market price, holders are paid a premium versus market. - If it is below, holders take a loss versus market. Live liquidation prices are on each subnet page at [taostats.io/subnets](https://taostats.io/subnets). ## Storage items involved - `SubnetTAO` — TAO reserve in the subnet. This is the pot distributed at deregistration. - `SubnetProtocolAlpha` — protocol-owned alpha accumulated from per-block chain buys (runtime 415 and later). - `SubnetAlphaIn` — AMM pool-reserve alpha paired against `SubnetTAO`. - `SubnetAlphaOut` — alpha issuance tracker (staked-out alpha). Not used in the liquidation-price denominator; the payout math sums actual staker share-pool alpha instead. - `TaoInRefundDeploymentBlock` — cutover block for the new denominator rule. On finney: 8,334,450. - `NetworkRegisteredAt` — the block a subnet was registered. Determines legacy vs. new. - `NetworkRegistrationStartBlock` — 6,573,966. Determines eligibility for the owner lock-cost refund. ## Source This behaviour is defined in `pallets/subtensor/src/staking/remove_stake.rs::destroy_alpha_in_out_stakes` and `pallets/subtensor/src/coinbase/root.rs::do_dissolve_network` in the [opentensor/subtensor](https://github.com/opentensor/subtensor) repository, spec_version 425. The relevant runtime is v3.4.2-415, published in commits d1de05615 and f40f4ae6f. --- # Subnet owner A group or organisation that owns the key to and controls the codebase of a subnet _Source: https://beta.taostats.io/docs/concepts/subnets/subnet-owner_ _Last reviewed: 2026-09-15_ A group or organisation that owns the key to and controls the codebase of a subnet If you have an idea for the creation of a decentralised machine learning or commodity through a novel validation and incentive mechanism design, you can build a subnetwork for Bittensor. ## Idea What is the purpose of the subnet? What is the commodity/machine learning commodity you are looking to provide and where does it derive its value? Everything starts with an idea or a problem to solve. ## Process Subnet owners are responsible for providing the base miner and validator code. They also design the all important incentive mechanism on which value is assigned to miners work. * Handling all vectors that miners or validators might use to subvert the subnet. There are very in depth tutorials for [creating a subnet](https://docs.bittensor.com/tutorials/basic-subnet-tutorials) covered in the official Bittensor Documentation which we will not attempt to cover here, however the process deployment can be broken down as * Running locally: During the initial construction phase most development teams will build locally. * Running on Bittensor testnet: Once the code base is complete and ready for testing it is possible to deploy on the Bittensor testnet, which emulates a similar environment and conditions to mainnet, in order to refine the code and processes, deploy and support applications and infrastructure, and to start introducing network participants to the product. * Running on Bittensor mainnet: Once the subnet has proven itself on testnet and feels ready to deploy on mainnet, the registration fee must be locked up and the subnet becomes live on the main Bittensor network. Newly registered UIDs have an immunity period (currently around 4 months, governed by the subnet's `ImmunityPeriod` hyperparameter) before they can be deregistered by having the lowest stake-weighted score. ## Registration To register a subnet, the subnet owner must pay the lock cost. A portion seeds the subnet pool; the remainder is recycled. It is not returned to the owner. Once a new subnet is registered, Emissions are turned off to allow the SN owner some time to test their code, and work through any kinks in their framework. When the SN owner is ready to start their subnet, they call the `start_call` extrinsic to turn on emission to their subnet. > [!NOTE] > **When in startup mode** > > * Set your identity on the chain `btcli s set-identity` > * The owner hotkey (UID 0) will have the same address as your coldkey. Do a hotkey swap. > * Test validation. Make sure your validator can set weights, and is doing so on the regular. UID 0 is a good place for you validator. You'll receive your owner rewards and validation rewards to the same hotkey. > * Do you allow Neuron registration before you begin emission? Note that Subnets that are registered, but have not started the subnet will have 0 emission. Have a great subnet idea? Read the [Subnet Owner Startup Guide](https://beta.taostats.io/docs/concepts/subnets/subnet-owner-startup-guide) for design frameworks, incentive-mechanism resources, and the post-registration launch checklist. ## Subnet Owner Neuron Every subnet owner is given an immune neuron (UID 0 by default). ### Mining The owner cannot run a miner on this hotkey to receive alpha. Any incentive (mining) emission directed to an owner or owner-immune hotkey is withheld from the miner pool — it does not pay alpha to the owner — and counts toward the subnet's `MinerBurned` proportion the following tempo, reducing the subnet's chain emission share. Whether the subnet's `RecycleOrBurn` configuration recycles or burns the withheld emission, the penalty applies identically. There is no toggle that lets an owner recover that incentive as alpha. See [Price-based emission shares](https://beta.taostats.io/docs/concepts/protocol-changes/price-based-emission-shares) for the full `MinerBurned` mechanic. ### Validation Subnet owners are incentivized to run a validator. They are best placed to judge miner results and to provide access to the subnet for external users. It is also an additional revenue stream — the 18% owner alpha can be staked to a validator and earn additional alpha returns on the holdings. --- # Subnet owner startup guide You've got a subnet idea, or you've just registered one. _Source: https://beta.taostats.io/docs/concepts/subnets/subnet-owner-startup-guide_ _Last reviewed: 2026-09-15_ You've got a subnet idea, or you've just registered one. This guide takes you from initial design through launch. The page is split into two halves: - **Designing a subnet** — frameworks, incentive mechanism resources, prior-art talks. Useful pre-registration. - **Launching your subnet** — identity, validator, starting emission, immunity, UID pruning. Useful post-registration. For the broader concept of what a subnet owner _is_, see [Subnet Owner](https://beta.taostats.io/docs/concepts/subnets/subnet-owner). ## Designing a subnet ### Incentive mechanism resources Talk on validator setup and incentive design: [Bittensor subnet owner Hotkey: How to set up and use](https://www.youtube.com/watch?v=wZhgzMKc05I) * namoray spoke on the Bittensor Guru podcast about his vision of subnets in [Episode 20](https://bittensor.guru/episode-20-subnet-19-vision-w-namoray) — a good introduction to subnet creation. * Rhef (Subnet 12) has published a [subnet guide](https://docs.google.com/document/d/10wRkMVv5rfjHtJwDYMZkMl4v6_MHtJEABK3X5aIXhdg/edit#heading=h.4y6sli8eoiyn) covering practical lessons from running a live subnet. ## Launching your subnet ### Subnet identity Identity can be set at registration time, or changed later with `btcli s set-identity`. This is how Taostats shows your name, logo, and links. Check the current identity with `btcli s get_identity`: ``` Current Subnet 1 Identity Item ┃ Value ━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Netuid │ 1 subnet_name │ Apex github_repo │ https://github.com/macrocosm-os/apex subnet_contact │ support@macrocosmos.ai subnet_url │ https://apex.macrocosmos.ai discord │ macrocrux description │ Building the world's fastest deep researchers logo_url │ https://www.macrocosmos.ai/images/mc_logo_black.png additional │ ~ ────────────────┼───────────────────────────────────────────────────── │ ``` > [!NOTE] > **Tips for setting identity** > > The biggest pitfall is the logo URL. > > The `logo_url` **must** be the URL of the raw image — not the URL of a page hosting the image. > > For example: > > ❌ `https://github.com/taostat/.github/blob/main/profile/taostats.png` > > This is a page hosting the image. Right-click the image and open it in a new tab to find the raw URL. > > ✅ `https://raw.githubusercontent.com/taostat/.github/refs/heads/main/profile/taostats.png` > > This is the link to the image served directly by GitHub. Use this form. ### Immune owner neurons Owners can set how many immune neurons they have via the `ImmuneOwnerUidsLimit` parameter. The default is 1; the max is 10. ### Running a validator All subnet owners have at least one neuron that cannot be deregistered. This is intended to be run as a validator: * Validators provide access to the subnet's commodity. With a validator, you have access to your own commodity. * Mining emission to this hotkey is burned (see [Subnet Owner Neuron](https://beta.taostats.io/docs/concepts/subnets/subnet-owner#subnet-owner-neuron) for details). The owner cannot run a miner on this hotkey to receive alpha. #### Setting up a validator * Make sure your validator is setting weights. * Work with other validators to ensure they are running the subnet code and that your validator is in consensus. ### Starting emission Subnets on registration are not active. Run `btcli subnet start` to start emission on your subnet. ### Subnet immunity You have 4 months of immunity from registration to build up your subnet. After 4 months, if your subnet has the lowest moving price, it may be deregistered. ### UID pruning At launch your subnet has 256 UIDs. This can be reduced to a lower number. ### Subnet mechanisms Subnet mechanisms are a way to run different tasks on a single subnet. See [Subnet Architecture — Subnet Mechanisms](https://beta.taostats.io/docs/concepts/subnets/subnet#subnet-mechanisms-formerly-subsubnets) for the current implementation. ### What's next * Once your subnet is live, your emission share is governed by the demand formula (price EMA with miner-burn scaling) feeding the spec 440 emission gate. See [Subnet Emissions](https://beta.taostats.io/docs/concepts/subnets/subnet-emissions) for how emission is computed and its implications for owner self-emission. * See [Subnet Owner](https://beta.taostats.io/docs/concepts/subnets/subnet-owner) for the broader role and responsibilities of a subnet owner. --- # Subnet Emissions (TAO / Pool) Every block, each emit-enabled subnet receives a share of TAO emission and mints alpha. _Source: https://beta.taostats.io/docs/concepts/subnets/subnet-emissions_ _Last reviewed: 2026-09-15_ > [!NOTE] > **Current emission basis** > > This page describes the live, on-chain behavior after PRs [#2779](https://github.com/opentensor/subtensor/pull/2779) and [#2781](https://github.com/opentensor/subtensor/pull/2781) (merged 2026-06-23), as modified by the **spec 440 emission gate** (2026-07-27). The price-based quantity below is now the *demand* input to the gate, not the final share — see [The emission gate](https://beta.taostats.io/docs/concepts/protocol-changes/emission-gate) and [Price-based emission shares](https://beta.taostats.io/docs/concepts/protocol-changes/price-based-emission-shares). ## tao and alpha emissions Every block, each emit-enabled subnet receives a share of TAO emission and mints alpha. The flows are: * **`tao_in`** — TAO emitted into the subnet pool, set by the price-based shares formula. * **`alpha_in`** — alpha added to the subnet pool, set by `min(tao_emission/price, root_proportion × alpha_emission)`. * **`alpha_out`** — alpha distributed to subnet stakeholders. See also: [Tao Emission Distribution](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission), [Alpha Emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission). ## `tao_in` `tao_in` is the TAO that flows into the subnet's liquidity pool each block. It is **not** the subnet's full TAO emission — that emission splits between `tao_in` (pool injection) and on-chain alpha buys. The combined share each subnet receives is set in two stages. First the chain computes each subnet's **demand**: $$ demand_i(s_i) \propto price_i \times (1 - miner\_burned_i) $$ renormalized across all emit-enabled subnets. As of **spec 440**, this demand is *not* the emission share — it feeds a **Hill-function gate** at a quantile bar θ that boosts above-bar subnets and chokes the below-bar tail toward zero, then renormalizes: $$ emission_i \propto s_i \times gate(s_i), \qquad gate(s) = \dfrac{s^h}{s^h + \theta^h} $$ `tao_in` is the slice of the **gated** emission that lands in the pool; the remainder funds on-chain alpha buys (see [Tao Emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) for the chain-buy path). * **`price_i`** — the subnet's `SubnetMovingPrice` exponential moving average, normalized across emit-enabled subnets. * **`(1 − miner_burned_i)`** — penalty for subnets that routed last tempo's miner emission to owner or owner-immune hotkeys. Applies whether the withheld emission was burned or recycled. * **`gate(s_i)`** — the spec 440 emission gate. See [The emission gate](https://beta.taostats.io/docs/concepts/protocol-changes/emission-gate) for θ, `h`, `q`, and the redistribution. If the weighted demand sum is zero (all subnets at full burn), the chain falls back to raw normalized `price` shares and emission still flows. See: [The emission gate](https://beta.taostats.io/docs/concepts/protocol-changes/emission-gate) for the gate, and [Price-based emission shares](https://beta.taostats.io/docs/concepts/protocol-changes/price-based-emission-shares) for how demand is built. ## `alpha_in` `alpha_in` is the alpha added to the subnet pool each block: $$ alpha\_in_i = \min\!\left(\dfrac{tao\_emission_i}{price_i},\ root\_proportion_i \times alpha\_emission\right) $$ where `tao_emission_i` is the subnet's per-block TAO emission, `price_i` is the pool's current alpha price in TAO, and `alpha_emission` is the base alpha mint per block (≤ 2, subject to halving). The cap is `root_proportion × alpha_emission`; the first term is the alpha you'd get by injecting the full TAO emission at the current pool price. The smaller of the two is what enters the pool. Any TAO that doesn't get matched into the pool funds on-chain alpha buys instead — see [Tao Emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission). For subnets with low `root_proportion` (older subnets with significant alpha issuance), most fresh alpha enters circulation via chain buys rather than direct pool injection. See: [Alpha Emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission) for the alpha-supply schedule. ## `alpha_out` Every block, `alpha_out` (the per-block alpha distributed to subnet stakeholders) is distributed amongst stakeholders according to the subnet's incentive distribution. For the full walkthrough of how `alpha_out` is split across miners, validators, and stakeholders, see [Subnet Emissions (Alpha)](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out). --- # Subnet Mechanisms Each subnet can run multiple mechanisms (formerly called sub-subnets), allowing one subnet to work on several distinct challenges. _Source: https://beta.taostats.io/docs/concepts/subnets/subnet-mechanisms_ _Last reviewed: 2026-09-15_ Each subnet can run multiple **mechanisms** (formerly called sub-subnets), allowing one subnet to work on several distinct challenges. This page covers how a subnet owner divides the subnet's `alpha_out` across those mechanisms. For how `alpha_out` is then split among subnet owner / miners / validators inside a single mechanism, see [Subnet emission overview](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out). For the broader emission flow, see [Subnet Emission: tao and alpha](https://beta.taostats.io/docs/concepts/subnets/subnet-emissions). ## Mechanisms in a subnet In V1 of subnet mechanisms, all miners and validators in a subnet compete in every mechanism. The owner sets how the subnet's per-block `alpha_out` is split across mechanisms via: ```rust pub fn sudo_set_mechanism_emission_split( origin: OriginFor, netuid: NetUid, maybe_split: Option>, ) -> DispatchResult ``` The `maybe_split` vector defines the percentage of subnet emission that flows to each mechanism. > [!NOTE] > **Split examples** > > * Two mechanisms, even split: `50:50`. > * Two mechanisms, one is new and ramping up: `90:10`. A subnet may host up to 8 mechanisms (2 at launch, rising to a ceiling of 8). ## How mechanism splits feed participant rewards Inside each mechanism, the standard split applies (owner / miners / validators). Rewards for an individual miner or validator are calculated **per mechanism** and then aggregated to the subnet level using the mechanism-split weighting. Concretely: * A miner's `incentive` and a validator's `dividend` are computed inside each mechanism. * Each mechanism contributes to the participant's subnet reward in proportion to its share of the split. * The summed result is what the participant earns from the subnet per tempo. See: * [Subnet emission overview](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out) — the canonical map of how `alpha_out` is split inside a single mechanism. * [Consensus for miners](https://beta.taostats.io/docs/concepts/miners/consensus-for-miners) — how `incentive` is awarded inside a mechanism. * [Dividends for Validators](https://beta.taostats.io/docs/concepts/validators/dividends-for-validators) — how `dividend` is awarded inside a mechanism. --- # Incentive Mechanisms What a subnet's incentive mechanism is, how validators turn miner work into weights and emissions, and what makes a mechanism hard to game. _Source: https://beta.taostats.io/docs/concepts/subnets/incentive-mechanisms_ _Last reviewed: 2026-09-15_ A subnet's **incentive mechanism** is the rule set its validators use to score miners. It is the economic heart of a subnet: it defines what "good work" means, and — through the weights validators set — it decides how the subnet's emissions flow to the miners producing that work. Every subnet on Bittensor designs its own incentive mechanism. There is no single, network-wide scoring rule. A language-model subnet, a compute subnet, and a prediction-market subnet each reward completely different behaviour, so each writes its own mechanism. ## How an incentive mechanism works An incentive mechanism runs as a continuous loop between the miners and validators of a subnet: 1. **Miners produce work.** Each miner responds to the subnet's task — generating text, serving inference, returning a prediction, storing data, or whatever commodity the subnet produces. 2. **Validators evaluate that work.** Validators send challenges to miners and score the responses against the subnet's definition of quality. Scoring logic lives in the subnet's own validator code, not in the chain. 3. **Validators set weights.** Each validator converts its scores into a vector of **weights** — one number per miner — and submits it on-chain. A higher weight means "this miner did more of the work I value." 4. **Consensus turns weights into emissions.** The Yuma consensus mechanism combines every validator's weights, discounts outliers and dishonest weight-setting, and produces the network's agreed ranking. That consensus ranking determines each miner's share of the subnet's emissions. 5. **Emissions are paid, and the loop repeats.** Miners earn alpha emissions in proportion to the consensus weight they hold, giving them a direct incentive to keep producing the work the mechanism rewards. For the mechanics of how weights become emissions, see [Consensus](https://beta.taostats.io/docs/concepts/chain-runtime/consensus) and [Validation](https://beta.taostats.io/docs/concepts/validators/validation). ## What makes a good incentive mechanism A well-designed mechanism has three properties: * **It rewards the behaviour the subnet actually wants.** The score a miner earns should track real value produced, not a proxy that is easy to satisfy without doing the work. * **It is expensive to game and cheap to verify.** Validators should be able to check a response far more cheaply than a miner can fake a good one. When faking is cheaper than working, miners optimise for the fake. * **It resists collusion.** Because emissions follow consensus weights, a mechanism has to survive validators or miners trying to coordinate for unearned rewards. > [!NOTE] > The most common failure mode is **[weight copying](https://beta.taostats.io/docs/concepts/validators/weight-copying)** — a validator that copies another validator's weights instead of doing its own evaluation. It earns dividends without contributing honest scoring, which degrades the signal the whole mechanism depends on. Yuma consensus and mechanisms such as commit–reveal are designed to blunt this. ## Where the mechanism lives The incentive mechanism is **off-chain code** written by the subnet owner and run by that subnet's validators and miners — typically published in the subnet's GitHub repository. The chain does not define the scoring rule; it only records the weights validators submit and runs [consensus](https://beta.taostats.io/docs/concepts/chain-runtime/consensus) over them. This is why two subnets can share the same chain and consensus while rewarding entirely different work. Changing a subnet's incentive mechanism is one of the most consequential things a [subnet owner](https://beta.taostats.io/docs/concepts/subnets/subnet-owner) can do: it changes what every miner is optimising for. ## Related * [Consensus](https://beta.taostats.io/docs/concepts/chain-runtime/consensus) — how weights become emissions (Yuma) * [Validation](https://beta.taostats.io/docs/concepts/validators/validation) — the validator's role in scoring * [Weight copying](https://beta.taostats.io/docs/concepts/validators/weight-copying) — the main gaming vector * [Subnet emissions](https://beta.taostats.io/docs/concepts/subnets/subnet-emissions) — where the rewarded emissions come from * [Subnet owner](https://beta.taostats.io/docs/concepts/subnets/subnet-owner) — who designs the mechanism --- # Validators Validators: Validation (architecture), Running a Validator, Weight copying, Dividends for Validators, Child & parent hotkeys _Source: https://beta.taostats.io/docs/concepts/validators_ _Last reviewed: 2026-09-15_ - [Validation (architecture)](https://beta.taostats.io/docs/concepts/validators/validation) - [Running a Validator](https://beta.taostats.io/docs/concepts/validators/validator) - [Weight copying](https://beta.taostats.io/docs/concepts/validators/weight-copying) - [Dividends for Validators](https://beta.taostats.io/docs/concepts/validators/dividends-for-validators) - [Child & parent hotkeys](https://beta.taostats.io/docs/concepts/validators/child-hotkeys) --- # Validation (architecture) Validators are the neurons in a subnet that validate miner output and provide gateway access to the network _Source: https://beta.taostats.io/docs/concepts/validators/validation_ _Last reviewed: 2026-09-15_ Validators are the neurons in a subnet that validate miner output and provide gateway access to the network > [!NOTE] > **This section focuses on the validator architecture inside a subnet.** > > The [Validator Persona](https://beta.taostats.io/docs/concepts/validators/validator) has details on how a validator can be run. On each subnet there are a configurable number slots reserved for validation (default: 64). In practice, these slots are not all filled by validators, and miners can use these slots as well. Validators have three primary roles. Two exist inside each subnet mechanism, and the third is distribute stakeholder emission. 1. **Validation of miner output**. This is usually done by sending regular requests to each miner and then assigning a value/score to the response. These scores are often added to a moving average of the miners performance which enables a score (weights) to be set at regular intervals on the blockchain for all miners by that validator. These weights form part of the incentive landscape which when combined with the weights of the other validators using [Yuma Consensus](https://beta.taostats.io/docs/concepts/chain-runtime/consensus) are then used to define and distribute emissions. 2. **Gateway access to the network**. The only way a user or application can query a subnet is through the hotkey of an active validator - therefore validators also act as trusted gateways to the miners which in turn allows miners to prioritise queries based on a stake. 3. **Stakeholder Emissions**. Stake is still routed through validators on each subnet. See [Dividends for Validators](https://beta.taostats.io/docs/concepts/validators/dividends-for-validators), [Emissions: Root vs. Alpha Stake](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha) for further details. The amount of tao a validator has as delegated stake defines both the value of the weights they set for miners and as a result allows for a natural market prioritisation of access to form. ## Validation Validators must assess how well the miners are performing and the value they create on the network. Each subnet has a different [Incentive Mechanism](https://beta.taostats.io/docs/concepts/subnets/incentive-mechanisms) for determining how the validator interacts with the miner and scores the responses. The incentive mechanism is not fixed and it is the possibility for design of unique and innovative incentive mechanisms that is one of the key values of Bittensor - allowing each subnet a different approach to validation. ### Parent/Child hotkeys Validators can share stake with other validators by becoming a parent hotkey. This allows the parent to share a percentage of stake (from 0-100%) with the child hotkey. See [Child Hotkeys](https://beta.taostats.io/docs/concepts/validators/child-hotkeys) for more details. ### Weight copying [Weight Copying](https://beta.taostats.io/docs/concepts/validators/weight-copying) occurs when a validator does not perform actual miner validation, but copies the weights of other validators. The Bittensor team has added encrypted weights in an attempt to mitigate this issue. ### Minimum Stake Some subnets have a minimum stake required to be a successful validator. Below this minimum value, weights set by a validator would have near zero effect on the miner's emissions. ### Validator Registration Learn how to [register a node](https://beta.taostats.io/docs/concepts/chain-runtime/node-registration) on a subnet. In addition to the steps in the above link, validators need to have a significant amount of TAO/alpha staked to their hotkey to be successful in validating miners. This is due to market dynamics incentivising miners to naturally prioritise requests from validators with more stake as their weights hold great influence over consensus of trust. Although this varies from subnet to subnet there is a hard floor of 1k tao with a generally accepted competitive functional floor of around 20k tao (at the time of writing). This means that whilst it is possible to validate with less than 20k tao, you may not achieve the same level of responses from all miners and as a result consensus in the weights you set, and as a result your appropriate share of emissions. It should also be noted that in order to validate competitively on root, you must be present on as many subnets as possible. This increases your emissions, and thus the return to the stakeholders. > [!NOTE] > **How can miners ignore validators?** > > If a validator has a very low amount of tao staked, their scoring has very little weight in Consensus. Ignoring a validator allows the miner to focus on the validators that will impact their score (and create the subnet's output). ### Validator Emission Validators are awarded emission from the network based on their dividend score. Dividend is evaluated from the stake and Vtrust values. Vtrust describes how well their weights match the **consensus** of other validators. See [Dividends for Validators](https://beta.taostats.io/docs/concepts/validators/dividends-for-validators) for a detailed analysis. [Roles of a Bittensor Validator](https://www.youtube.com/watch?v=XUgoBN8VB7Q) [Bittensor Subnet access via Validators](https://www.youtube.com/watch?v=j_Qa9inlsng) [Bittensor: What are validator Dividends and how are they calculated](https://www.youtube.com/watch?v=Bd4-eyGa1o0) [Bittensor Delegation: How are your rewards calculated](https://www.youtube.com/watch?v=GzB381fBQQM) [Bittensor subnet owner Hotkey: How to set up and use](https://www.youtube.com/watch?v=wZhgzMKc05I) ## Gateway Access As miners are only scored by validators there is no incentive for them to receive or trust requests from anyone else except a valid validator. Any request to the miners must therefore pass through a validator which will be routed to a miner(s) who will generate the response to the validator, who returns the response to the external user. This allows validators to build API infrastructure or allow their access to be valued by any other network participant providing API access to the network. This is just one way of facilitating access to the network data via a validator and constant advancements a birthing new and innovative ways to interface with the commodities produced by subnets. ![Diagram of a validator acting as a gateway between an external user and a grid of miners, forwarding requests to a selected miner and relaying responses](https://beta.taostats.io/images/docs/concepts/taostats-validator-gateway-access-diagram.png) --- # Running a Validator A validator operates validator nodes on subnets of the Bittensor network. _Source: https://beta.taostats.io/docs/concepts/validators/validator_ _Last reviewed: 2026-09-15_ A validator operates validator nodes on subnets of the Bittensor network. The person (or organisation) behind the validator is afforded gateway access to the intelligence and commodities produced by the subnets on which they operate allowing them the ability to build infrastructure and facilitate external access to the network. Validators are tasked with both measuring and rewarding the value produced by the network from within the code structure of each subnet, but also through external activities unique to each validator which are aimed to win approval and trust of the community which will be rewarded with delegated stake, affording greater network access. A validator's performance in a subnet is measured through their consensus with the other validators, measured by the vtrust metric, attained through the process of scoring and setting weights to the miners. Validators whose scores are in agreement/consensus with the rest of the validators have a higher vtrust and as a result earn more performant rewards. > [!NOTE] > **TL;dr of successful validation** > > 1. The more stake your validator has - the higher the dividends/emission in each subnet. > 1. Many subnets have minimum stake requirements — a hard floor of 1k tao, with a generally accepted competitive functional floor of around 20k tao. > 2. For the highest stakeholder return, you must validate on as many subnets as possible - returns are additive across subnets. > 1. Take & child take can be manipulated in each subnet to maximize returns. ## Subnet Validation Each subnet uses a unique validation and rewards mechanism to define the value of the commodity being produced and assign incentive rewards for this process. Miners complete tasks based on the subnet mechanism requirements and the validators verify, compare and score the responses. The scores are collated, normalised and submitted as weights for consensus, published to the blockchain. The output of the consensus (rewards landscape) is the breakdown of the rewards for the validators, miners, and subnet owners. These results are recorded on the blockchain. To see a validator's results in Taostats, [Taostats Validator pages](https://taostats.io/validators) have a wealth of detail: ![Taostats validator list table with rank, name/address, dominance, nominators, weights, root and alpha stake, take, and a root/alpha split bar, plus search and CSV controls](https://beta.taostats.io/images/docs/concepts/taostats-validator-list-table-concepts.png) Each validator has a page with a table showing subnet-specific data: ![Per-validator subnet table with netuid, hotkey, take, proportion, subnet and family weight/balance split bars, dominance, dividends, and trust columns](https://beta.taostats.io/images/docs/concepts/taostats-validator-subnet-data-table.png) See [Taostats: For Validators](https://beta.taostats.io/docs/understanding-taostats/validators/validators) for more details ## Stake/delegation Validators are incentivised to add value to the Bittensor ecosystem. This value is recognised and rewarded by participants delegating [Stake](https://beta.taostats.io/docs/concepts/staking) to their validator(s) of choice. The more stake a validator has, the greater proportion of network bandwidth is afforded to them through the natural market effect of their weights holding higher value to miners as a result of the prioritisation of stake by Yuma Consensus. (Higher stake also maximises emissions for the validator.) To reward those that stake on a validator, the validator's emissions are divided amongst all delegators. ## Emissions Validators on each subnet receive 41% of all emissions. This is divided amongst the validators based upon their current performance on a given subnet. The dividend metric is the fraction of validator emission for each validator. It is determined from the vtrust metric, proportional to the total stake they hold on any given subnet. Validators with high VTrust and high stake will maximise returns. ### Child Take If the validator has an active neuron, they can set a child take - if another validator places a parent hotkey on the validator's neuron, the child hotkey is awarded a percentage of their award. ### Take As emission is divided to delegators, the validator can take a small percentage of the emissions. This is called the `take`. Today, validators can set this percentage (using the [Command Line Interface (CLI)](https://beta.taostats.io/docs/concepts/command-line-tool)) to be any value from 0-18% (the default value is 18%). See the [Subnet emission overview](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out) for a model of the percentages a validator can earn. The remainder of the emission is distributed to the stakeholders. ### Child Hotkey Validator A validator can use [Child Hotkeys](https://beta.taostats.io/docs/concepts/validators/child-hotkeys) to distribute their stake to other active validators. This means that one can be a "validator" without running any infrastructure on Bittensor subnets. --- # Weight copying Weight copying is a controversial topic in the Bittensor community. _Source: https://beta.taostats.io/docs/concepts/validators/weight-copying_ _Last reviewed: 2026-09-15_ Weight copying is a controversial topic in the Bittensor community. In this article, we look to *explain* weight copying and pros and cons of weight copying. ## What is weight copying? Validators weigh the work of each miner and create a ranked scoring - this is called setting weights. The weights are taken to the Yuma consensus to create the trust score for all of the validators. Vtrust is the scoring of validators - and to score well in Vtrust, your weights must be similar to those of every other validator. **weight copying** is when a validator copies the scores from the Yuma consensus, and uses them to place their weights. This ensures a high Vtrust. ## Why Weight copying? When a validator uses the scoring from the Yuma consensus to place weights - they will score an extremely high Vtrust. High Vtrust leads to a higher percentage of emissions - which leads to higher revenue. * On some subnets, miners will actively ignore requests from validators with low stake. To get a high stake, you need good results. It puts new validators in a chicken/egg situation. By weight copying, the validator is able to show good returns, and gain delegation. ### Reasons to not weight copy Validators that weight copy are not contributing to the Bittensor ecosystem. Validation of the miners is an essential part of the checks and balances of the Bittensor ecosystem. Weight copying does not give back into the ecosystem, and pushes the work onto a smaller group of validators. Subnets are beginning to block access to the data to validators who weight copy - forcing all nodes to be active participants in the network. ## Responses to Weight copying: Commit Reveal In Bittensor 7.3.0, Commit Reveal was launched. Weights submitted to the root network are encrypted for a certain number of blocks. This feature, know as commit reveal can be used to hide the current weights that each validator places on the root subnet. The code was released so that subnet owners could do the same in their subnets: validator weights would be encrypted for a known number of blocks, preventing weight copiers from using fresh data, and making it hard for them to be successful as weight copying validators. The Bittensor team have released a [blog post](https://blog.bittensor.com/weight-copying-in-bittensor-422585ab8fa5) and [technical whitepaper](https://docs.bittensor.com/papers/BT-Consensus-based-Weights.pdf) on their research on commit reveal and its effect of weight copying. --- # Dividends for Validators If a validator is judged to be out of consensus, their VTrust (validator trust) decreases. _Source: https://beta.taostats.io/docs/concepts/validators/dividends-for-validators_ _Last reviewed: 2026-09-15_ > [!NOTE] > **How we got here** > > [Subnet Emission: tao and alpha](https://beta.taostats.io/docs/concepts/subnets/subnet-emissions) > > [Alpha Distribution Mechanisms](https://beta.taostats.io/docs/concepts/subnets/subnet-mechanisms) ## How are emissions calculated for Validators? ### VTrust 1. Validators test miners and create a weighted list of scores. These are submitted to Yuma Consensus. 2. These scores are compared to the other validators — each validator is judged to be *in consensus* with the rest of the validators. If a validator is judged to be out of consensus, their VTrust (validator trust) decreases. VTrust is a value between 0 and 1, where 0 is terrible and 1 is perfect. ### [Stake Weight](https://beta.taostats.io/docs/concepts/staking/stake-weight) The other input to validator emissions is stake weight. Validators with higher stake weight receive higher emissions. * **root_stake**: TAO staked to a validator on root. * **tao_weight**: defined on chain as 0.18. * **alpha_stake**: alpha staked to a validator on the subnet. * **total_stake**: the value used to determine emissions. $$ stake_{total} = stake_{alpha} + stake_{root} \cdot tao_{weight} $$ ### Dividends Dividends are the percentage of total validator emissions awarded to each validator. They are calculated from VTrust and `total_stake`. High stake and high VTrust lead to high dividends, and high dividends yield high emissions. * The sum of all dividends on a subnet is 1. * The dividend score is calculated once per tempo (360 blocks for most subnets). ## Calculating Validator Emission ![Diagram splitting emission by percentage among subnet owner, validators, and miners, with the validator share routed through child/parent hotkey allocations](https://beta.taostats.io/images/docs/concepts/taostats-validator-emission-split-diagram.png) * Validators receive 41% of the `alpha_out` subnet emission. * The validator's dividend score gives the fraction of the validator alpha that is awarded. > [!NOTE] > **Emission math example** > > A subnet receives 1 `alpha_out` per block. > > In 1 epoch: 1 × 360 = 360 alpha. > > Validators receive 41% of the subnet's emissions: 360 × 0.41 = 147.6 alpha. > > Validator X has dividends of 0.006: 147.6 × 0.006 = 0.8856 alpha per epoch. > > If this validator has parent hotkeys, this is divided amongst the validators based on stake (see [Emission for Parent/Child Hotkeys](https://beta.taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys)). > > It is then divided into root emission (converted to TAO) and alpha emission — see [Emissions: Root vs. Alpha Stake](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha). ### Validator rewards The validator's subnet emission is further split by several factors: * Parent hotkeys receive their percentage of the stake. * The validator may take a `child_take` from this emission. * Each subnet has a root:alpha proportion that divides the emissions. * Both alpha and root proportions may have a validator take. * **This is the reward for the validator.** * The remaining root and alpha reward is divided amongst stake nominators. ### Next Steps * [Emission for Parent/Child Hotkeys](https://beta.taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys) — dividing dividends to parent/child hotkeys. * [Emissions: Root vs. Alpha Stake](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha) — dividing between root & alpha proportions. * [Stakeholder Emissions: Root](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root) & [Stakeholder Emissions: Alpha](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-alpha) — distribution of emissions to stakeholders. --- # Child & Parent Hotkeys A child hotkey lets a validator delegate a portion of its stake weight to another hotkey, which validates on its behalf. _Source: https://beta.taostats.io/docs/concepts/validators/child-hotkeys_ _Last reviewed: 2026-09-15_ A **child hotkey** lets a validator delegate a portion of its stake weight to another hotkey, which validates on its behalf. The parent retains ownership of the stake; the child earns a configurable **childkey take** on the emissions it produces. Parent hotkeys launched on the Bittensor chain in September 2024 — a way for a stakeholder to earn TAO from stake without running a validator themselves. > [!NOTE] > For how child hotkeys affect validator returns and emissions, see [Validation](https://beta.taostats.io/docs/concepts/validators/validation) and [Emission and parent hotkeys](https://beta.taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys). ## Key points * **Parent hotkey:** owns the stake and assigns weight to one or more child hotkeys. It adds its stake to an existing validator, increasing that validator's total stake on the subnet. * **Child hotkey:** validates using delegated weight and takes a childkey cut of the resulting emission. * Child/parent relationships are factored into every per-subnet validator return calculation. ## Why use a parent hotkey? * A parent hotkey does not need to run a neuron. * You can begin building a validator while already validating — many subnets have minimum stake requirements, and parenting lets you participate below your own competitive floor. ## Parent hotkeys on Taostats In the subnet metagraph, a yellow stake value indicates parent hotkeys. Clicking the caret opens a view showing all of the parents (and the percentage of their stake) added to the child hotkey. ![Subnet metagraph table row whose yellow stake weight expands into a nested Child/Parent panel listing hotkeys with stake, root stake, and alpha weight](https://beta.taostats.io/images/docs/concepts/taostats-parent-hotkey-metagraph-expand-table.png) For the benefit of being a parent hotkey, Taostats charges a child take of 4.5% — the parent's returns are reduced by 4.5%, which is distributed to Taostats and its stakeholders. ## Can parent hotkeys "beat" existing validator returns? If the parent hotkey chooses child validators with high VTrust, it can achieve competitive returns — but it will never earn higher returns than the validator it is parenting on. ## Related * [Validation](https://beta.taostats.io/docs/concepts/validators/validation) * [Emission and parent hotkeys](https://beta.taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys) * [Dividends for Validators](https://beta.taostats.io/docs/concepts/validators/dividends-for-validators) --- # Miners Miners: I want to mine on Bittensor, Mining (architecture), Running a Miner, Miner Emission _Source: https://beta.taostats.io/docs/concepts/miners_ _Last reviewed: 2026-09-15_ - [I want to mine on Bittensor](https://beta.taostats.io/docs/concepts/miners/i-want-to-mine-on-bittensor) - [Mining (architecture)](https://beta.taostats.io/docs/concepts/miners/mining) - [Running a Miner](https://beta.taostats.io/docs/concepts/miners/miner) - [Miner Emission](https://beta.taostats.io/docs/concepts/miners/consensus-for-miners) --- # I want to mine on Bittensor TL;dr: It's complicated, and you're going to have to do some research. _Source: https://beta.taostats.io/docs/concepts/miners/i-want-to-mine-on-bittensor_ _Last reviewed: 2026-09-15_ TL;dr: It's complicated, and you're going to have to do some research. TL;dr 2:Mining on Bittensor is very competitive. May the odds be ever in your favor. ## Introduction So you want to mine. What is the best way to mine? How do I get started? Can i mine with \? ![Dark-themed chat message explaining that best mining approach depends on subnet and miner/validator performance, not hashrate](https://beta.taostats.io/images/docs/concepts/taostats-mining-advice-chat-message.png) ## The Basics * [Miner (Architecture)](https://beta.taostats.io/docs/concepts/miners/mining): Interaction to mining on Bittensor. * [Emission for Miners](https://beta.taostats.io/docs/concepts/miners/consensus-for-miners) : How you are rewarded with emissions. * [Taostats: For Miners](https://beta.taostats.io/docs/understanding-taostats/miners/taostats-for-miners) How do you visualize how your miner is doing. ## Picking a Subnet There are many subnets on Bittensor, and new ones register while others deregister — for the current count and the full sortable list, see [taostats.io/subnets](https://taostats.io/subnets). Each subnet has a different objective and goal, and so each has different mining/validation requirements. #### Picking a subnet * What are you interested in? If it is model-training, sports or finance predictions, compute, biology, astrophysics.. there may be a subnet that matches your interests. * Each subnet has a Github repository and a channel in the Bittensor Discord. * Your hardware- You may already have HW. Check each SN's hardware requirements. * Emissions: Miners are awarded a proportion of the subnet's emissions > [!NOTE] > **Should I go for a high emission subnet?** > > ## Option 1: Go for the big bucks > > Subnet xx has the highest emission amongst all the subnets. > > Some of the original subnets have very high emission. But they have also been around for 6 months-2 years. Some of the miners on this subnet have had 11 months to modify and improve their miners. Using the default miner is unlikely to beat these highly tuned models. Prepare for a lot of coding, trial & error. > > ## Option 2: Start with a new Subnet > > Subnet XX was registered this week. Its emissions are very small (the top miner is making $1.50/day). But, There are just 9 miners active (and 256 slots). So your miner will not be deregistered, and you can learn how to maximize your returns on the subnet along with everyone else. You may have small returns at the start, but if you believe the subnet can succeed - you may be an insider on the *next* biggest subnet. * Registration cost: Each subnet has different cost to register a neuron. [Taostats: For Miners](https://beta.taostats.io/docs/understanding-taostats/miners/taostats-for-miners) shows how to determine the cost and how it changes over time. * Is there a testnet? If you can run on a testnet - you can forego the registration costs to see if you are able to run the miner. You can also run a local blockchain for testing. ## Skills required * DevOps: You will be running at least one server to be an active miner. * Coding: You will need to optimize your miner to fit the requirements of the subnet. Most of the subnets are written in Python. * Subnet specific skills: Perhaps understanding inference models or Protein folding. --- # Mining What miners do inside a Bittensor subnet, why their requests reach them through validators, and where to find hardware, incentive and registration details. _Source: https://beta.taostats.io/docs/concepts/miners/mining_ _Last reviewed: 2026-09-15_ Miners are nodes in a Bittensor subnet that produce output as defined by the subnet code. > [!NOTE] > **This section focuses on the miner architecture inside a subnet.** > > The [Running a Miner](https://beta.taostats.io/docs/concepts/miners/miner) has details on how a miner can be run. Miners produce output as defined by the subnet code. Each Subnet completes a different type of task, so mining is unique to each subnet. As miners are only scored by validators, there is no incentive for them to receive or trust requests from anyone other than a validator, therefore all requests to the miners pass through a validator. ![Tiered flow diagram showing user requests crossing a boundary to a validator layer, then routed to a selected miner and returned](https://beta.taostats.io/images/docs/concepts/taostats-user-validator-miner-request-flow-diagram.png) ## Hardware requirements Mining hardware requirements vary by subnet although most require some for of GPU to perform the require compute functions. Each subnet's github repository should have a `min_compute.yml` or information in the readme, describing the hardware requirements for mining the subnet. Each Github repository is listed on the Subnet page on taostats.io. ## Miner Trust/Incentive Each miner works to maximise their trust and incentive metrics on the network. This is done by meeting the validation requirements for the subnet at a higher level than their peers. Each validator will grade the results of the miner, assigning a score. Each epoch, the incentive scores (weights) are aggregated by the consensus mechanism to determine the miner's emissions. See [Incentive for Miners](https://beta.taostats.io/docs/concepts/miners/consensus-for-miners) for a detailed breakdown of how miner incentive is calculated. ## Miner Registration Learn how to [register a node](https://beta.taostats.io/docs/concepts/chain-runtime/node-registration) on a subnet. --- # Running a Miner A miner deploys (at least) one mining node into (at least) one subnet to perform the work being rewarded by the subnet incentive mechanism. _Source: https://beta.taostats.io/docs/concepts/miners/miner_ _Last reviewed: 2026-09-15_ A miner deploys (at least) one mining node into (at least) one subnet to perform the work being rewarded by the subnet incentive mechanism. The object of a miner is to score higher than their peers and not fall into the bottom percentile and risk deregistration. The longer a miner remains active, the more profitable they become. Miners may operate multiple nodes on multiple subnets. The taostats [mining dashboard](https://taostats.io/pro/mining) helps you track how well your miners are doing. When mining, miners ensure that their servers are operating - accepting requests from validators and returning responses. Miners can modify their mining server and code to best meet the incentive mechanism for the subnet. Mining is highly competitive - the "best" miners in each subnet accumulate more emissions, and the miners with the lowest scores are de-registered from the network. ## Creating a miner The miner persona runs [Miner servers](https://beta.taostats.io/docs/concepts/miners/mining) in a subnet. To mine, research all of the subnets (see the [Bittensor Subnets](https://beta.taostats.io/docs/concepts/subnets/list-of-subnets) list), and decide which subnet you wish to mine. Each subnet has different hardware and software requirements. Some subnets have a testnet to test your miner before registering and mining in the subnet. You'll need to [register a node](https://beta.taostats.io/docs/concepts/chain-runtime/node-registration) with a Bittensor hotkey. Then you'll start your miner code on your server with the same hotkey to verify your server on the network. ## Ranking Each miner participates in a subnet. It solves the challenge specific to that subnet, and the miner's responses are evaluated by validators based on the subnet's criteria. The validators then weigh (or rank) the responses of all miners and rank them via weights. The weights are posted to [Yuma Consensus](https://beta.taostats.io/docs/concepts/chain-runtime/consensus) to create an incentive score - and the higher the incentive, the higher the reward. If a miner's server falls into the bottom of the miner trust rankings for a subnet, it risks being de-registered. Reward for miners is scored as incentive that is converted to emission.. ## Rewards Miners receive alpha as an award for the work produced. The reward is based on their ranking as scored by the specific subnet's incentive mechanism. The emission scores for all miners sum to 1. This is then used to allocate the emissions awarded to the miners. The [Tokenomics](https://beta.taostats.io/docs/concepts/tokenomics/tokenomics) section describes how tao is distributed in the Bittensor ecosystem. * Some subnets have "winner-takes-all" awarding (or a few winners-take-all). * Incentive awarded to the Subnet owner is burned. ### Where do your awards go? Miner alpha rewards will automatically stake to the hotkey. If you would like your mining rewards to be automatically staked to a validator, this can be set via `Autostake` #### Autostake your rewards With autostake, all incentive from all hotkeys are automatically staked to one hotkey. Generally, a miner would choose a validator to earn staking rewards. This does complicate the separation of mining rewards with staking rewards. There is a Taostats API for the transfer of mining rewards: ## Helpful links * [Taostats: For Miners](https://beta.taostats.io/docs/understanding-taostats/miners/taostats-for-miners) --- # Miner Emission How is emission calculated for Miners? _Source: https://beta.taostats.io/docs/concepts/miners/consensus-for-miners_ _Last reviewed: 2026-09-15_ > [!NOTE] > **How we got here** > > [Subnet Emission tao and alpha](https://beta.taostats.io/docs/concepts/subnets/subnet-emissions) > > [Distribution of alpha\_out to participants](https://beta.taostats.io/docs/concepts/subnets/subnet-mechanisms) How is emission calculated for Miners? Emission is derived from the `incentive` calculated by Yuma Consensus. 1. Validators test miners, and create a ranked list of each miner (weights). These weights are regularly delivered to the consensus engine. 1. These are stored in a 2D matrix - each row is the UID of the validator placing weights, and each column is the UID of the miner. (A visual representation of the weights can be found for each subnet on taostats: [Subnet 19 Miner weights](https://taostats.io/subnets/19/miners) . 2. These weights are used to calculate `incentive` and consensus - how well do the validators agree on scoring? 3. The `incentive` score is made by a weighted average of validator weights. Weights placed by validators with higher amounts of delegation of tao are given higher weight in the incentive score. Validators that are out of consensus (a high deviation from the weighted score) may have their weight reduced further. ## Incentive The `incentive` score for a subnet scores how well miners are performing in relation to other miners. The sum of incentive scores in a subnet is 1. * Each miner's `incentive` score is reported in the metagraph of the subnet. * The `incentive` score is updated once per tempo of the subnet (360 blocks) > [!NOTE] > Burning Incentive > > Incentive that is awarded to the Subnet owner hotkey (shown with a crown on taostats) is burned. See [Burning](https://beta.taostats.io/docs/concepts/tokenomics/burning) ## Emission ![Flow diagram splitting subnet emission by percentage among subnet owner, validators, and miners, with the miner branch highlighted and fanning out to individual miners](https://beta.taostats.io/images/docs/concepts/taostats-emission-owner-validator-miner-split-diagram.png) The miner emission score is how much alpha is awarded to the miner each epoch. (An epoch is 360 blocks.) > [!NOTE] > **Emission math example** > > A subnet receives 1 `alpha_out` per block. > > In 1 epoch - 1\*360 = 360 alpha. > > Miners receive 41% of the subnet' emissions. 360\*.41 = 147.6 alpha > > Miner 19 has incentive of 0.006. 147.6\*0.006 = .8856 alpha per epoch. > > *Miner 19 has 0.8856 alpha emission*. Emission is calculated and awarded every epoch. This can mean that emission is delivered to your hotkey after your miner is deregistered. ## Daily Rewards On taostats, the daily rewards is calculated by multiplying emission \*20 (There are \~20 epochs in 24 hours.) ## Math We can extract the weights, consensus, and incentive scores from the network, and look at how they interact. Let's grab the data for Subnet 18, miner 191. ```python import bittensor as bt #who we are interested in subnet_number = 18 miner_uid = 191 #validator parameters: #we need to find the rows for where validators have placed weights. #find the rows by looking in the stake vector for rows with large delegation min_stake = 22000 validators = [] total_stake = 0 counter =0 #load the data from the network subnet = bt.metagraph( netuid = subnet_number, lite = False) subnet_weights = subnet.W subnet_stake = subnet.S subnet_consensus = subnet.C subnet_incentive = subnet.I #loop through all of the UIDs. #if there is a large amount of stake - we have a validator #grab the weight placed for the miner_uid for neuron in subnet_stake: stake = neuron.item() if stake > min_stake: weight = subnet_weights[counter][miner_uid] print(f"validator {counter}: Weight {weight}") counter += 1 #now grab consensus and incentive print(f"consensus: {subnet_consensus[miner_uid]}") print(f"incentive: {subnet_incentive[miner_uid]}") ``` ``` validator 21: Weight 0.0022598521318286657 validator 63: Weight 0.0014278064481914043 validator 77: Weight 0.002753422362729907 validator 104: Weight 0.00243220292031765 validator 120: Weight 0.0 validator 132: Weight 0.001061580260284245 validator 133: Weight 0.003077547997236252 validator 139: Weight 0.003447300987318158 validator 145: Weight 0.0017241350142285228 validator 160: Weight 0.0019509864505380392 validator 171: Weight 0.0030758935026824474 validator 175: Weight 0.0037663523107767105 validator 180: Weight 0.001641291193664074 validator 181: Weight 0.0024577134754508734 validator 187: Weight 0.0022174983751028776 validator 188: Weight 0.0017739878967404366 validator 190: Weight 0.0033894709777086973 validator 194: Weight 0.004710848908871412 validator 230: Weight 0.0024577134754508734 validator 232: Weight 0.0021844268776476383 validator 236: Weight 0.0030592582188546658 validator 246: Weight 0.0021754945628345013 consensus: 0.0021820401307195425 incentive: 0.002151522086933255 ``` The code calls the Chain and asks for all of the validator weights. The output is a formatted list with the weight from each validator. In the response, we can see on line 5 that validator 120 placed no weight. This score will be removed by the consensus engine, and the VTrust for the validator will be reduced. > [!NOTE] > **VTrust for validator 120** > > The code below queries the chain for the VTrust for validators 120, 232 and 236. The number is reported in a Tensor: > > 120: 44.5% > 232: 93.9% > 236: 89.6% > > ``` > print(subnet.Tv[120]) > print(subnet.Tv[232]) > print(subnet.Tv[236]) > > tensor(0.4450) > tensor(0.9391) > tensor(0.8962) > ``` > > At 44.5% Vtrust, validator 120 will begin to see lower emissions. The overall consensus is 0.00218, and looking at the weights placed by each validator - we can see that most of the validators are close to that score. The overall incentive is right around the consensus (slightly lower) at 0.00215 ### Charting Weights and Consensus The code below draws a red dotted line indicating the consensus weight. Each validator's weight is shown by a blue dot. ```python import matplotlib.pyplot as plt # Unpack the points into two lists: xs and ys xs, ys = zip(*weights) # Create a scatter plot plt.scatter(xs, ys) # Add a horizontal line at y = consenus plt.axhline(y=subnet_consensus[miner_uid], color='r', linestyle='--') # Set the labels for the axes plt.xlabel('Validator UID') plt.ylabel('Weight') # Set the title of the plot plt.title(F'weights and consensus for miner {miner_uid} in subnet {subnet_number}') # Show the plot plt.show() ``` ![Scatter plot of validator weight assigned to a miner versus validator UID, with a horizontal dashed consensus reference line](https://beta.taostats.io/images/docs/concepts/taostats-miner-weight-consensus-scatter.png) Validator 103 is the point at the top of the graph, and out of consensus with the others - all much closer to the consensus line. The weight posted by Validator 103 will not be included (or its weight drastically reduced) as it is out of consensus. --- # Staking An overview of staking TAO on Bittensor under dTao — root versus subnet stake — with links to price impact, root baskets, stake weight and yield. _Source: https://beta.taostats.io/docs/concepts/staking_ _Last reviewed: 2026-09-23_ Staking is how TAO holders earn yield on Bittensor. Under **dTao** you can stake to **root** (TAO only, no price risk on your stake) or to a **subnet** (buying that subnet's alpha token, higher risk and reward). Start with [Staking in dTao](https://beta.taostats.io/docs/concepts/staking/staking-in-dtao) for the full model, then dig into price impact, root baskets, and yield. - [Staking in dTao](https://beta.taostats.io/docs/concepts/staking/staking-in-dtao) - [Root Validator Baskets](https://beta.taostats.io/docs/concepts/staking/root-validator-baskets) - [Taostats for Staking](https://beta.taostats.io/docs/concepts/staking/taostats-for-staking) - [Price Impact and Slippage](https://beta.taostats.io/docs/concepts/staking/slippage) - [Stake weight](https://beta.taostats.io/docs/concepts/staking/stake-weight) - [Yield](https://beta.taostats.io/docs/concepts/staking/yield) --- # Staking in dTao Staking tao/alpha is how investors earn yield. _Source: https://beta.taostats.io/docs/concepts/staking/staking-in-dtao_ _Last reviewed: 2026-09-23_ Staking tao/alpha is how investors earn yield. > [!NOTE] > Staking with taostats > > See [Staking Instructions](https://beta.taostats.io/docs/understanding-taostats/accounts/staking-instructions) for a number of pages describing how to stake using Taostats. Staking plays a principal role in the functioning of the Bittensor network. In February 2025, the dTao release gave stakeholders additional power: staking into a subnet increases the emissions of the subnet. ## Staking Options in dTao, there are two options for staking: * [Staking to root](#staking-to-root) * [Staking to a Subnet](#staking-to-alpha) ## Staking to root Staking to root uses only tao. Your tao is staked on a root validator, and you receive returns based on the validator's performance in the subnets. Staking to root is a `safe` staking option — your staked tao cannot lose value, though rewards you haven't claimed yet are held as subnet alpha and move with subnet prices. However, root staking decreases over time [by design](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha), as the root proportion decreases on all subnets. ### Root rewards under Root Reborn Root dividends are handled by **[Root Reborn](https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/explainer)**, live on mainnet (subtensor `spec_version` 441). It replaced the earlier auto-compounding and "keep vs. swap" claim options — there is **no auto-claim**. Instead, each root validator runs a **basket**: your root dividends are no longer sold — they stay as the subnet alpha they were earned in and are held in the validator's basket as compounding subnet-alpha exposure until you redeem. The validator can reshape the basket by trading, within guardrails. You pick a validator on its basket, not just its take rate. Your balance no longer rises on its own. To realise rewards you make a single manual **`claim_root`** call (prefer **`claim_root_with_hotkey`** for one validator), which values your basket shares at current NAV and swaps them **to TAO** (there is no "keep as subnet alpha" redemption). Claiming costs a fee billed at a fixed runtime fee allowance (~τ0.0082; light claims can refund lower) — prefer a concentrated basket and claim infrequently — and switching or unstaking doesn't forfeit what you're already owed; it stays claimable on that validator's basket. For the full mechanics — the basket, how shares accrue, fees, and per-participant impact — see **[Root Validator Baskets](https://beta.taostats.io/docs/concepts/staking/root-validator-baskets)** (the short canonical reference) and the [Root Reborn explainer](https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/explainer) and [TL;DR](https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/tldr). Root dividends accrue to your basket continuously — each time a subnet your validator earns on runs its epoch — but they only reach your balance when you make the manual claim. ## Staking to alpha This is the new feature and primary goal of dTao - to enable stakeholders to vote and determine the emissions for every subnet. To stake in alpha, tao is exchanged via the [Subnet Pools](https://beta.taostats.io/docs/concepts/subnets/subnet-pools) into alpha. This will incur [Slippage](https://beta.taostats.io/docs/concepts/staking/slippage). The received alpha is then staked to the validator selected. Your returns will be in alpha, and autocompounded to the validator hotkey. Because alpha staking trades through a subnet pool, it can be front-run by MEV bots that worsen your slippage. Taostats protects alpha stake/unstake transactions with [MEV Shield](https://beta.taostats.io/docs/concepts/chain-runtime/mev-shield), which encrypts the transaction so bots cannot read or front-run it. Staking to alpha *does* incur risk: a drop in alpha token price will result in a lower amount of tao when unstaking. Emission is awarded every 360 blocks (approx 72 minutes). > [!NOTE] > **No unbonding period** > > Unstaking is immediate — there is no lock-up or unbonding delay. As soon as an unstake settles, the resulting tao is in your free balance and spendable right away. (The exception is [conviction locks](https://beta.taostats.io/docs/concepts/chain-runtime/conviction-v2): alpha locked in conviction **cannot be unstaked** while the lock is active — your total staked alpha on the subnet must stay at or above the locked amount. Only alpha held *above* the locked amount is unstakable.) ### Staking fees For all staking transactions there is a small extrinsic (transaction) fee charged by the chain. Taostats currently does not allow staking every last tao — it leaves a small amount behind to cover the fee for the eventual unstake transaction. #### Root There is no **additional** staking fee to stake or unstake from root — only the standard chain extrinsic fee applies. #### Subnets * Staking and unstaking through a subnet pool carries a fee that defaults to **0.05%** of the stake/unstake value. * This can be changed by the subnet owner, so read the current value before you stake. #### Get the current fee (and price) for a subnet The live pool endpoint [`GET /api/dtao/pool/latest/v1`](https://beta.taostats.io/docs/api-reference/subnet/get-pool-latest) returns the subnet's current **`fee_rate`** (staking/unstaking fee) along with its **`price`** in TAO. Pass the `netuid` for the subnet you want. ### Moving stake The move stake command can be used to switch validators in a subnet. Under the hood, this is an unstake, and then staking. However, only one fee is charged. There are three distinct operations for relocating an existing position — they are easy to confuse: * **Move** (`move_stake`) — re-delegate a position to a different hotkey and/or a different subnet. You keep ownership. Moving across subnets swaps through both pools and incurs slippage on each leg. * **Swap** (`swap_stake`) — move a position to a *different subnet* on the *same* hotkey. Both legs (sell on the origin pool, buy on the destination pool) can incur slippage, and the two subnets must differ. * **Transfer** (`transfer_stake`) — hand the position to **another coldkey**. After this, that coldkey controls and can unstake the funds — not you. This is a transfer of value and is **irreversible**; double-check the destination address. ### Unstaking everything at once The "unstake all" operations sweep your entire stake on a hotkey in one call, but they behave differently from a normal unstake and have two things worth knowing: * **No slippage protection.** Each pool swap executes at the current price with no limit, so large positions can incur significant slippage. * **Silent skips.** Subnets where subtoken trading is disabled, or where a position is dust below the chain minimum, are silently skipped — the call can *succeed* while leaving some stake untouched. `unstake_all` returns everything to your free tao balance; `unstake_all_alpha` sells your alpha positions and restakes the proceeds as tao on root (netuid 0), keeping the funds staked. ### Root or subnet — which should I stake to? * **Root** uses only TAO and your staked TAO carries no price risk (unclaimed rewards are held as subnet alpha), but its returns decline over time [by design](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha) as subnets take a growing share of emissions. Rewards are realized on a manual `claim_root` (see [Root Validator Baskets](https://beta.taostats.io/docs/concepts/staking/root-validator-baskets)). * **Alpha** (subnet) staking buys a subnet's token, which can appreciate or depreciate against TAO — higher potential return, higher risk, and it incurs [price impact](https://beta.taostats.io/docs/concepts/staking/slippage). --- # Taostats for Staking Understand how to read the data in order to stake your tao _Source: https://beta.taostats.io/docs/concepts/staking/taostats-for-staking_ _Last reviewed: 2026-09-15_ Understand how to read the data in order to stake your tao Staking is a great option if you want to support the Bittensor network with tao, but do not want to run a subnet or neuron. > [!NOTE] > [**Staking Instructions**](https://beta.taostats.io/docs/understanding-taostats/accounts/staking-instructions) — Use taostats for all your staking transactions! ## Staking Staking is the process of delegating your tao to a validator. ### Root stake Validators with high VTrust across as many subnets as possible will have the highest root returns. You can also choose to support validators who work towards building the Bittensor ecosystem (with higher emissions, validators earn more tao, so by supporting validators who work on the ecosystem, you support their work.) ### Alpha Stake Staking in a subnet involves buying an alpha token. See [Staking in dTao](https://beta.taostats.io/docs/concepts/staking/staking-in-dtao) for full details. Your alpha quantity grows over time through autocompounding, but the exchange rate between tao/alpha can change — so the tao value of your stake can still fall, leading to a net loss of funds. Because alpha staking trades through a subnet pool, it can be targeted by MEV bots. Alpha stake/unstake transactions on Taostats are protected by [MEV Shield](https://beta.taostats.io/docs/concepts/chain-runtime/mev-shield) — and Taostats **signs the encryption wrapper for you**, so there is no second signature to enter. ### Staking hold period There is no hold period for staking. ### Staking Risk * **Root**: Staking on root Bittensor is the lower-risk option. Your tao is delegated to a validator's hotkey — the validator can set weights with it but cannot withdraw or transfer it, and you can unstake at any time. Returns still depend on the validator's performance and on root's declining share of total emissions. * **Alpha**: When buying alpha, you are purchasing a new token. Your alpha quantity grows through autocompounding, but the price of alpha/tao will fluctuate — so the tao value of your position can fall. This can lead to a loss in funds. ### Choosing a validator Learn about the validators, and how they are contributing to the Bittensor network. By staking with a validator, you are supporting this work. The table shows the amount of tao that is delegated to them, and the % of network delegated tao: ![Taostats validator as of Feb. 5 2024.](https://beta.taostats.io/images/docs/concepts/e48533f5-Screenshot_2024-09-06_at_14.53.04.jpg) The info button takes you to the [validator explorer](https://beta.taostats.io/docs/concepts/validators/validator#explorer) page, providing details about the validator's performance. ### Return on your stake When you stake your TAO on a validator, you'll want an idea of the amount of emissions you will receive. Taostats has a *very basic* calculator that uses the average emissions across the entire bittensor network: [https://taostats.io/staking/](https://taostats.io/staking/). [Bittensor Delegation: How are your rewards calculated](https://www.youtube.com/watch?v=GzB381fBQQM) ## APY [https://taostats.io/yield](https://taostats.io/yield) displays the APY for all subnets including root ![Dark-themed validator yield table with subnet selector, simulation input, and validator, stake, and 1H/1D/1W/1M APY columns as colored pills](https://beta.taostats.io/images/docs/concepts/taostats-validator-apy-yield-table.png) This page is calculated based on **actual returns** over the period. As always *past performance does not indicate future gains*. Root APY will be in decline as subnets mature, due to [Emissions: Root vs. Alpha Stake](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha). --- # Root Validator Baskets Root Validator Baskets are the mechanism Root Reborn introduced for handling root dividends. _Source: https://beta.taostats.io/docs/concepts/staking/root-validator-baskets_ _Last reviewed: 2026-09-23_ Root Validator Baskets are the mechanism [Root Reborn](https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/explainer) introduced for handling root dividends. Root dividends no longer cash out to TAO: they are held in your root validator's **basket** of subnet alpha, which you redeem to TAO on demand. For the full treatment see the [Root Reborn explainer](https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/explainer) and its [TL;DR](https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/tldr). This page is the short canonical reference. ## How the basket works Each root validator has a single basket, staked under a global escrow coldkey with the validator as hotkey. Your root stake with that validator gives you a **share** of the basket, valued at the basket's net asset value (NAV). * **Dividends land where they were earned.** A root dividend earned on subnet N is held as subnet-N alpha in the basket — the protocol executes no trades on it, so no swap fees and no slippage. Direct deposits (`stake_into_basket`) are split across the basket's current holdings by value and buy each one; the depositor pays that entry's swap fees and slippage. * **Only trades move composition.** The validator reshapes the basket by trading (below). Otherwise the protocol only converts holdings to the basket's TAO slot: dust rows during a claim, and every holding on a deregistered subnet. * **Your deposit mints shares at the pre-deposit NAV**, so existing holders are never diluted by an inflow. The basket compounds through alpha emissions on its positions and price movement on the alpha held. It creates and destroys no TAO — it is `TotalStake`-neutral. ## Basket trading: swap_basket A root validator rebalances its basket with a single call, signed by its coldkey (or a `BasketTrading` proxy): ``` swap_basket(hotkey, origin_netuid, destination_netuid, amount, min_amount_out) ``` Sell `amount` of the basket's `origin_netuid` holding for TAO and buy `destination_netuid` with it. Either side may be root (netuid 0) — the basket's TAO slot. The TAO slot counts as a holding for the concentration cap, so trading can't lift it above 1/16 of the basket. Shares and staker entitlements are unchanged; only the basket's composition moves. Every trade emits a `BasketSwapped` event, so a validator's trades — and the fees and slippage they incurred — are public on chain. ### Guardrails Every `swap_basket` must pass all of these, or it rolls back: | Guardrail | Rule | Error | |---|---|---| | Network gate | `BasketTradingEnabled` must be on network-wide | `BasketTradingDisabled` | | Per-validator freeze | Governance can freeze one hotkey's trading | `BasketTradingFrozen` | | Price band | Each AMM leg must fill fully within **2%** of the strictest of the subnet's moving price, its fast (~2-hour) moving price and its spot price | `SlippageTooHigh` | | Caller floor | The buy leg must credit at least `min_amount_out` (`0` = no floor; the 2% band still applies) | `BasketMinOutNotMet` | | Turnover budget | TAO through the middle is drawn from a bucket of **10% of basket NAV** (`BasketDailyTurnoverCap`) that refills over **7200 blocks** (~1 day) | `BasketTurnoverBudgetExceeded` | | Liquidity cap | The destination holding may not exceed **10%** of the destination pool's alpha reserve (`BasketLiquidityCap`); alpha bought into one destination within 7200 blocks is capped at the same 10% (selling doesn't restore it) | `BasketLiquidityCapExceeded` | | Concentration cap | The destination holding may not exceed **1/16 of basket NAV** (`BasketConcentrationCap`), so a traded basket spreads across at least 16 holdings. Not enforced while the chain has fewer subnets than that | `BasketConcentrationCapExceeded` | | Same subnet | Origin must differ from destination | `BasketSameSubnet` | | Ownership | Caller must own `hotkey`; `hotkey` must be registered on root and hold at least `amount` on origin | `NonAssociatedColdKey`, `HotKeyNotRegisteredInSubNet`, `NotEnoughStakeToWithdraw` | The three caps are governance-set hyperparameters (u16-normalised; defaults 6553/65535 ≈ 10%, 6553/65535 ≈ 10%, 4096/65535 = 1/16). The `basket_trading_status` runtime view exposes the network gate, per-hotkey freeze, and remaining turnover budget. ## Redeeming: claim_root Your balance does not rise on its own. To realise rewards you make a manual claim: * **`claim_root_with_hotkey(hotkey)`** — redeem one validator's basket (preferred). * **`claim_root(subnets)`** — coldkey-wide sweep of every root-relevant validator. The `subnets` argument is ignored (kept for old-client SCALE compatibility). Your share is valued at the basket's current NAV and redeemed **pro-rata across all holdings**, swapped to TAO, and staked back onto root on that validator. Redemption is **always to TAO**. If you want subnet alpha on your coldkey, claim to root, unstake, then stake into the subnet yourself. Claims whose estimated payout is below the network **claim threshold** (default τ0.0005) are skipped and keep accruing. Dust holdings below that threshold are consolidated into the basket's root (TAO) slot as a side effect, so later claims get cheaper as rows disappear. Since spec 468 a claim also leaves small rows unsold: a subnet holding worth less than min(τ1, 0.1% of the basket's NAV), or one where your own slice is worth less than τ0.0001, is skipped as long as your slice is at most τ0.01. Your whole share is still redeemed, so the skipped slices stay in the basket for the other holders (`BasketClaimDustSkipped` reports them). The TAO slot is never skipped. ## Costs and considerations * **Claiming costs a fee**, but billing is capped. Admission still uses a large declared work envelope (so heavy claims fit in a block), yet `paymentInfo` and the fee you pay are discounted to a fixed **fee allowance of 4 claim units** (`ROOT_CLAIM_FEE_ALLOWANCE` in the runtime) — about **τ0.0082** after the spec 467 fee-rate halving. Light claims can refund below that; heavy claims are capped at it. Prefer a concentrated basket and claim infrequently. * **Reservation vs spent.** The chain quotes the fee allowance at inclusion (`paymentInfo`); light work can refund unused weight after: | Call | Admission envelope (block capacity) | Fee billed (`paymentInfo`) | |---|---|---| | Single-validator (`claim_root_with_hotkey`) | 129 units + scan(129) + flush bound | ~0.0082 TAO (4-unit allowance) | | Coldkey-wide (`claim_root`) | 256 units + scan(256) + flush bound | ~0.0082 TAO (same allowance) | You must have enough free TAO to cover the reserved amount to submit. Typical spent fees stay near the allowance for any non-trivial basket; tiny single-holding claims can land lower (~τ0.0015). * **Switching validators.** New dividends follow your root stake, but what you're already owed doesn't: moving or unstaking credits pending dividends first, and your owed share stays in the old basket (still moving with its value) until you claim it with `claim_root_with_hotkey` or `claim_root`. * **Your return depends on subnet performance.** Between claims you hold subnet-alpha exposure — it can outperform or underperform TAO. Stakers who want pure TAO exposure should claim more frequently — trading can't take a basket's TAO slot above 1/16 of its NAV. * **Pick validators on their basket.** `BasketSwapped` events, NAV history, and composition are all public — judge a validator on what it holds and how it trades, not just its take rate. ## Data on Taostats The `BetaBasketRuntimeApi` exposes per-staker owed TAO, per-validator NAV and basket composition, network-wide root NAV, and `basket_trading_status`. These power basket performance, composition, and pending-claim metrics on Taostats. ## Related * [Root Reborn — full explainer](https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/explainer) * [Root Reborn — TL;DR](https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/tldr) * [Stakeholder Emissions: Root](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root) * [Dividends for Validators](https://beta.taostats.io/docs/concepts/validators/dividends-for-validators) * [Staking in dTao](https://beta.taostats.io/docs/concepts/staking/staking-in-dtao) --- > [!NOTE] > **Previously.** Root Reborn shipped in runtime v441 with root dividends accumulating in place as subnet alpha on the subnet they were earned on. v450 turned on `set_root_weights`, a per-validator weight vector (8-destination floor, 1/16 concentration cap, one set per 100 blocks) that a validator's dividends were sold and re-bought into; validators without one kept accumulating in place. Runtime v461 removed the vector and its `RootWeightSettingEnabled` gate — inflows now accumulate in place and validators reshape the basket only by trading. Stored vectors were cleared at the upgrade; baskets kept every holding. The 1/16 rule survives as `BasketConcentrationCap` on `swap_basket` buys. Basket trading (`swap_basket`) was switched on network-wide at spec 468. Before Root Reborn, root dividends were auto-sold to TAO and compounded onto root stake, with keep/swap claim options — none of that remains. --- # Stake weight How to determine Validator stake weight. _Source: https://beta.taostats.io/docs/concepts/staking/stake-weight_ _Last reviewed: 2026-09-15_ How to determine Validator stake weight. With the launch of dTao, stakeholder may place stake on root or on a subnet. In order to determine how much stake a validator has on a subnet, these values are combined. Root stake is weighted at a lower value that the alpha stake. The weighting parameter `tao_weight` is defined on-chain (currently 0.18) root\_stake: The amount of tao staked to a validator on root.\ tao\_weight : Defined on chain as 0.18. alpha\_stake: The amount of alpha staked to a validator on the subnet stake\_weight: The value used to determine emissions. $$ stake_{total} = stake_{alpha} + stake_{root} \cdot tao_{weight} $$ > [!NOTE] > **Example** > > ![Dark-themed table row with Child, Stake Weight, Root Prop, and Alpha Prop columns denominated in tao and alpha](https://beta.taostats.io/images/docs/concepts/taostats-stake-weight-child-row-table.png) > > $$ > 53{,}162 + 390{,}232 \cdot 0.18 = 123{,}404 > $$ --- # Price Impact and Slippage Why a stake or unstake returns less than the quoted price implies: price impact from pool size, slippage from other trades, the formulas, and slippage limits. _Source: https://beta.taostats.io/docs/concepts/staking/slippage_ _Last reviewed: 2026-09-15_ **Slippage** is the difference between the amount of tao or alpha you *expected* from a trade and the amount you *actually* received. When you stake or unstake through a subnet (liquidity) pool, you almost never get the exact quantity implied by the quoted price — the shortfall is slippage, usually shown as a percentage. Slippage (the umbrella term) has two components: - **Price impact** — the inherent, predictable part. It comes down to **how big your transaction is** relative to **how much liquidity is in the pool**. A large trade against a small pool moves the price a lot; a small trade against a deep pool barely moves it. Price impact happens even if you are the only person trading. - **Slippage (price action)** — the part caused by *other* trades. Between the moment your transaction is submitted and the moment it lands, someone else can stake or unstake in the same pool and move the price, so you receive more or less than you expected. This is often just **another random stake or unstake** happening near yours — it is not necessarily anyone acting against you. In the worst case it *can* be deliberate **front-running** (an [MEV bot](https://beta.taostats.io/docs/concepts/chain-runtime/mev-shield) trading ahead of your transaction on purpose), which Taostats defends against with [MEV Shield](https://beta.taostats.io/docs/concepts/chain-runtime/mev-shield) (see below). > [!NOTE] > **The larger the purchase amount, the higher the price impact** > > ### The smaller the liquidity pool, the higher the price impact. ## What is Price Impact? Due to the limited resources of the liquidity pool, any change in the ratio of tao/alpha will affect the price and exchange rate. The act of making a purchase through the subnet pool changes the ratio, and affects the rate at which the exchange is placed. > [!NOTE] > **Price Impact occurs when staking AND unstaking alpha.** ## Slippage from price action Price impact is predictable from the pool size and your trade size. The **price action** component is not: between submitting your transaction and it landing, other trades in the same pool move the price, so you end up with more or less than you expected. Most of the time this is simply **another random stake or unstake** that happened to land near yours — no one is targeting you. It *can*, however, be deliberate: an [MEV bot](https://beta.taostats.io/docs/concepts/chain-runtime/mev-shield) that sees your pending transaction and **front-runs** it on purpose to profit from the price move. Because subnet-pool trades are exposed to this, Taostats routes your alpha stake/unstake through **[MEV Shield](https://beta.taostats.io/docs/concepts/chain-runtime/mev-shield)**, which encrypts the transaction so bots cannot read it and front-run you. ## Putting it together Your total slippage is price impact plus price action. For example, a transaction may have 0.5% price impact on its own, but another trade lands ahead of it and moves the price, adding a further 0.25% — for 0.75% total slippage versus the amount you expected. ## Price Impact & Slippage formulas The tao/alpha conversion price cannot be used to calculate a transaction. You must use the following equation to determine the `α_received`: $$ \alpha_{received} = \alpha_{pool} - \dfrac{k}{tao_{pool} + tao_{staked}} $$ The opposite occurs when unstaking alpha to buy tao: $$ tao_{received} = tao_{pool} - \dfrac{k}{\alpha_{pool} + \alpha_{unstaked}} $$ The amount received will be less than the amount expected from the direct price conversion. That total difference is the slippage (generally shown as a percentage): $$ Slippage = \dfrac{\alpha_{expected} - \alpha_{actual}}{\alpha_{expected}} $$ ## Price Impact Calculator _Interactive on the web page: a price impact calculator (pool TAO, pool alpha, amount and direction → amount received and price impact) that evaluates the formulas above._ > [!NOTE] > **Example 1 (large purchase = large price impact):** > > A subnet pool has 100α and 100τ. alpha:tao is 1:1, so the alpha price is 1 tao. > > ![Subnet liquidity pool holding 100 τ and 100 α at a 1:1 ratio](https://beta.taostats.io/images/docs/concepts/slippage-pool-100-tao-100-alpha.png) > > A tao holder wishes to sell 1,000 tao for alpha. Following the exchange rate of 1:1, you might assume 1,000α would be received. But there is just 100α in the pool, so using the equation above 90.9α is received. > > This results in a price impact of 90.91%: > > $$ > \dfrac{1000 - 90.9}{1000} \times 100 = 90.91\% > $$ > > Large purchases of tao or alpha will have large amounts of price impact. > [!NOTE] > **Example 2 smaller purchase** > > A subnet pool has 100α and 100τ. alpha:tao is 1:1, so the alpha price is 1 tao. > > ![Subnet liquidity pool holding 100 τ and 100 α at a 1:1 ratio](https://beta.taostats.io/images/docs/concepts/slippage-pool-100-tao-100-alpha.png) > > A tao holder wishes to sell 10 tao for alpha. Using the equation for alpha\_expected, they will receive 9.09α. > > This results in 9.1% price impact. > > $$ > \dfrac{10 - 9.09}{10} \times 100 = 9.1\% > $$ ## Price impact and Slippage values The transaction tables list the actual slippage of a transaction. A negative slippage means your transaction actually profited from the trade ![Transaction table showing per-trade Slippage % and Fee (τ) columns](https://beta.taostats.io/images/docs/concepts/transaction-table-slippage-fee-columns.png) ## Setting a slippage limit You can cap how far the price is allowed to move before your stake or unstake is cancelled. Bittensor provides **limit-price** variants of the staking extrinsics — `add_stake_limit` and `remove_stake_limit` — which take a limit price and **revert with `SlippageTooHigh`** rather than filling if the pool price moves past your tolerance. > [!NOTE] > **Whether a limit is applied depends on the tool** > > A slippage limit is **not** enforced by the chain automatically. The plain `add_stake` / `remove_stake` extrinsics execute at whatever price the pool is at when the transaction lands — no protection. It is the **tool** that decides whether to route through the limit variant: > > * **Taostats** applies a slippage limit to your stake/unstake transactions. > * **btcli** applies one by default (a 5% tolerance). > * A tool or script calling raw `add_stake` / `remove_stake` has **no** slippage protection unless it explicitly uses the limit variant. ### Chain minimums and caps * **Minimum stake:** a single stake below **0.002 tao** (plus the swap fee) is rejected with `AmountTooLow`. * **Partial unstake floor:** a partial unstake must leave a remainder worth at least **0.002 tao** at the pool price — otherwise unstake the full position instead. * **Maximum single swap:** on dynamic subnets, a single stake larger than **1000× the pool's tao reserve** is rejected with `InsufficientLiquidity`. Split very large stakes into smaller transactions. --- # Yield What returns can investors expect when staking? _Source: https://beta.taostats.io/docs/concepts/staking/yield_ _Last reviewed: 2026-09-15_ What returns can investors expect when staking? ## Root staked vs. alpha staked A Chart showing the percentage of tao staked to root vs. to all the subnets ![Yield dashboard with total/root/alpha stake stat cards and a line chart of root-staked versus alpha-staked percentage of tao over time](https://beta.taostats.io/images/docs/concepts/taostats-root-vs-alpha-staked-chart.png) ## Yield Values Change the subnet in the left dorpdown to see results in other subnets * **Validator**: Validator Name * **STAKE**: Stake held in the subnet * **1H APY**: Actual returns in the last hour - extrapolated to a year. * **1D APY**: Actual returns in the last day - extrapolated to a year. * **1W APY**: Actual returns in the last week - extrapolated to a year. * **1M APY**: Actual returns in the last month - extrapolated to a year. ![Validator yield table with a subnet selector, returns simulator, and validator, stake, and 1H/1D/1W/1M APY columns](https://beta.taostats.io/images/docs/concepts/taostats-yield-values-apy-table.png) ## Yield Calculator Enter the tao/alpha you have staked to see your earnings every hour, day, week month. ![Yield calculator table where an entered stake amount produces per-validator APY percentages and projected tao earnings across hourly, daily, weekly, and monthly windows](https://beta.taostats.io/images/docs/concepts/taostats-yield-calculator-table.png) --- # nom/1k/24BTday This value represents the daily return in tao for every 1000 tao delegated. _Source: https://beta.taostats.io/docs/concepts/staking/some-of-the-math-behind-taostats_ _Last reviewed: 2026-09-15_ This value represents the daily return in tao for every 1000 tao delegated. We are sometimes a bit lax in the use of "day" vs. "BTDay", but in all these cases, we mean 7200 blocks - which is approximately 24 hours. (We are working to move to BTDay "Bittensor day" which is usually a few seconds longer than 24 hours). The Basic calculation is: $$ \dfrac{(daily\ return\ in\ tao)}{(\text{total }staked)} \cdot 1000 $$ For validators, this must be calculated *per subnet* and then is added for a network-wide value. On taostats, we are using actual returns from nominators on each validator to calculate a daily nom/1ktao/BTday. It accounts for Hotkey swaps, and other myriad ways that the calculation can be obfuscated on chain. ### Where you can find nom/1k/24BTday * [Validator Home](https://taostats.io/validators) This is the instantaneous value - from today's stats. * [Staking Calculator](https://taostats.io/staking) This is the 30 day average. This *smooths out* changes in the value that occur from changes in stake. * [Validator Pages](https://taostats.io/validators/5GKH9FPPnWSUoeeTJp19wVtd84XqFW4pyK2ijV2GsFbhTrP1) This is the sum of the value across all subnets. ![Dark-themed stat card displaying a nomination return per 1000 tao over 24 hours metric](https://beta.taostats.io/images/docs/concepts/taostats-nom-per-1k-stat-card.png) ## Dominance Dominance is calculated per subnet. It is the validator stake/total tao staked on the subnet. If measured in the context of a subnet, a healthy validator (High VTrust/low updated) should have dividends that are similar to their dominance. $$ \dfrac{(validator\ stake)}{(\text{total } subnet\ stake)} $$ This can be broken down a number of ways. * **Child Hotkey dominance:** This is the sum of all child & parent stake/ total tao staked in the subnet. * **Hotkey dominance:** Sum of all parent & child stakes for a single hotkey/total tao staked in the subnet. ## Daily Return The amount that the validator has earned in the last 24 hours. It is a sum of validator return across all subnets. $$ \sum_{all\ subnets} (Validator\ return) $$ ## Validator Return To determine a validator's return in a subnet, we need to account for all places that emission is gained for validators on the subnet: $$ \sum_{all\ subnets} \left( (parent\ hotkey\ contributions) + (child\ hotkey\ contributions) \right) $$ * Emission for the registered hotkey. * Calculate the % of stake held by the child hotkey \* the emission. (Note if there is no parent/child, the % of stake held is 100%) $$ \dfrac{Child\ hotkey\ stake}{all\ stake\ on\ hotkey} \cdot emission $$ * Child hotkey takes. If there is a child hotkey, they can extract a childkey take from parent hotkeys. Find the emission of the parent hotkey, and multiply by the childkey take. Sum for all parent hotkeys. $$ \sum_{\text{all parent hotkeys}} \dfrac{(\text{stake on parent})}{\text{all stake on hotkey}} \cdot emission \cdot childkeytake $$ * If the hotkey is a parent on one or more child hotkeys, calculate the parent return on other validator's child hotkeys, subtract the childkey take. Sum these across all parents. $$ \sum_{\text{all parent hotkeys}} \dfrac{(\text{stake on parent})}{\text{all stake on hotkey}} \cdot emission \cdot (1 - childkeytake) $$ These values, summed across the subnet, provide the validator return. ## APY: Annual Percentage Yield nom/1k/24BTday is the DPY\*1000. So, to get to APY, take any nom/1k/24BTday, and divide by 1000. The multiply by 365 to get the annual value. --- # Tokenomics Learn how tao and alpha tokens are emitted and distributed to participants on Bittensor. _Source: https://beta.taostats.io/docs/concepts/tokenomics_ _Last reviewed: 2026-09-15_ Learn how tao and alpha tokens are emitted and distributed to participants on Bittensor. > [!NOTE] > The one-line version: `tao` has a fixed **21M** supply on a Bitcoin-style > halving schedule. Each subnet also issues its own `alpha` token — and every > alpha token has the **same 21M max supply** on its own halving schedule. Each > subnet's alpha trades against tao at its own exchange rate, set by that > subnet's liquidity pool. ## Supply > [!NOTE] > The figures below are an illustrative snapshot, **not live**. For the current numbers, see the [Taostats tokenomics page](https://taostats.io/tokenomics/) or query the API. | Metric | Value | | --- | --- | | Total supply | `21,000,000` τ | | Circulating supply | `~11.2M` τ (snapshot) | | In circulation | `~53%` (snapshot) | The total issuance shown on Taostats is taken directly from the substrate blockchain and updates automatically. Because tao used to recycle registrations is burned back into the unissued supply, the halvening schedule lengthens over time — this is calculated at the current block/issuance. ## Halving Bittensor tokens follow the Bitcoin halving schedule. The **total token issuance**, not the block number, determines the exact point each halvening occurs (see [Halving](https://beta.taostats.io/docs/concepts/tokenomics/halving)). Because the halvening is issuance-driven, you read it off the chain rather than counting blocks. The current block and issuance are available from the API, for example: ```bash curl -H "Authorization: $TAOSTATS_API_KEY" \ "https://api.taostats.io/api/block/v1?limit=1" ``` ## Emission split Alpha emission is divided between the participants and the subnet pool: - **Miners** earn incentive for useful work - **Validators** earn dividends for accurate consensus - **Stakers** earn a share of the validator's dividends See [Staking in dTao](https://beta.taostats.io/docs/concepts/staking/staking-in-dtao) for how to participate. ## In this section - [Tokenomics](https://beta.taostats.io/docs/concepts/tokenomics/tokenomics) - [TAO](https://beta.taostats.io/docs/concepts/tokenomics/tao) - [Alpha tokens](https://beta.taostats.io/docs/concepts/tokenomics/alpha-tokens) - [Alpha emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission) — *see How emission works* - [Halving](https://beta.taostats.io/docs/concepts/tokenomics/halving) - [Burning](https://beta.taostats.io/docs/concepts/tokenomics/burning) - [Recycling](https://beta.taostats.io/docs/concepts/tokenomics/recycling) - [Price Impact and Slippage](https://beta.taostats.io/docs/concepts/staking/slippage) --- # Tokenomics Learn how tao and alpha tokens are emitted and distributed to participants on Bittensor. _Source: https://beta.taostats.io/docs/concepts/tokenomics/tokenomics_ _Last reviewed: 2026-09-15_ Learn how tao and alpha tokens are emitted and distributed to participants on Bittensor. [Tao](https://beta.taostats.io/docs/concepts/tokenomics/tao): The emission and distribution of tao into the subnets. [Alpha Tokens](https://beta.taostats.io/docs/concepts/tokenomics/alpha-tokens): Each subnet has a token that can be purchased with tao. [Subnet emission overview](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out): Alpha emission is divided between the participants and the subnet pool. [Halving](https://beta.taostats.io/docs/concepts/tokenomics/halving): Bittensor tokens (tao and alpha) follow the Bitcoin halving schedule. [Recycling](https://beta.taostats.io/docs/concepts/tokenomics/recycling): The purchase of a subnet or subnet neurons results in tao/alpha being recycled, [Staking](https://beta.taostats.io/docs/concepts/staking/staking-in-dtao): Buy and sell alpha in each subnet. Or for a safer option, stake into the root subnet. ## Definitions: * **Max Supply**: total number of tokens that will be issued. For all Subnet alpha tokens and for tao, this is 21 million (each). * **Total Supply**: Max Supply - burned. We can never exceed total supply, some tokens are burned. * **Burned**: Tokens that have been removed from circulation. A burn cannot be reversed - the token is eliminated. * **Recycled**: Tokens that have been removed from circulation. These tokens can be issued again. * **Circulating Supply**: Token that can be bought or sold. * For Subnets, this is a sum of alpha in the liquidity pool + all alpha that is staked. * For tao - this is all free tao and all staked tao. * **Total Issuance**: Total of all tokens issued. This is circulating supply + all token that is burned. --- # TAO The token of the Bittensor network _Source: https://beta.taostats.io/docs/concepts/tokenomics/tao_ _Last reviewed: 2026-09-15_ The token of the Bittensor network In Asian philosophy, Tao is the natural way of the universe, an unexplainable force that is an important part of everyday life. It gets its name from the Chinese character which means “the way” or “the path”. If you are a Star Wars fan - think "The Force." The tao token similarly pervades into every part of the Bittensor ecosystem. Tao is the token that is foundational to all of the tokens earned by core participants of the Bittensor network. For a high-level overview, the [Tokenomics](https://taostats.io/tokenomics/) page has a great history and background of the tao token. ## Tao Emission One block is written to the Bittensor blockchain approximately every 12 seconds. For every block written, 0.5 tao is created (in the current halving cycle — the first halving occurred in December 2025). (see [Tao Emission Distribution](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) for details) This means a maximum of 3600 tao are created every day. If a block takes longer to be produced, this can lower the daily emitted blocks. You can visualise the chain block production at [taostats](https://taostats.io/analytics/blocks) ![Analytics area chart titled chain block production, plotting block count per period over time with granularity, date, and CSV export controls](https://beta.taostats.io/images/docs/concepts/taostats-chain-block-production-chart.png) ### Distribution of Emitted tao Each block's emitted tao is distributed across the subnet pools according to each subnet's emission share. The exact formula lives in one canonical place — see **[Tao Emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission)** for the full mechanic and **[Price-based subnet emission shares](https://beta.taostats.io/docs/concepts/protocol-changes/price-based-emission-shares)** for how each subnet's share is computed. A subnet's emission % is simply its share of the per-block tao emission. ### Recycling Recycled tao is tao that is removed from circulation back into the unissued supply. [Recycling](https://beta.taostats.io/docs/concepts/tokenomics/recycling) ### Burned Tao can be burned, this is tao that is no longer in circulation, and is no longer accessible. ### tao vs. rao 1 billionth of a tao is a rao. 10^9 rao = 1 tao. The Bittensor network has a hard limit of 21,000,000 (21 million) tao. ### Halving Bittensor follows the halving schedule of Bitcoin. The first halving occurred in December 2025 when 10.5M tao had been emitted; block emission dropped from 1 tao to 0.5 tao per block at that point. [Halving](https://beta.taostats.io/docs/concepts/tokenomics/halving) --- # Alpha tokens Alpha is the generic name for subnet tokens. _Source: https://beta.taostats.io/docs/concepts/tokenomics/alpha-tokens_ _Last reviewed: 2026-09-15_ Alpha is the generic name for subnet tokens. Each subnet has its own token. From the dTao launch in February 2025, all subnets now have a token for staking. The subnet tokens are given a letter from an alphabet (greek, hebrew, arabic, etc.) but are generically defined as 'alpha'. (alpha is also the token of subnet 1, as it is the first letter in the greek alphabet) ## [Alpha Emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission) ## Alpha tokens can only be purchased with tao. Your staking transaction will take your tao to purchase alpha. This is done through a liquidity pool. Since each subnet has a token, each subnet has a liquidity pool (or Subnet Pool) that converts tao to the token of the subnet. The price cannot be used to determine the exact conversion, there is [Slippage](https://beta.taostats.io/docs/concepts/staking/slippage) on every transaction in and out of a Subnet Pool. ## [Subnet Pools](https://beta.taostats.io/docs/concepts/subnets/subnet-pools) ![Liquidity pool readout showing alpha and tao reserves with equal USD values and a stacked proportion bar splitting the pool by token count](https://beta.taostats.io/images/docs/concepts/taostats-subnet-pool-composition-panel.png) In the screenshot above, the value of alpha and tao in the pools are equal, but there are \~4x the alpha tokens in the pool vs. tao. Alpha Price is determined by the contents of the subnet pool. ## Alpha Price The Subnet pool determines the alpha price: $$ \alpha_{price} = \dfrac{\tau_{pool}}{\alpha_{pool}} $$ > [!NOTE] > **Example** > > Using the pool in the screenshot above. 110,900/432,470= 0.2564. This is the price of Subnet 64 when the screenshot was taken. ## [Slippage](https://beta.taostats.io/docs/concepts/staking/slippage) When buying alpha (or unstaking/selling alpha), the alpha price is indicative of the amount you will receive, but every purchase has slippage. ## What are alpha tokens used for? * Alpha is used for staking on a subnet. The more alpha staked, the higher the subnet's emissions * Alpha is used to register neurons (miners & validators) on the subnet. Alpha spent registering neurons is recycled. ## Related * [Alpha emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission) — how `alpha_in` and `alpha_out` are minted each block. * [Subnet Pools](https://beta.taostats.io/docs/concepts/subnets/subnet-pools) — the liquidity pool that sets the alpha price. * [Price Impact and Slippage](https://beta.taostats.io/docs/concepts/staking/slippage) — why the quoted price isn't the exact amount you receive. * [Staking in dTao](https://beta.taostats.io/docs/concepts/staking/staking-in-dtao) — how to stake tao into a subnet's alpha. * [Subnet emission overview](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out) — how emitted alpha is split across participants. --- # Halving The tokenomics of Bittensor follow Bitcoin: when half of the remaining supply has been issued, emission halves. _Source: https://beta.taostats.io/docs/concepts/tokenomics/halving_ _Last reviewed: 2026-09-15_ The [tokenomics](https://taostats.io/tokenomics) of Bittensor follow Bitcoin: when half of the remaining supply has been issued, emission halves. Tao and alpha both halve, but on independent schedules because their per-block emissions differ. > [!NOTE] > **Halvings are triggered by issuance, not block height** > > A halving fires when **total issuance** crosses the midpoint of the remaining supply (10.5M, then 15.75M, then 18.375M, ...) — it is not scheduled by block number. Because **recycled tao (e.g. registration burns) is subtracted from total issuance** and can be re-emitted, recycling pushes each halving *later*. Transaction fees are also **recycled** — subtracted from total issuance and available to be re-emitted — so, like registration recycling, they push halvings marginally later rather than being neutral. ## First halving (December 2025) The first halving occurred in December 2025, when 10,500,000 tao had been issued. The block reward dropped by 50%. * **tao**: per-block emission dropped from **1 → 0.5 τ/block** (December 2025). > [!NOTE] > **The tao halving date can shift** > > Recycling removes tao from circulation, so the exact halving date cannot be predicted precisely. The first tao halving occurred in **December 2025**. ## Current per-block emissions (post-Dec-2025) | Token | Per-block emission | Notes | |-------|--------------------|-------| | tao | 0.5 τ | halved Dec 2025 | | alpha_out | 1 α | unchanged until alpha-side halving | ## Second halving At 15.75M tao issued: * **tao**: 0.5 → 0.25 τ/block ## Third halving At 18.375M tao issued: * **tao**: 0.25 → 0.125 τ/block ## etc. > [!NOTE] > **The tao halving affects the timing of alpha halvings** > > Alpha added to the pool depends on the tao entering the pool. When tao halves, the tao entering each pool halves, which changes the slope of cumulative alpha emission. The tao halving is the yellow line in the chart below. > > The red dotted line marks 10.5M alpha — the first alpha-side halving threshold. > > ![Tao and alpha halving timeline](https://beta.taostats.io/images/docs/concepts/halving-schedule.jpg) ## See also * [Alpha Emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission) — how alpha emission is calculated each block. * [Tao Emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) — how 0.5 τ/block is distributed across subnets. --- # Burning When token is burned - it is no longer accessible and not a part of the circulating supply _Source: https://beta.taostats.io/docs/concepts/tokenomics/burning_ _Last reviewed: 2026-09-15_ When token is burned - it is no longer accessible and not a part of the circulating supply > [!NOTE] > **Recycled vs. burned** > > **Recycled tao/alpha** just becomes unissued - ready to be emitted again at a later date > > **Burned tao/alpha** is destroyed. This token no longer exists, and cannot be used. ## Tao * Tao extrinsic (transaction) fees are **recycled**, not burned — the tao is subtracted from total issuance and becomes available to be emitted again later (this defers the [halving](https://beta.taostats.io/docs/concepts/tokenomics/halving) slightly). Since runtime **445** the fee is also not paid to the block author. See [Recycling](https://beta.taostats.io/docs/concepts/tokenomics/recycling) and the [Runtime 445](https://beta.taostats.io/docs/concepts/protocol-changes/runtime-445) explainer. ## Alpha * Mining emission to the subnet owner hotkey is burned. * Subnet owners can burn alpha * Subsidized subnets: the validator alpha that would be converted to tao for root emissions is burned. --- # Recycling Recycling is the process of returning active tao or alpha to the unissued pool. _Source: https://beta.taostats.io/docs/concepts/tokenomics/recycling_ _Last reviewed: 2026-09-15_ Recycling is the process of returning active tao or alpha to the unissued pool. > [!NOTE] > **Recycled vs. burned** > > **Recycled tao/alpha** just becomes unissued - ready to be emitted again at a later date > > **Burned tao/alpha** is destroyed. This token no longer exists, and cannot be used. ## Alpha token recycling * **Neuron registration**: When a neuron is registered, the coldkey pays the registration fee in tao. However, the fee is sent through the [subnet pool](https://beta.taostats.io/docs/concepts/subnets/subnet-pools) and converted to alpha. This alpha is then recycled. * **Subsidized subnets**: In certain conditions, excess tao is sold to alpha. This alpha is then recycled. ## Tao recycling * **Root Neuron Registration**: If registering on root, there is no need to transfer the fee into alpha. The tao is directly recycled. * **Subnet Registration**: When a subnet is registered, 1 tao from the fee is placed in the subnet pool. If there is any lock fee remaining, it is recycled. * **Transaction fees**: Extrinsic (transaction) fees are recycled — subtracted from total issuance and available to be emitted again later, rather than paid to the block author. Since runtime **445** this reverted the earlier behaviour of rewarding the block author. Alpha-denominated fees are sold to tao and that tao is recycled. See the [Runtime 445](https://beta.taostats.io/docs/concepts/protocol-changes/runtime-445) explainer. --- # How emission works Every block the chain emits TAO, mints alpha in each subnet, and distributes it down to individual stakeholders. _Source: https://beta.taostats.io/docs/concepts/how-emission-works_ _Last reviewed: 2026-09-15_ Every block the chain emits TAO, mints alpha in each subnet, and distributes it down to individual stakeholders. This section follows that flow **step by step** — each page picks up where the previous one left off, with a *How we got here* and a *What's next* at the top and bottom. ## The flow, step by step 1. **[TAO emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission)** — 0.5 τ/block is split across subnets; each subnet's share is injected into its pool or spent as a chain buy. 2. **[Alpha emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission)** — each subnet mints alpha per block, split into `alpha_in` (pool) and `alpha_out` (1 α to participants). 3. **[Split `alpha_out` among participants](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out)** — owner 18%, miners 41%, validators 41%. 4. **[Parent / child hotkeys](https://beta.taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys)** — aggregate each validator's dividends across its parent and child hotkeys. 5. **[Root vs alpha split](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha)** — divide the validator's dividends into a root proportion and an alpha proportion. 6. Distribute to stakeholders — **[root](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root)** and **[alpha](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-alpha)**. ## Pages in this section - [1. TAO emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) - [2. Alpha emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission) - [3. Split alpha_out (owner / miners / validators)](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out) - [4. Parent / child hotkeys](https://beta.taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys) - [5. Root vs alpha split](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha) - [6a. Stakeholder emissions: root](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root) - [6b. Stakeholder emissions: alpha](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-alpha) --- # TAO emission How the TAO emitted every block is shared between subnets, and how each subnet's share splits into TAO injected into its pool and chain buys of alpha. _Source: https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission_ _Last reviewed: 2026-09-15_ > [!NOTE] > **Where we are — step 1 of the emission flow** > > This is the start of the flow. See the [full emission flow](https://beta.taostats.io/docs/concepts/how-emission-works) for the whole chain. Basics on how tao is emitted and distributed in Bittensor. Every block, 0.5 tao is emitted by the chain (the first [Halving](https://beta.taostats.io/docs/concepts/tokenomics/halving) was in December 2025). Where do these tokens go? The tao is divided amongst the subnets based on emission. And, then, depending on the alpha price, some is injected into the liquidity pool, and some is used as a chain buy to purchase alpha (that is held as protocol-owned alpha, not recycled). ## How emission is determined As of spec 440 (2026-07-27), a subnet's share of per-block emission is **no longer proportional to demand**. Emission is now computed in two stages: 1. **Demand.** Each subnet's demand `s` is `subnet_moving_price × (1 − miner_burned)`, normalized across all subnets. (Before PR [#2800](https://github.com/opentensor/subtensor/pull/2800) this was also weighted by `root_proportion`; that weighting has been removed.) Until spec 440 this quantity *was* the emission share — now it is the **input** to the gate. 2. **The gate.** Demand feeds a Hill-function gate at a q-mass quantile bar θ: subnets above the bar keep ~all their share, the below-bar tail is choked toward zero, and the freed-up emission is redistributed up to the winners. Final emission is `eᵢ = sᵢ·gate(sᵢ) / Σⱼ sⱼ·gate(sⱼ)`. Tao Flow / Net Tao Flow no longer drive emission. For the full derivation of the gate, the quantile bar, and the sudo knobs (`q`, `h`), see the canonical page: **[The emission gate (spec 440)](https://beta.taostats.io/docs/concepts/protocol-changes/emission-gate)**. For how demand itself is built, see [Price-based subnet emission shares](https://beta.taostats.io/docs/concepts/protocol-changes/price-based-emission-shares). > [!WARNING] > **Emission is not pro-rata to demand** > > Any APY or emission estimate that assumes a subnet earns emission *in proportion to* its price/demand is wrong as of spec 440. Above-bar winners are understated and the below-bar tail is overstated. See [The emission gate](https://beta.taostats.io/docs/concepts/protocol-changes/emission-gate). > [!NOTE] > **Historical** > > Between Nov 2025 and Jun 2026, emission shares were driven by tao flow (and later net tao flow). That mechanism was replaced on 2026-06-23 by the price-based shares + miner-burn scaling design, which spec 440 (2026-07-27) then turned into the *demand* input to the emission gate. Emitted tao has 2 destinations: * tao injected * chain buy ### Tao injected This is the primary feature of tao emission. Tao from the chain is injected into the subnet's liquidity pool. Alpha is minted and added at the same time (to keep the liquidity pool and the price balanced). The alpha minted into the pool each block is capped at `root_proportion × alpha_emission`. Since `alpha_emission = 1` for all subnets currently, the de-facto per-block alpha cap is simply the subnet's `root_proportion`. Any TAO emission that can't be matched into the pool under this cap funds on-chain alpha buys instead (see Chain Buy below). ### Chain Buy If alpha injection is limited by the cap, there is excess tao that was emitted to the subnet. This tao is used to buy alpha; that alpha is not recycled — it is held in a protocol wallet and redistributed to alpha holders if the subnet is dissolved. This mechanism raises the alpha price — eventually leading to the chain buys stopping. > [!NOTE] > Example — Subnet 64 > > SN64 emits **0.05575 τ** this block (11.15% share × 0.5 τ). At a price of 0.0786 τ, that tao would mint **0.7093 α** if fully injected. > > But SN64's `root_proportion` is **0.14605**, so the `alpha_in` cap is `0.14605 × 1 = 0.14605 α`. Since 0.7093 α ≫ 0.14605 α, injection is clamped to the cap: > > * **Injected** (into the pool): 0.14605 α × 0.0786 τ = **0.01148 τ** (20.6% of emission) > * **Chain buy** (excess → market buy of alpha): **0.04427 τ** (79.4% of emission) ### What's next **Step 2 — [Alpha emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission):** now that TAO has been emitted to each subnet, the subnet mints its own alpha per block, split into `alpha_in` (the pool) and `alpha_out` (1 α to participants). --- # 2. Alpha emission Each subnet emits alpha every block through two distinct pathways, which serve different purposes: _Source: https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission_ _Last reviewed: 2026-09-15_ > [!NOTE] > **Where we are — step 2 of the [emission flow](https://beta.taostats.io/docs/concepts/how-emission-works)** > > How we got here: > > 1. [TAO emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) — TAO split across subnets, injected into pools + chain buys. > > **This page (step 2):** each subnet mints its own alpha per block — `alpha_in` (pool) and `alpha_out` (participants). ## Alpha emission Each subnet emits alpha every block through **two distinct pathways**, which serve different purposes: * **`alpha_in`** — alpha injected into the subnet's liquidity pool (paired with tao), which sets the pool price and depth. When the pool injection is capped, the leftover tao becomes a **chain buy** instead. Capped at `root_proportion × alpha_emission` per block (de-facto the subnet's `root_proportion`, since `alpha_emission = 1`). See [Tao Emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) for the chain-buy mechanic. * **`alpha_out`** — alpha paid out to the subnet owner, miners, validators, and stakers. A flat 1 α/block, distributed via the incentive split — see [Subnet emission overview](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out). `alpha_in` and `alpha_out` are governed by independent rules and currently halve on different schedules. See [Halving](https://beta.taostats.io/docs/concepts/tokenomics/halving) for the full schedule. ### alpha_in (capped at root_proportion × alpha_emission) Each block, the chain injects tao into the subnet pool and mints a matching amount of alpha to keep the pool's tao : alpha ratio balanced. The alpha injected is the smaller of two quantities: the tao injected divided by the current alpha price, and the per-block cap `root_proportion × alpha_emission`: $$ \alpha_{in} = \min\!\left(\dfrac{\tau_{injected}}{\alpha_{price}},\ root\_proportion \times \alpha_{emission}\right) $$ Since `alpha_emission = 1` for all subnets currently, the cap is de-facto the subnet's `root_proportion`. Below the cap, the injected alpha is simply the injected tao valued at the current alpha price: $$ \alpha_{in} = \dfrac{\tau_{injected}}{\alpha_{price}} $$ > [!NOTE] > **Cap: alpha_in ≤ root_proportion × alpha_emission** > > If `tao_injected / alpha_price` would exceed `root_proportion × alpha_emission`, the `tao_injected` is reduced until `alpha_in` equals the cap. The leftover tao becomes a **chain buy** — the chain buys alpha from the pool. The alpha purchased this way is **not recycled**; it is held in a protocol wallet and redistributed to alpha holders if the subnet is dissolved. See [Tao Emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) for the full mechanic. > > (This cap was previously a flat 0.5 α/block. As of subtensor PR [#2779](https://github.com/opentensor/subtensor/pull/2779) the `alpha_in` cap is `root_proportion × alpha_emission`.) ### alpha_out (1 α/block) `alpha_out` is a flat 1 α emitted per block per subnet, distributed to the subnet owner, miners, validators, and stakers via the standard incentive split. It is **not** affected by the December 2025 tao halving. `alpha_out` will halve on its own schedule, when 10.5M alpha have been issued in that subnet — see [Halving](https://beta.taostats.io/docs/concepts/tokenomics/halving). To learn how this 1 α is split across participants, see [Subnet emission overview](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out). ### Worked example — Subnet 64 SN64 has emission share 11.15%, alpha price 0.0786 τ, and `root_proportion` 0.14605 (so the `alpha_in` cap is `0.14605 × 1 = 0.14605 α`). * tao emitted to this subnet: 11.15% × 0.5 τ = **0.05575 τ** * alpha this tao would mint at price: 0.05575 / 0.0786 = **0.7093 α** (far exceeds the 0.14605 α cap) * alpha_in this block: **0.14605 α** (clamped to the `root_proportion` cap) * tao actually injected: 0.14605 × 0.0786 = **0.01148 τ** (20.6% of emission) * excess tao → chain buy (alpha held in protocol wallet): **0.04427 τ** (79.4% of emission) * alpha_out this block: **1 α** (unchanged) Total alpha entering the subnet ecosystem this block: 0.14605 α (`alpha_in`) + 1 α (`alpha_out`) = **1.14605 α**. ### What's next **Step 3 — [Split `alpha_out` among participants](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out):** the 1 α/block of `alpha_out` is divided among the subnet owner (18%), miners (41%), and validators (41%). ### See also * [Halving](https://beta.taostats.io/docs/concepts/tokenomics/halving) — current emission ceilings and the halving schedule. * [Tao Emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) — how 0.5 τ/block is split into pool injection and chain buys, and what happens to chain-buy alpha (held in protocol wallet, redistributed on subnet dissolution). * [Subnet emission overview](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out) — how `alpha_out` is distributed across owner, miners, validators, and stakers. --- # Split alpha_out (owner / miners / validators) This page shows how a subnet's alpha_out is divided among participants, then points to the rest of the flow. _Source: https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out_ _Last reviewed: 2026-09-15_ > [!NOTE] > **Where we are — step 3 of the [emission flow](https://beta.taostats.io/docs/concepts/how-emission-works)** > > How we got here: > > 1. [TAO emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) — TAO split across subnets. > 2. [Alpha emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission) — each subnet mints `alpha_in` + `alpha_out`. > > **This page (step 3):** split the 1 α/block of `alpha_out` among the subnet owner, miners, and validators. This page shows how a subnet's `alpha_out` is divided among participants, then points to the rest of the flow. ![Cascading flow diagram of one alpha emission split among subnet owner, validators, and miners, then through hotkey allocations and a root:alpha stake split to validator and stakeholders](https://beta.taostats.io/images/docs/concepts/taostats-subnet-emission-distribution-flow-diagram.png) ## The `alpha_out` split (1 α/block) * **Subnet owners** receive **18%** of subnet emission. * **[Miners](https://beta.taostats.io/docs/concepts/miners/consensus-for-miners)** receive **41%** of emissions. * **[Validators](https://beta.taostats.io/docs/concepts/validators/dividends-for-validators)** receive **41%** of emissions — which is then further divided amongst their stakeholders (steps 4–6). ## What's next **Step 4 — [Parent / child hotkeys](https://beta.taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys):** aggregate each validator's dividends across its parent and child hotkeys. Then: * Step 5: [Root vs alpha split](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha) — divide the validator's dividends into root and alpha proportions. * Step 6: award stakeholder rewards — [root](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root) and [alpha](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-alpha). --- # 4. Parent / child hotkeys Parent hotkeys are validators that do not run infrastructure in a subnet. _Source: https://beta.taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys_ _Last reviewed: 2026-09-15_ Parent hotkeys are validators that do not run infrastructure in a subnet. They use their stake as a parent hotkey to a validator running infrastructure (the child hotkey). Parent hotkeys have all of the same abilities as child hotkeys. * Delegators may stake alpha on a parent hotkey inside a subnet. * Delegators staked on root receive root stake from parent hotkeys. > [!NOTE] > **Where we are — step 4 of the [emission flow](https://beta.taostats.io/docs/concepts/how-emission-works)** > > How we got here: > > 1. [TAO emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) — TAO split across subnets. > 2. [Alpha emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission) — each subnet mints `alpha_in` + `alpha_out`. > 3. [Split `alpha_out` among participants](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out) — owner 18% / miners 41% / validators 41%. > > **This page (step 4):** aggregate each validator's dividends across its parent and child hotkeys. ## Calculating emissions for Parent/Child hotkeys > [!NOTE] > **Example** > > Taostats is the validator > > ![Spreadsheet row with columns for child, root stake, alpha stake, child hotkey take, amount parent staked, and dividends used in parent/child emission calc](https://beta.taostats.io/images/docs/concepts/taostats-parent-child-dividends-table.png) > > There are two parent hotkeys: > > ![Spreadsheet listing parent hotkeys with root stake, alpha stake, and stake-percentage columns as inputs to an emission calculation](https://beta.taostats.io/images/docs/concepts/taostats-parent-hotkeys-stake-table.png) The validator running the child hotkey (running the validation infrastructure) can impose a `child hotkey take` on any validator running a parent hotkey. In the screenshot above the child hotkey take is set at 4.5%. #### Step 1: Find the tao and alpha staked to the hotkey First, we determine the amount of tao and alpha each validator has on this hotkey: * Taostats has 8/9 of its stake * parent\_1 has 50% of its stake on this child hotkey * parent\_2 has 100% of its stake on the child hotkey. ![Spreadsheet mapping accounts (validator and two parents) to their tao and alpha stake columns for finding stake on a hotkey](https://beta.taostats.io/images/docs/concepts/taostats-hotkey-tao-alpha-stake-table.png) #### Step 2: Determine the total stake of each validator `tao_weight = 0.18` $$ stake_{total} = stake_{alpha} + stake_{root} \cdot tao_{weight} $$ ![Spreadsheet with tao, alpha, and total-stake columns per validator, combining the two token stakes into one weighted total](https://beta.taostats.io/images/docs/concepts/taostats-validator-total-stake-table.png) #### Step 3: Find the Percentage of total stake, and apply it to the dividends. The 0..15 dividends are split based on the % of total stake for each validator ![Spreadsheet splitting a fixed dividend pool across validators proportionally by each one's percentage of total stake](https://beta.taostats.io/images/docs/concepts/taostats-dividend-proportional-split-table.png) #### Step 4: Apply child hotkey take to parents Taostats has a 4.5% child hotkey take. Remove 4.5% of the dividends from each parent, and apply the proceeds to taostats. ![Spreadsheet applying a child hotkey take to each parent's dividends, showing dividends, take, and final dividends columns](https://beta.taostats.io/images/docs/concepts/taostats-childkey-take-final-dividends-table.png) 0.000102 and 0.003372 are taken from parent\_1 and parent\_2, and added to taostats' final dividends. #### Step 5: Repeat this math for all child hotkeys. Taostats has 1/9 of its stake on another validator. Parent\_1 has 50% of its stake on other validators. Sum these dividends for all hotkeys in a subnet to get the final dividends for a validator on a subnet. > [!NOTE] > **Child Hotkey Take** > > Note that the child hotkey take collected by the child hotkey is added to the dividends of the validator. > > This means that most of the child hotkey take is distributed to the stakeholders of the validator, and it is not directly deposited to the validator's wallet. ### What's next **Step 5 — [Root vs alpha split](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha):** the validator's remaining dividends are divided into a root proportion and an alpha proportion, then distributed to stakeholders ([root](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root) / [alpha](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-alpha)). --- # 5. Root vs alpha split In the Bittensor ecosystem, holders of tao may stake to a validator in a subnet in two different ways: _Source: https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha_ _Last reviewed: 2026-09-15_ > [!NOTE] > **Where we are — step 5 of the [emission flow](https://beta.taostats.io/docs/concepts/how-emission-works)** > > How we got here: > > 1. [TAO emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) — TAO split across subnets. > 2. [Alpha emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission) — each subnet mints `alpha_in` + `alpha_out`. > 3. [Split `alpha_out` among participants](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out) — owner / miners / validators. > 4. [Parent / child hotkeys](https://beta.taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys) — aggregate each validator's dividends. > > **This page (step 5):** divide the validator's dividends into a root proportion and an alpha proportion. In the Bittensor ecosystem, holders of tao may stake to a validator in a subnet in two different ways: * **Root stake** : Staking to a validator in subnet 0, the root subnet. * **Alpha Stake**: Staking to a validator in a subnet, exchanging your tao for alpha token. ![Flow diagram of child/parent hotkey allocations entering a validator and a root:alpha split producing alpha-denominated local stake and tao-denominated root stake](https://beta.taostats.io/images/docs/concepts/taostats-root-alpha-stake-split-diagram.png) The ratio of root: alpha staked is calculated using the `root_proportion`. ## Calculating root proportion `root proportion` is calculated from 3 values: * **tao on root**: The total amount of tao on root. * **alpha issued**: The sum of `alpha_in` and `alpha_out` (all alpha emitted) * **tao\_weight**: a variable set by the chain. The current `tao_weight` is 0.18. $$ root_{proportion} = \dfrac{tao_{weight}\, tao_{staked}}{tao_{weight}\, tao_{staked} + alpha_{issued}} $$ ### Current Root prop Root proportion will change every block, as the tao and alpha values will have increased. The results can be charted over time: ![At day 0 there are 6M tao available.](https://beta.taostats.io/images/docs/concepts/9832735c-Screenshot_2025-02-03_at_22.27.36.jpg) The chart will vary on the amount of tao available at the moment the subnet is created. The above chart shows day 0 = 6 million tao. On day 0 of the subnet, 100% of emission will go to root stakeholders. 50% root: 50% alpha is met at approximately day 70 (this is highly variable, and just an estimate). > [!NOTE] > **Each Subnet has a statistics page showing the Root proportion chart for the subnet.** > > [https://beta.taostats.io/subnets/75/statistics](https://beta.taostats.io/subnets/75/statistics) In this second chart, the yellow/green subnet is created 100 days after the blue/red subnet (9,720,000 tao, and 0 alpha for the 2nd subnet): ![Line chart plotting root and alpha proportion (percent) versus time in days for two subnets, with the second pair time-shifted from the first](https://beta.taostats.io/images/docs/concepts/taostats-root-alpha-proportion-decay-chart.jpg) ### What's next The validator's dividends are now split into a root share and an alpha share. The final step distributes each to stakeholders: * **Step 6a — [Stakeholder emissions: root](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root)** * **Step 6b — [Stakeholder emissions: alpha](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-alpha)** --- # 6a. Stakeholder emissions: root Stakeholders on root place their delegation of tao on a root validator. _Source: https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root_ _Last reviewed: 2026-09-23_ > [!NOTE] > **Where we are — step 6a of the [emission flow](https://beta.taostats.io/docs/concepts/how-emission-works)** > > How we got here: > > 1. [TAO emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) — TAO split across subnets. > 2. [Alpha emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission) — each subnet mints `alpha_in` + `alpha_out`. > 3. [Split `alpha_out` among participants](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out) — owner / miners / validators. > 4. [Parent / child hotkeys](https://beta.taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys) — aggregate each validator's dividends. > 5. [Root vs alpha split](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha) — divide dividends into root and alpha. > > **This page (step 6a):** distribute the **root** share to stakeholders. ## Root Emissions: Stakeholders on root place their delegation of tao on a root validator. * For every subnet the validator is active: stakeholders will earn a proportion of the rewards. * Root staking will have lower returns over time, as stakeholder emission is split between alpha and root stakeholders (see [Emissions: Root vs. Alpha Stake](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha) * Every block, root's share of each subnet's alpha emission is set aside as alpha — it is not sold to tao. Since **[Root Reborn](https://beta.taostats.io/docs/concepts/protocol-changes/root-reborn/explainer)** (mainnet, `spec_version` 441) it is not auto-compounded onto your root stake either: at each subnet epoch it is added, still as that subnet's alpha, to your validator's basket and held until you make a manual claim. See [Root Validator Baskets](https://beta.taostats.io/docs/concepts/staking/root-validator-baskets). ![Flow diagram of validator emissions through a root:alpha split, with the tao-denominated root-stake branch highlighted and each branch split by commission between validator and stakeholders](https://beta.taostats.io/images/docs/concepts/taostats-root-emission-flow-diagram.png) > [!NOTE] > **Pre- dTao analogy** > > Pre-dTao, staking was done to a validator. > > * Rewards were earned across all subnets the validator was active. > > dTao: this is staking to a validator on root. ## Calculating Root Emission Step 1: The validator take is removed from the root dividend and staked to the validator's hotkey as alpha on that subnet. Step 2: The rest, still alpha, is added to the validator's basket. It is shared among the validator's root stakers in proportion to their root stake and reaches their stake only when they claim. ### What's next This is the final step of the emission flow — the root share has reached stakeholders. Under **Root Reborn** these rewards accrue to your validator's basket and are realized on a manual `claim_root`; see [Root Validator Baskets](https://beta.taostats.io/docs/concepts/staking/root-validator-baskets) and [Staking in dTao](https://beta.taostats.io/docs/concepts/staking/staking-in-dtao). See also the parallel path, [Stakeholder emissions: alpha](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-alpha). --- # Stakeholder emissions: alpha Stakeholders may stake on a validator in a subnet. _Source: https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-alpha_ _Last reviewed: 2026-09-15_ Stakeholders may stake on a validator in a subnet. * Staking on a subnet converts tao into subnet [Alpha Tokens](https://beta.taostats.io/docs/concepts/tokenomics/alpha-tokens). This will cause there to the [Slippage](https://beta.taostats.io/docs/concepts/staking/slippage) * For every block, a percentage of emissions will be rewarded to each alpha stakeholder. > [!NOTE] > **Where we are — step 6b of the [emission flow](https://beta.taostats.io/docs/concepts/how-emission-works)** > > How we got here: > > 1. [TAO emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) — TAO split across subnets. > 2. [Alpha emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission) — each subnet mints `alpha_in` + `alpha_out`. > 3. [Split `alpha_out` among participants](https://beta.taostats.io/docs/concepts/how-emission-works/split-alpha-out) — owner / miners / validators. > 4. [Parent / child hotkeys](https://beta.taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys) — aggregate each validator's dividends. > 5. [Root vs alpha split](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha) — divide dividends into root and alpha. > > **This page (step 6b):** distribute the **alpha** share to stakeholders. ## Emission in Alpha ![Flow diagram of a validator's alpha emission passing through a root:alpha split into local and root stake, each divided between validator and stakeholders](https://beta.taostats.io/images/docs/concepts/taostats-alpha-emission-split-flow-diagram.png) Step 1: From the total dividends in alpha - deduct the validator's take, and award to their hotkey. Step 2: With the remaining alpha, award every hotkey a weighted average (based on the amount of alpha stake) ## What's next This is the final step of the emission flow — the alpha share has reached stakeholders as compounding subnet-alpha stake. To learn how to hold, add to, or unwind that position, see [Staking in dTao](https://beta.taostats.io/docs/concepts/staking/staking-in-dtao) and [Price Impact and Slippage](https://beta.taostats.io/docs/concepts/staking/slippage). See also the parallel path, [Stakeholder emissions: root](https://beta.taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root). --- # Wallets & accounts Wallets & accounts: Wallets, coldkeys, hotkeys, Coldkeys, Hotkeys, Connecting your wallet, Sign a message with your wallet key _Source: https://beta.taostats.io/docs/concepts/wallets-accounts_ _Last reviewed: 2026-09-15_ - [Wallets, coldkeys, hotkeys](https://beta.taostats.io/docs/concepts/wallets-accounts/wallets-coldkeys-hotkeys) - [Coldkeys](https://beta.taostats.io/docs/concepts/wallets-accounts/coldkeys) - [Hotkeys](https://beta.taostats.io/docs/concepts/wallets-accounts/hotkeys) - [Connecting your wallet](https://beta.taostats.io/docs/concepts/wallets-accounts/connecting-your-wallet) - [Sign a message with your wallet key](https://beta.taostats.io/docs/concepts/wallets-accounts/sign-a-message-with-your-wallet-key) --- # Wallets, coldkeys, hotkeys Wallets are used to store and house your tokens. _Source: https://beta.taostats.io/docs/concepts/wallets-accounts/wallets-coldkeys-hotkeys_ _Last reviewed: 2026-09-15_ Wallets are used to store and house your tokens. But the term wallet can be used for a few different things in the Bittensor ecosystem. ## Wallet application Wallet applications are the way you interact with your tao on chain. There are many wallets (The Bittensor Discord has a [FAQ](https://discord.com/channels/799672011265015819/1215386737661055056/1220037507656450068) listing the wallets that support Bittensor.) No matter what wallet application you use, the wallet is just looking at your tao on the chain. ### Taostats wallets We think the taostats wallet applications are pretty good! #### [Chrome extension](https://chromewebstore.google.com/detail/taostats-the-bittensor-wa/khdnjjgidjjbjpececegbfglalchffpo) #### [Mobile apps](https://taostats.io/app) > [!NOTE] > **Banking** > > When you access your bank account, you use the mobile app, the website, an ATM, or even a bank teller in the bank. These are all interfaces into your bank account. > > None of these interfaces hold the money in your account, but are access points to the bank to manipulate your money. You can take money in and out, pay bills, etc.from the interfaces in your account. You can connect many wallets to the [taostats delegation app](https://delegate.taostats.io) . Once connected you can add/remove stake to validators using taostats. (Taostats has no access to your wallet - the actions are all performed by the wallet app on chain). You can also use the [Command Line Interface (CLI)](https://beta.taostats.io/docs/concepts/command-line-tool) to interact with your wallet without using a wallet application. Your tao is always stored on chain, and the application wallet is a way to gain access to that tao. ### Switching wallet applications When changing your wallet applications - you do not need to do anything with your tao. You can just connect your coldkey wallet to the new interface. This is done by using your 12 word mnemonic to regenerate the wallet in the new interface. You can then remove the your wallet from the old application. We do not recommend removing a wallet application interface before addeing the new interface - just in case there is an error. #### Things you do not have to do when switching wallet applications ![Dark-themed Discord chat message describing unstaking from one wallet app and re-staking in another via a hardware device](https://beta.taostats.io/images/docs/concepts/taostats-wallet-switch-chat-message.png) > [!NOTE] > **Banking** > > "I no longer want to use my bank's mobile app, I want to use the website. In order to switch, I closed my savings account in the mobile app. I then logged in on my bank's website, and opened a savings account there." By unstaking your tao, you lose rewards for a period backwards in time (this can be up to 24 hours!) When restaking - you lose rewards for a period of time in the future (this can be up to 24 hours!). While it is unlikely that you will lose rewards for 48 hours, it is possible. ## Coldkey Wallet Your coldkey wallet is stored on the Bittensor chain and holds your tao. The chain acts as the "bank" for your wallet address and stores your funds and transaction history. For this reason, it is essential that your coldkey be kept secure. See [Coldkeys](https://beta.taostats.io/docs/concepts/wallets-accounts/coldkeys) for more detail. > [!NOTE] > **Banking** > > The coldkey wallet on the chain is equivalent to your bank account in the vault. Anyone with access to the money in your account can add or extract from the vault. ## Hotkey Hotkeys are used on chain. If you run a validator or miner, you use a hotkey (associated to a coldkey). If you stake tao, you are also using a hotkey. All tao/alpha on a hotkey is controlled by the owner of the coldkey. This means that staked tao/alpha is fully under your control, as are the emissions earned by miners/validators. See [Hotkeys](https://beta.taostats.io/docs/concepts/wallets-accounts/hotkeys) for more detail. ## Securing your wallet Because your coldkey controls your funds on chain, securing it is essential. Bittensor supports several complementary approaches — hardware ledgers, multisignature accounts, and proxy accounts — that can be combined for defence in depth. - [Securing a wallet: ledgers, multisig & proxies](https://beta.taostats.io/docs/concepts/security/securing-a-wallet) — the threat model and when to use each approach. - [Multisig, explained: tutorial](https://beta.taostats.io/docs/concepts/security/multisig-tutorial) — how multisignature wallets work, step by step. - [Multisig: worked examples](https://beta.taostats.io/docs/concepts/security/multisig-examples) — real multisig flows decoded from the chain. For the chain-level detail, see [Multisig extrinsics](https://beta.taostats.io/docs/understanding-taostats/extrinsics/multisig-extrinsics) and [Proxy extrinsics](https://beta.taostats.io/docs/understanding-taostats/extrinsics/proxy-extrinsics). --- # Coldkeys The coldkey is your wallet on the chain. _Source: https://beta.taostats.io/docs/concepts/wallets-accounts/coldkeys_ _Last reviewed: 2026-09-15_ The coldkey is your wallet on the chain. It is used for tao storage and transferring tao to and from others. Coldkeys can have hotkeys for performing tasks on chain. ## Coldkey uses * Funds in your coldkey can be transferred in and out of your coldkey. * Subnets are registered on a coldkey, using the funds on that coldkey. * Delegation to validators. The tao on your coldkey can be delegated to the hotkey of a validator. ## Create a coldkey wallet In the btcli:`btcli wallet create` Using Polkadot JS extension: 1. Create new account ![Dark-themed wallet toolbar with search, an orange add button, and settings, plus a dropdown offering a Create new account option](https://beta.taostats.io/images/docs/concepts/taostats-wallet-create-account-menu.png) In all cases, you will be provided with a 12 word mnemonic/seed phrase. it is **very important** to keep this phrase in a safe place. ![Wallet screen displaying a generated 12-word mnemonic seed phrase in a bordered box under an uppercase label](https://beta.taostats.io/images/docs/concepts/taostats-wallet-mnemonic-seed-display.png) > [!NOTE] > **Key type and address format** > > Coldkeys and hotkeys are **sr25519** keypairs. Addresses use the SS58 format with Bittensor's network prefix **42** (an address such as `5F...`). The 12-word mnemonic is the only recovery path — the wallet password only decrypts the keyfile on one machine; anyone holding the mnemonic can regenerate the key and controls the funds. > [!WARNING] > **NEVER, EVER provide your mnemonic/seed phrase to "support."** > > Anyone with your seed phrase has full access to your wallet. 3. This will generate a coldkey public hash/public key that looks like `5E6yV6xPjFrYv167nXaMhdmZUwMR5QM1M9jJhL85QPhi2DYc`. For Bittensor, all keys will begin with a 5. ## Coldkey security Your coldkey public key (`5E6yV6xPjFrYv167nXaMhdmZUwMR5QM1M9jJhL85QPhi2DYc`) is public and can be searched on taostats to display you your balance, transactions, etc. Who owns the coldkey is anonymous. Others can *send* tao to your cold key, but only you can withdraw from your coldkey. Your mnemonic phrase allows you to add your coldkey into wallet applications. You can import existing coldkeys into wallet apps, etc. However, *anyone* can add a wallet with the 12 word phrase, including scammers. If you believe your coldkey has been compromised, you can perform a coldkey swap. ### Coldkey swap A coldkey swap will lock the funds on your coldkey for 5 days, and after 5 days, the funds will be available on a new coldkey. The delay prevents bad actors from swapping coldkey access away from existing users. This is available today via `btcli wallet swap_coldkey`. ## Hotkeys Hotkeys are connected to the cold key, and used for performaing transactions on chain. See [Hotkeys](https://beta.taostats.io/docs/concepts/wallets-accounts/hotkeys) for details. --- # Hotkeys Hotkeys are part of your Bittensor wallet, and are used to perform actions on the chain in a secure fashion. _Source: https://beta.taostats.io/docs/concepts/wallets-accounts/hotkeys_ _Last reviewed: 2026-09-15_ Hotkeys are part of your Bittensor wallet, and are used to perform actions on the chain in a secure fashion. [Coldkeys](https://beta.taostats.io/docs/concepts/wallets-accounts/coldkeys) can have multiple hotkeys. Each hotkey can be used to: * Register a miner or validator on a subnet. (You can use the same hotkey on multiple subnets, but you cannot reuse the same hotkey on a single subnet). * Stake alpha to a validator's hotkey. Under dTao, tao is converted to the destination subnet's alpha at stake time, and alpha is what is actually staked to the hotkey. In both of these cases, staking rewards are paid in alpha and credited to the hotkey you staked to. All stake attached to a hotkey remains under **your** coldkey and can be unstaked back to the coldkey. --- # Connecting your wallet Taostats' staking tools require a connection with a wallet extension. _Source: https://beta.taostats.io/docs/concepts/wallets-accounts/connecting-your-wallet_ _Last reviewed: 2026-09-15_ Taostats' staking tools require a connection with a wallet extension. To delegate with the taostats apps, you must: 1. have a wallet that has a browser extension 2. Click Connect Wallet to add a wallet: 3. ![Dark-themed app panel with a light Connect Wallet button bearing a wallet icon and a Buy action below](https://beta.taostats.io/images/docs/concepts/taostats-connect-wallet-button.png) Your wallet extension will ask for permission to connect to taostats (Polkadot wallet is shown) 4. ![Polkadot.js account connection request dialog showing the requesting app and URL, an account selection list with identicons, and Connect and Reject buttons](https://beta.taostats.io/images/docs/concepts/taostats-polkadot-connection-request-dialog.png) 5. Click connect and enter your password ## Troubleshooting wallet connectivity [Stake troubleshooting](https://beta.taostats.io/docs/understanding-taostats/taostats-pro/stake-troubleshooting) ## --- # Sign a message with your wallet key One way to prove ownership of a wallet is to sign a message. _Source: https://beta.taostats.io/docs/concepts/wallets-accounts/sign-a-message-with-your-wallet-key_ _Last reviewed: 2026-09-15_ One way to prove ownership of a wallet is to sign a message. This can be done with the [polkadot website](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Farchive.chain.opentensor.ai%3A443#/signing) Import your wallets, and choose the wallet you would like to sign the message with. ![Wallet message-signing panel with an account selector, message field, hex-input toggle, resulting signature field with copy button, and a Sign message button](https://beta.taostats.io/images/docs/concepts/taostats-wallet-sign-message-panel.png) Here, the wallet rao has signed the message "I like taostats." To sign this message, the owner has to enter their wallet's password. So only the owner of the wallet can create the signature. ## Decrypting the signature The other party has your wallet address, and the signature. Click the verify tab from the link above. ![Signature verify form with address selector, signed-data field, a signature field showing a green valid checkmark, crypto-type, and hex-input fields](https://beta.taostats.io/images/docs/concepts/taostats-wallet-verify-signature-panel.png) The green checkmark indicates success! Whoever created that signature has possession of the wallet. --- # Chain & runtime Chain & runtime: Chain architecture, Conviction, Extrinsics and events, Yuma Consensus, Commit Reveal 3.0, MEV shield, Node registration, Miner collateral, EVM… _Source: https://beta.taostats.io/docs/concepts/chain-runtime_ _Last reviewed: 2026-09-15_ - [Chain architecture](https://beta.taostats.io/docs/concepts/chain-runtime/chain-architecture) - [Conviction](https://beta.taostats.io/docs/concepts/chain-runtime/conviction-v2) - [Extrinsics and events](https://beta.taostats.io/docs/concepts/chain-runtime/extrinsics-and-events) - [Yuma Consensus](https://beta.taostats.io/docs/concepts/chain-runtime/consensus) - [Commit Reveal 3.0](https://beta.taostats.io/docs/concepts/chain-runtime/commit-reveal-30) - [MEV shield](https://beta.taostats.io/docs/concepts/chain-runtime/mev-shield) - [Node registration](https://beta.taostats.io/docs/concepts/chain-runtime/node-registration) - [Miner collateral](https://beta.taostats.io/docs/concepts/chain-runtime/miner-collateral) - [EVM contracts](https://beta.taostats.io/docs/concepts/chain-runtime/evm-contracts) - [Deploy a dTao chain](https://beta.taostats.io/docs/concepts/chain-runtime/deploy-a-dtao-chain) - [RPC connection to the chain](https://beta.taostats.io/docs/concepts/chain-runtime/rpc-connection-to-the-chain) --- # Chain architecture How does the Bittensor Chain work? _Source: https://beta.taostats.io/docs/concepts/chain-runtime/chain-architecture_ _Last reviewed: 2026-09-15_ How does the Bittensor Chain work? * [Yuma Consensus](https://beta.taostats.io/docs/concepts/chain-runtime/consensus) * [Smart Contracts with EVM](https://beta.taostats.io/docs/concepts/chain-runtime/evm-contracts) * [Commit Reveal 3.0](https://beta.taostats.io/docs/concepts/chain-runtime/commit-reveal-30) * [Parent/Child Hotkeys](https://beta.taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys) * [Extrinsics](https://beta.taostats.io/docs/concepts/chain-runtime/extrinsics-and-events) * [List of all Extrinsics](https://beta.taostats.io/docs/understanding-taostats/extrinsics/list-of-all-extrinsics) * [Multisig extrinsics](https://beta.taostats.io/docs/understanding-taostats/extrinsics/multisig-extrinsics) * [Batch Extrinsics](https://beta.taostats.io/docs/understanding-taostats/extrinsics/batch-extrinsics) * [Deploy a Test Chain (Mac)](https://beta.taostats.io/docs/concepts/chain-runtime/deploy-a-dtao-chain) * [Sign a message with your wallet key](https://beta.taostats.io/docs/concepts/wallets-accounts/sign-a-message-with-your-wallet-key) --- # Conviction Conviction is Bittensor's governance mechanism that ties voting power to long-term commitment. _Source: https://beta.taostats.io/docs/concepts/chain-runtime/conviction-v2_ _Last reviewed: 2026-09-15_ ## 1. What is conviction? Conviction is Bittensor's governance mechanism that ties voting power to long-term commitment. When you lock alpha tokens to a subnet, you earn conviction — a measure of your stake's weight in governance decisions and subnet ownership. Conviction exists to: - Reward long-term alignment over short-term speculation - Provide subnet governance stability - Enable subnet ownership transitions through the **subnet king** mechanism - Create skin-in-the-game for validators and subnet owners Locks are perpetual by default, subnet owners receive instant conviction, and the unlock queue was eliminated in favor of exponential decay. ## 2. How locking works To earn conviction, you lock alpha tokens using the `lock_stake` extrinsic: - **One lock per coldkey per subnet** — You can only have a single active lock targeting one hotkey on each subnet. - **Lock to a hotkey** — Your locked alpha is associated with a specific hotkey on that subnet. This is typically the subnet owner's hotkey, or the hotkey of someone building conviction to challenge for subnet ownership. - **Top-ups must match** — Additional locks to the same subnet must target the same hotkey; you can't split locks across multiple hotkeys. - **Perpetual by default** — Locked mass stays constant indefinitely, allowing conviction to grow toward 100%. - **Optional decay** — Call `set_perpetual_lock(false)` to enable exponential decay if you want to eventually unstake. > [!NOTE] > **Conviction locking and staking are separate — you can do both with the same alpha** > > Conviction locking (via `lock_stake`) and regular [staking](https://beta.taostats.io/docs/concepts/staking/staking-in-dtao) are **different methods** and don't have to point at the same hotkey. You can **lock to the subnet owner's hotkey** to build conviction and show support for the owner, while **staking the same alpha to a different, higher-performing hotkey** (for example, a Taostats validator). That way you maximize your alpha staking rewards *and* keep your conviction directed at the owner. ## 3. Two types of locks ### Perpetual locks (default) When you lock alpha without toggling decay, your lock is perpetual: - `locked_mass` remains constant forever - `conviction` grows exponentially from 0 toward `locked_mass` - Conviction asymptotically approaches 99% after 1 year, 99.9%+ after 2 years - **Cannot unstake** — perpetual locks stay locked unless you toggle to decaying mode ### Decaying locks After calling `set_perpetual_lock(false)`, your lock begins exponential decay: - `locked_mass` decays with `UnlockRate` (158.6 day time constant) - `conviction` follows a coupled decay/growth formula driven by `MaturityRate` (79.3 day time constant) - After 365 days, **90% of locked mass has decayed** (by design) - You can unstake the difference between your original lock and current `locked_mass` ### Subnet-owner locks Subnet owners receive special treatment: - **Instant conviction** — conviction equals `locked_mass` immediately (no growth period) - **Auto-locked owner cut** — The owner's share of emissions is automatically locked each block, building conviction continuously - Owner locks are perpetual by default but can opt into decay ## 4. The numbers ### System parameters | Parameter | Value (blocks) | Value (days) | Meaning | |---|---:|---:|---| | `UnlockRate` | 1,142,108 | 158.6 (τ) | Time constant for locked mass decay. 90% decays in 365 days. | | `MaturityRate` | 571,054 | 79.3 (τ) | Time constant for conviction growth. 2× faster than unlock rate. Half-life: 55 days. | | Half-life (decay) | ~792,000 | 110 | Time for locked mass to decay to 50% (decaying locks only). MaturityRate half-life is 55 days. | ### Conviction growth timeline (perpetual lock) How conviction grows over time when `locked_mass` stays constant: | Days elapsed | Conviction (% of `locked_mass`) | |---:|---:| | 0 | 0.0% | | 30 | 31.5% | | 60 | 53.1% | | 90 | 67.8% | | 120 | 78.0% | | 159 (τ) | 86.5% | | 180 | 89.7% | | 240 | 95.1% | | 365 | 99.0% | ### Locked-mass decay timeline (decaying lock) How `locked_mass` decays after toggling `set_perpetual_lock(false)`: | Days elapsed | Locked mass remaining | |---:|---:| | 0 | 100.0% | | 30 | 82.8% | | 60 | 68.5% | | 90 | 56.7% | | 110 (half-life) | 50.0% | | 120 | 46.9% | | 159 (τ) | 36.8% | | 365 | 10.0% | ## 5. Worked example **Scenario:** a validator locks 10,000 alpha on subnet 64 to their hotkey. ### Phase 1: perpetual lock (default) `locked_mass = 10,000 alpha` (constant) | Time | Conviction | Can unstake | |---|---:|---:| | Day 0 | 0 alpha | 0 alpha | | Day 30 | 3,150 alpha | 0 alpha | | Day 60 | 5,310 alpha | 0 alpha | | Day 90 | 6,780 alpha | 0 alpha | | Day 120 | 7,800 alpha | 0 alpha | | Day 180 | 8,970 alpha | 0 alpha | | Day 365 | 9,900 alpha | 0 alpha | > [!WARNING] > Perpetual locks cannot be unstaked. Locked mass stays at 10,000 alpha forever. ### Phase 2: toggle to decaying At day 365, the validator calls `set_perpetual_lock(false)`. Now both `locked_mass` and `conviction` evolve: | Days since toggle | Locked mass | Conviction | Can unstake | |---:|---:|---:|---:| | 0 | 10,000 | 9,900 | 0 | | 30 | 8,280 | 8,530 | 1,720 | | 60 | 6,850 | 7,280 | 3,150 | | 90 | 5,670 | 6,160 | 4,330 | | 120 | 4,690 | 5,180 | 5,310 | | 159 (τ) | 3,680 | 4,090 | 6,320 | | 365 | 1,000 | 1,090 | 9,000 | Unstakeable amount = original lock (10,000) − current `locked_mass`. After 1 year of decay, the validator can unstake 9,000 alpha, leaving 1,000 still locked. ## 6. Subnet-owner locks Subnet owners accumulate locked alpha automatically and receive immediate conviction: - **Owner cut auto-locked:** Each block, the owner's emissions share is locked to their subnet ownership hotkey. - **No initial alpha distribution:** Subnet registration does not distribute initial alpha to the owner. Conviction builds solely through the auto-locked owner cut from ongoing emissions. - **Instant conviction:** Unlike validators, owners don't wait for conviction to grow — `conviction = locked_mass` immediately. - **Perpetual by default:** Owner locks don't decay unless the owner explicitly calls `set_perpetual_lock(false)`. - **Aggregate tracking:** All owner locks on a subnet are aggregated into `OwnerLock` storage for subnet king calculations. This instant conviction ensures subnet owners always have governance weight proportional to their locked stake without waiting periods. ## 7. Subnet king mechanism After a subnet has been active for 1 year (365.25 days), ownership can transfer via the **subnet king** mechanism. ### Eligibility requirements - Subnet must be at least 365.25 days old. - A **single hotkey's own rolled aggregate conviction** must exceed **18% of eligible alpha**, where eligible alpha = `SubnetAlphaOut − SubnetProtocolAlpha − AlphaBurned`. The subtraction saturates at zero, so a subnet with zero eligible alpha can never transfer ownership. The bar is measured on the winning hotkey alone — the subnet-wide total no longer counts, so other keys' locks (including the incumbent owner's) do not add to a challenger's threshold. - The hotkey with the highest aggregate conviction is the candidate, and that same hotkey must clear the 18% bar by itself. Conviction is aggregated per hotkey (from all coldkeys locking to that hotkey), not per coldkey. > [!NOTE] > **Reading eligible alpha from the API** > > You don't have to compute `SubnetAlphaOut − SubnetProtocolAlpha − AlphaBurned` yourself. The Taostats [dTAO pool](https://beta.taostats.io/docs/api-reference) endpoint exposes this exact quantity as the **`alpha_staked`** field (`GET /api/dtao/pool/latest/v1?netuid=`). To check how close a subnet is to a takeover, compare a hotkey's rolled conviction against `0.18 × alpha_staked`. > [!NOTE] > **Changed in runtime spec 447** > > Before spec 447, ownership transferred once the **subnet-wide total** rolled conviction (all hotkeys and coldkeys combined, including the owner) reached **10% of eligible alpha**. Spec 447 replaced that with an **18% bar on a single hotkey's own conviction**. Summing across all lockers let unrelated stakers — the incumbent owner included — inadvertently supply a challenger's quorum; gating on the winner's own conviction closes that path. Coalitions still work because backers lock directly to the challenger's hotkey, so their conviction lands in that hotkey's aggregate. ### How it works 1. **Aggregate calculation:** For each hotkey, the system sums rolled conviction across all locks targeting it — `HotkeyLock + DecayingHotkeyLock + OwnerLock` (and the decaying owner lock) — via a single shared computation (`subnet_king_with_conviction`), so selection and the admission gate can never disagree. 2. **Comparison:** The hotkey with the highest aggregate conviction is the subnet king candidate. Ownership transfers only if **that hotkey's own conviction exceeds 18% of eligible alpha** — the subnet-wide sum is not used. The comparison is cross-multiplied in 256-bit integers so high-range takeovers can't saturate. 3. **Transfer:** Ownership transfers, and the lock aggregates swap: - Old owner's `OwnerLock` → becomes non-owner locks - New owner's non-owner locks → become `OwnerLock` 4. **Instant conviction retained:** The new owner keeps their conviction value but now has instant-conviction status for future locks. **Design rationale:** This mechanism prevents permanent ownership monopolies while requiring challengers to demonstrate long-term commitment through locked alpha and conviction growth. ## 8. What you can and can't do ### ✅ Allowed actions - **Top up existing lock:** Add more alpha to your existing lock (must target the same hotkey). - **Move lock to a different hotkey:** You can move your lock to a different hotkey on the same subnet. If the destination hotkey is owned by the same coldkey, conviction is preserved. If owned by a different coldkey, conviction resets to zero. - **Toggle decay mode:** Switch between perpetual and decaying at any time with `set_perpetual_lock`. - **Partial unstaking (decaying only):** Unstake the difference between original lock and current `locked_mass`. ### ❌ Not allowed - **Unstake perpetual locks:** You must first toggle to decaying mode and wait for mass to decay. - **Cross-subnet transfers:** Locks are subnet-specific and cannot be moved between subnets. - **Multi-hotkey locks:** You cannot have multiple locks to different hotkeys on the same subnet from one coldkey. - **Lock hotkey changes:** If you have an active lock on a subnet, you can't lock to a different hotkey without first removing the existing lock. - **Coldkey swap with active locks on destination:** A coldkey swap requires the destination coldkey to have no active locks. The source coldkey's locks transfer to the destination, but only if the destination is clean. ## 9. Technical reference ### Storage maps | Storage | Key | Value | Purpose | |---|---|---|---| | `Lock` | (coldkey, netuid) | `LockState` | Legacy/compatibility — tracks basic lock state | | `HotkeyLock(netuid, hotkey)` | (coldkey, netuid, hotkey) | `LockState` | Aggregate conviction from all perpetual (non-decaying) non-owner coldkeys locking to this hotkey on this subnet | | `DecayingHotkeyLock(netuid, hotkey)` | (coldkey, netuid, hotkey) | `LockState` | Aggregate conviction from all decaying non-owner coldkeys locking to this hotkey on this subnet | | `OwnerLock(netuid)` | (coldkey, netuid) | `LockState` | Aggregate conviction for the subnet owner coldkey's lock on this subnet | | `DecayingLock(coldkey, netuid)` | (coldkey, netuid) | `LockState` | Per-coldkey flag: when present, that coldkey's lock decays. Missing = perpetual. | ### `LockState` structure ```rust LockState { locked_mass: u64, // Current locked alpha (decays if non-perpetual) conviction: u64, // Governance weight (grows/decays based on mode) last_update: u64 // Block number of last state update } ``` ### Roll-forward formula When reading lock state, the system rolls forward from `last_update` to the current block. With `dt = current_block − last_update` blocks elapsed, the decay factors and coupling term are: $$ decay_x = e^{-dt / UnlockRate} = e^{-dt / 1{,}142{,}108} $$ $$ decay_z = e^{-dt / MaturityRate} = e^{-dt / 571{,}054} $$ $$ \gamma = UnlockRate \times \dfrac{decay_x - decay_z}{UnlockRate - MaturityRate} $$ The locked mass either holds (perpetual locks) or decays: $$ locked\_mass_{new} = \begin{cases} locked\_mass_{old} & \text{if perpetual (no decay)} \\ locked\_mass_{old} \times decay_x & \text{otherwise} \end{cases} $$ $$ conviction_{new} = decay_z \times conviction_{old} + \gamma \times locked\_mass_{old} $$ For subnet owners with instant conviction, the formula simplifies to `conviction = locked_mass` (no roll-forward needed for conviction growth). ### Key extrinsics - `lock_stake(hotkey, netuid, amount)` — Lock alpha to a hotkey on a subnet (perpetual by default). - `set_perpetual_lock(netuid, perpetual: bool)` — Toggle between perpetual (`true`) and decaying (`false`) mode. --- # Extrinsics and events Extrinsics are how commands are written to the chain. _Source: https://beta.taostats.io/docs/concepts/chain-runtime/extrinsics-and-events_ _Last reviewed: 2026-09-15_ Extrinsics are how commands are written to the chain. The Bittensor chain is substrate based. Each block on the blockchain is written with events and extrinsics that occurred during the 12 seconds that the block was being produced. ## Extrinsics Extrinsics are groupings of events that occur together. ## Events Events are node/subnet registrations, tao trades, delegations, and distributions. Not all events are inside extrinsics. --- # Yuma Consensus The Yuma consensus mechanism _Source: https://beta.taostats.io/docs/concepts/chain-runtime/consensus_ _Last reviewed: 2026-09-15_ The Yuma consensus mechanism The Yuma Consensus algorithm translates weights into emissions. ## Neuron Rewards Mechanism Validators test the output of miners, and grade the results as weights. These weights are passed to Yuma Consensus. The Yuma Consensus algorithm translates weights into incentives for the subnet miners and dividends for the subnet validators. The Yuma Consensus rewards subnet validators with dividends for producing miner-value evaluations that are in agreement with the subjective evaluations produced by other subnet validators, weighted by stake. The results of the subnet consensus are written to the blockchain to facilitate trustless rewards distribution. ## Checks and Balances While setting the emissions for participants of the network, the algorithm also checks for Consensus. If the weights placed by a validator are not "in consensus" or similar to the other scores submitted by other validators, the results are given less "weight." This works as a check against bad actor validators who might try to manipulate the system for their own gain. ### TL;dr: If all the validators agree that a miner is doing a good job - they get a higher reward (incentive). The more that the validators agree on miner performance - the higher their rewards. ### Examples * **Miner** Validator `SuperTao` has 10 miners running in Subnet 85. The validator gives these miners extremely high scores, and very low scores to the remaining miners - a drastic difference from the other validators. The weights placed by `SuperTao` will be largely ignored by the Yuma Consensus engine. Also, the VTrust score for `SuperTao` will be lowered — directly affecting the Dividends and emission awarded to the Validator. [Bittensor TAO - Yuma Consensus and VTrust](https://www.youtube.com/watch?v=FT0gL4MXgMM) --- # Commit Reveal 3.0 Designed to stop weight copying: weights are committed to the chain, but revealed several epochs later. _Source: https://beta.taostats.io/docs/concepts/chain-runtime/commit-reveal-30_ _Last reviewed: 2026-09-15_ Designed to stop weight copying: weights are committed to the chain, but revealed several epochs later. Commit Reveal 3.0 launched in December 2024. ## What is Commit Reveal? Commit Reveal is designed to stop weight copying validators. See [Weight Copying](https://beta.taostats.io/docs/concepts/validators/weight-copying) For subnets that support Commit Reveal, all weights submitted by validators will be encrypted for a number of epochs. The weights will only be revealed and used for Yuma Consensus upon decryption. If a validator is weight copying, the are only able to access stale data. This will lower their score, making weight copying less lucrative. ## Setting Up Commit Reveal Subnet owners have two new Subnet Hyperparameters: ```shell commit_reveal_weights_interval 1 1 commit_reveal_weights_enabled False False ``` Enabling and setting the number of intervals will turn on Commit Reveal for the subnet. Interval denotes the number of tempos until the weights will be revealed. If set to 3, the weights will be revealed in three tempos, at the start of the tempo. ## Setting Weights Validators do nothing different post Commit Reveal. The chain nodes establish if Commit Reveal is turned on. If CR is on, the submitted weights are time-lock encrypted (using drand/tlock) and the encrypted commit is placed on chain. The encryption is bound to a future round, so the weights automatically become decryptable once the reveal interval (`commit_reveal_weights_interval` epochs) has elapsed — there is no hash-compare step; the chain simply decrypts and applies them at that point. ## Miner ramifications If you make changes to your miner, the resulting scores will be delayed by several epochs: ### New Miner Epoch 1: Start a miner, evaluated by all the miners. Epoch 2: Validators place initial weights Epoch 2 + `commit_reveal_weights_interval`: your initial weight appears. ### Miner crashes Epoch x: Miner crashes. Stops responding to validator requests Epoch x+1: Validators begin lowering your score (intervening epochs - scores continue to drop precipitously) Epoch x+1+ `commit_reveal_weights_interval`: you start seeing dropped scores Miners should not be using validator scores to determine if their miners are active. With Commit Reveal, deregistration is almost guaranteed. --- # MEV shield why do we need mev shield, and how does it work? _Source: https://beta.taostats.io/docs/concepts/chain-runtime/mev-shield_ _Last reviewed: 2026-09-15_ why do we need mev shield, and how does it work? ## MEVbots explained Maximum Extractable Value (MEV) bots scan the chain and look for transactions to "steal" assets from. There have been a number of approaches to hinder these Bots from operating on chain. When a transaction moves through a liquidity pool, there is an opportunity for slippage: where another transaction precedes your transaction, changing the price and affecting the amount of tao/alpha you receive. > [!NOTE] > Example > > An isolated transaction will have a small price impact due to the liquidity pool > > ![Diagram of a single token swap through an AMM subnet pool, with input tau, pool tau/alpha reserves, output alpha, and a resulting price-impact percentage](https://beta.taostats.io/images/docs/concepts/taostats-mev-swap-price-impact-diagram.png) > > But a large transaction in front of this one adds slippage: > > ![Diagram decomposing an AMM swap's adverse execution into price impact plus slippage caused by a large front-running transaction](https://beta.taostats.io/images/docs/concepts/taostats-mev-slippage-frontrun-diagram.png) > > In this example, 4% of the transaction is lost to slippage. > > This is what the MEV bots do. ## First fix: Limits All transactions should set a slippage limit. This means - "hey, the price is x, and I am ok with a change of y% for the transaction." The slippage limit should be small - a 4% slippage limit in the example above cost 20 alpha (\~ 2 tao). For high liquidity subnets, you can be well below 1%. ### The MEV bots calculate their MAX extraction on every transaction f your limit is very loose - the bot may decide to attack your transaction. If you have no limit set: The MEV bots can extract as much as they want. ![Dark-themed transaction log table with buy/sell pills, entity, alpha amount, tao value, per-unit price, percentage, and truncated wallet address columns](https://beta.taostats.io/images/docs/concepts/taostats-mev-transaction-log-table.png) ## MEVShield While a tight limit price on your transfer should be enough to stop MevBots, the chain has also launched MevShield. Currently in version 1.0: Mevshield encrypts your transfer, so that the MEVbot cannot read the details. ON the next block, your transaction is decrypted and processed. ### Advantages: By encrypting the transaction, the MEVBot cannot see what you have done, and therefore cannot schedule a transaction in front of your trade. ### Disadvantages Each transaction using MEVShield must be signed twice: * Sign the transaction * sign the encryption wrapper. Taostats (and other providers) now offers the ability to sign the encryption wrapper to save double password entry. ![Transaction confirmation panel with two checkboxes for enabling MEV shield protection and delegating submission, plus a Confirm button](https://beta.taostats.io/images/docs/concepts/taostats-mev-shield-confirm-dialog.png) MevShield 2.0 is in development with more enhancements. ### Why does Taostats disable MevShield for transactions `<1` tao? For transactions `<1` tao, you are not likely going to be mevved - the potential gain for the attackers is too small compared to the risk. ### Why does taostats disable MevShield for root stakes? Root staking has no price impact or slippage you cannot be mevved on a root transaction - so no need for 2 signatures. --- # Node registration Neurons are server nodes in each subnet. _Source: https://beta.taostats.io/docs/concepts/chain-runtime/node-registration_ _Last reviewed: 2026-09-15_ Neurons are server nodes in each subnet. To become a validator or miner on a subnet you must register a neuron. ## Neuron Registration To obtain a UID (unique slot number for a neuron) on a particular subnet you must register your hotkey. The cost of the slot is variable and can be found using the command line `btcli subnets list`. The **recycle** cost is the cost to register a neuron). The recycle cost decays smoothly each block, ensuring the price halves from the last registration cost every half life blocks. At each registration the recycle cost is increased by a multiplier Burn Increase Multiplier (clamped between limits). It is possible to register multiple neurons per block This allows the registration costs to be defined by natural market forces of demand. A historical chart is available on the subnet's page on Taostats to see the current costs for each subnet: ![URL format: https://taostats.io/subnets/netuid-18/#registration](https://beta.taostats.io/images/docs/concepts/de952272-Screenshot_2024-09-03_at_17.40.57.jpg) All new miners & validators are placed into [immunity](https://beta.taostats.io/docs/start-here/glossary#immunity) for a preset amount of time. The immunity period can be adjusted per subnet. A miner with immunity cannot be de-registered. > [!NOTE] > **Immunity period** > > To retrieve the immunity period (in blocks), you can use the [Bittensor CLI](https://beta.taostats.io/docs/concepts/command-line-tool) to select a Subnet. The output includes the immunity\_period. For subnet 1, it is 7200 blocks: > > ``` > btcli sudo get > Enter netuid [0/1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32] (0): 1 > Bittensor Version: Current 6.6.0/Latest 6.7.0 > Please update to the latest version at your earliest convenience. Run the following command to upgrade: > > python -m pip install --upgrade bittensor > Subnet Hyperparameters - NETUID: 1 - finney > HYPERPARAMETER VALUE > rho 10 > kappa 32767 > immunity_period 7200 > min_allowed_weights 8 > max_weight_limit 455 > tempo 99 > min_difficulty 1000000000000000000 > max_difficulty 1000000000000000000 > weights_version 10000 > weights_rate_limit 100 > adjustment_interval 112 > activity_cutoff 5000 > registration_allowed True > target_regs_per_interval 2 > min_burn 50000000 > max_burn 100000000000 > bonds_moving_avg 900000 > max_regs_per_block 1 > serving_rate_limit 10 > max_validators 128 > ``` ### Recycling of Fees Any tao spent on registration is converted into alpha and [recycled](https://beta.taostats.io/docs/concepts/tokenomics/recycling) - it is returned to the unissued supply (thus slowly lengthening the time until the next halvening). The tao recycled for registration is NOT returned to the miner upon de-registration and is considered part of the operational costs to be factored into the profitability calculations when mining. > [!NOTE] > **Some subnets add a collateral lock on top of the recycle** > > On subnets that enable **miner collateral**, the registration cost is *split*: the recycled share behaves exactly as above (converted to alpha, removed from supply), but a second share — set by the subnet's `CollateralLockShare` (up to 95%) — is staked to your hotkey and **frozen as a bond** instead of being burned. You recover that locked alpha only by earning emission (it drains back to free stake as you mine), or if the subnet dissolves. It is off by default and opt-in per subnet, so most registrations are recycle-only — but if you register on a collateral subnet, budget for the extra locked capital. See [Miner collateral](https://beta.taostats.io/docs/concepts/chain-runtime/miner-collateral) for the full mechanics. ## Neuron De-registration When a new miner/validator registers their hotkey, the neuron/node with the lowest emissions ranking in the subnet is de-registered. > [!NOTE] > **Miners & validators that have immunity cannot be de-registered.** If your subnet is deregistered for a new subnet, all neurons are de-registered. --- # Miner collateral Miner collateral is a refundable-by-work registration bond for Bittensor subnets. _Source: https://beta.taostats.io/docs/concepts/chain-runtime/miner-collateral_ _Last reviewed: 2026-09-15_ Miner collateral is a refundable-by-work registration bond for Bittensor subnets. Part of your registration fee stops being recycled and instead becomes locked stake you can only recover by earning emission — or by the subnet dissolving. It is **live on Finney mainnet at spec 437**. > [!NOTE] > **The one-line version** > > It's a security deposit. A subnet can force part of your registration cost to be staked and frozen as collateral. You get it back slowly as you do validated work — and if you walk away without mining, it sits frozen on your hotkey, earning nothing. ## Is it on? Off by default Miner collateral is **opt-in per subnet, and off everywhere until a subnet switches it on**. The controlling hyperparameter `CollateralLockShare` (**p**) defaults to `0`, and at `p = 0` there is no collateral at all — the entire registration price is recycled exactly as it was before the feature existed. A subnet activates it by setting `p > 0` via `sudo_set_collateral_lock_share`, callable only by the subnet owner or root. - **Optional for the subnet** — the owner chooses whether to enable it, and at what strength (`p` up to 95%). - **Mandatory for the miner** — once your subnet runs `p > 0`, every registration on it is split and bonded automatically. There is no per-miner opt-out at registration; if you register, you post the bond. - **Not retroactive** — turning `p` on (or changing it) affects future registrations only; standing collateral is never re-priced. Everything below describes a subnet that has enabled it. On a subnet with `p = 0`, none of it applies — you just pay the normal burn. ## Why it exists Registration on a busy subnet already costs real TAO — but by default 100% of that cost is recycled (swapped to alpha, and that alpha removed from supply; the chain labels this the "burn"). Once you're registered, the value is gone to you whether you mine honestly or squat the slot doing nothing. Miner collateral changes the incentive: a subnet owner can redirect part of the registration cost away from the burn and into a locked bond on your own hotkey. Now you have skin in the game. Mine well and the bond flows back to you. Spam-register or go idle and your capital is stuck. It's an anti-spam / commitment mechanism, tuned per subnet. > [!WARNING] > **Misconception to kill first** > > "Registration is cheap (0.001 TAO), so collateral is trivial." Not on collateral subnets. The 0.001 figure is the floor on idle subnets. A subnet that wants collateral deliberately runs a higher registration price and then splits it — that's the whole point. The feature targets those subnets, not the cheap ones. ## The split: burn vs lock Each subnet sets a hyperparameter **p** (`CollateralLockShare`), a fraction from `0` to `0.95`. Your registration cost splits by that ratio: ``` registration cost └─ ALL of it → swap TAO → alpha (into the subnet's pool) ├─ p → stake to your hotkey → LOCK └─ (1 − p) → alpha removed from supply (the "burn") ``` > [!NOTE] > The `(1 − p)` share is often called the "burn," but it's a recycle, and the chain uses that word literally. Your whole payment is swapped TAO → alpha. Two things then happen to the `(1 − p)` share: its TAO stays in the subnet and is tallied in `RAORecycledForRegistration` (the chain's recycled-TAO counter), and the alpha it bought is decremented from `SubnetAlphaOut` — removed from circulating alpha supply. It is not a TAO burn; nothing is destroyed at the TAO level. So it's your registration money that gets locked — not extra money on top. Two things to internalise: - **It's locked as alpha, not TAO.** Your `p` share buys the subnet's alpha token at its moving-average price (with a 5% slippage cap on the buy), and it's the alpha that's locked. Its TAO value floats afterward. - **The "burn" share is always positive.** `p` is capped at 95% (`MaxCollateralLockShare`) so a registration always recycles something — you can never lock 100%. ### Worked example Subnet sets reg cost = 2 TAO at the maximum `p = 0.95`, alpha price = 0.1: | Component | Amount | Fate | |---|---|---| | "Burned" `(1 − p)` | 0.1 TAO | recycled (alpha removed from supply) | | Locked `p` | 1.9 TAO → 19 alpha | frozen on your hotkey | Change the dials and you change the bond: `p = 0.5` on the same 2 TAO reg → burn 1 / lock 1. Note the cap makes a big bond need a big reg cost: to lock ~1 TAO you need reg ≥ ~1.05 TAO, since at most 95% of it can be locked. ## How the lock comes back: drain, not decay The lock does **not** decay on a clock. Sit idle for a year and it's exactly where you left it. The only thing that reduces it is earned emission, settled each tempo: $$ release\_this\_tempo = \min\!\left(k \times emission\_earned,\ locked - min\_locked\right) $$ - **k** = `CollateralDrainRatio` — the per-subnet unlock rate. Default `1.0` (one alpha released per alpha of emission earned), settable up to `10.0`. - Each tempo you earn emission, `k × emission` of alpha unlocks back to your free stake, where you can unstake or transfer it normally. - `k` is snapshotted onto your position at registration. If the owner changes `k` mid-life, your existing bond keeps its original rate — only your next re-registration re-prices it. > [!NOTE] > **Is emission locked? No — it's the opposite** > > A common misread: "does the feature lock my incentive?" No. Your emission pays out normally — and it's the key that unlocks your collateral. Earning emission drains your bond down. The only exception is the floor mechanic below. The drain settles against **full hotkey emission** — miner incentive *and* validator dividends — releasing the lock at rate `k`. ### The optional floor (`min_locked`) A miner can set a floor (`do_set_min_collateral`) — e.g. to track a per-machine deposit a subnet's validators publish. The lock self-maintains around it: - **Above the floor:** emission drains the lock down toward the floor (and stops there). - **Below the floor (you're deficient):** emission is captured — withheld from you and pushed back into the lock — until the floor is restored. This is the only path where emission doesn't reach your wallet. The chain also tracks `earned` — cumulative lifetime emission per collateral entry — so validators can compare a miner's extraction against the bond still at risk. ## A separate lock from conviction — they stack > [!WARNING] > **Miner collateral is NOT a conviction lock** > > These are two completely independent locks with different storage, purpose, and exit rules. A single stake position can carry both at once, and they stack: when you try to unstake, the chain subtracts both the miner collateral and the conviction lock, and only what's left over is movable. The two behave in opposite ways on the point that matters most — getting your locked stake out. Miner collateral has no transfer exit at all, where [conviction](https://beta.taostats.io/docs/concepts/chain-runtime/conviction-v2) does: | | Conviction lock | Miner collateral | |---|---|---| | Purpose | Voluntary — boost stake weight | Forced — registration bond | | Storage | `Locks` | `MinerCollateral` | | Unstake locked amount | blocked up to lock | blocked up to lock | | Transfer stake | follows the stake (recipient must accept) | blocked — stays on origin | | Hotkey swap | permitted | bond follows the UID via `keep_stake=false`; abandoning the lock (`keep_stake=true`) is refused with `KeepStakeBlockedByCollateral` | | Only exit | time unlock + transfer | earned emission (or subnet dissolution) — a key swap moves the bond, it does not release it | On the hotkey-swap row: a hotkey swap takes a `keep_stake` flag. With `keep_stake=false` the UID and its bonded stake move together to the new hotkey — the collateral follows the UID, and a per-subnet lineage record (`HotkeySuccessor` / `HotkeyRoot`) ties old and new keys to one identity so the bond stays attributable. Only `keep_stake=true` — which would strand the lock on the dead old hotkey while the UID walks off — is refused, with `KeepStakeBlockedByCollateral`. So the bond can't be abandoned by renaming keys, but it is not immovable: it travels with a full swap. > [!NOTE] > **Can I stake the frozen alpha to a validator for yield?** > > No. It's welded to the `(netuid, hotkey, coldkey)` position that registered — you can't move it to a validator hotkey. And on your own miner hotkey it earns no passive APY: miner hotkeys only earn incentive for scored work, not dividends. While it's frozen and you're not actively mining, it earns nothing. It is inert, illiquid capital until you mine it free. ## Deregistration & re-registration Getting pruned (neuron deregistration) does not sell or clear your alpha — it only frees your UID slot. Your staked alpha and its lock stay in place. On re-registration, the standing lock is valued at the moving-average price and credited against the new requirement, so you pay only the shortfall. ### Three re-registration cases (same 19 locked alpha, 1.9 TAO requirement) | Scenario | Requirement (1.9 TAO) | You pay | |---|---|---| | Price still 0.1 | 19 alpha = 1.9 TAO → covered | just the ~0.1 burn | | Price rises to 0.2 | 19 alpha = 3.8 TAO → over-covered | just the ~0.1 burn (excess drains out as you mine) | | Price drops to 0.05 | 19 alpha = 0.95 TAO → short 0.95 | buy ~19 more alpha (0.95 TAO) + 0.1 burn | > [!WARNING] > **Fill-or-kill top-up trap** > > The top-up buy is bounded at spot × 1.05 (5% slippage cap). If your top-up would push the pool more than 5% above spot, the whole re-registration reverts — no partial fill. On a thin subnet with a big top-up, add collateral in smaller chunks first (`do_add_collateral`) before re-registering. ## Is it ever truly lost? "Burned forever" is wrong — the collateral is never destroyed (only the small `(1 − p)` burn share is). But "stuck indefinitely" is right in the walk-away case. | What happens | Your collateral | |---|---| | You mine, then stop | drained back to free stake as you earned — mostly recovered | | You re-register that hotkey later | credited against the requirement — reusable | | Subnet is dissolved | all alpha (locked + free) pro-rata converted to free TAO and returned to your coldkey; the lock rows are wiped | | You quit, never mine, never re-reg, subnet lives on | frozen indefinitely — still yours, but non-earning & illiquid | | Value recycled (not returned) | only the `(1 − p)` registration share — swapped to alpha, alpha removed from supply (the "burn") | > [!NOTE] > **Subnet dissolution refunds you** > > On dissolution the chain runs a settlement that values every staker's alpha — collateral included — and pays it out as free TAO to the coldkey, then clears the `MinerCollateral` rows as dead metadata. So on subnet death, you get your money back. The realistic verdict: for a live subnet you walk away from, the collateral is "lost for the foreseeable future" — not burned, not lost to the chain, still your alpha, but frozen, non-earning, and unmovable until you mine it down or re-register. The real cost is opportunity cost, plus alpha-price drift: you get your alpha back, not your TAO. If alpha craters while locked, so does the value you recover. ## What this changes for reading stake: available ≠ total Miner collateral makes a position's displayed stake diverge from its spendable stake. Anyone reading a stake balance on a collateral subnet will overstate liquidity unless collateral is subtracted. | Concept | Source | Meaning | |---|---|---| | Total stake | existing stake storage | what shows on the position today | | Locked collateral | `MinerCollateral (netuid, hotkey, coldkey)` | frozen — can't unstake or transfer; a hotkey swap moves it with the UID but never releases it | | Available | `stake − collateral − conviction lock` | what's actually movable | The chain computes this internally (`available_to_unstake_from_hotkey` does `stake − collateral`, stacking with conviction locks). Storage and events to read: `MinerCollateral`, `ColdkeyMinerCollateral`, `CollateralLockShare` (p), `CollateralDrainRatio` (k); events `CollateralLocked`, `CollateralLockShareSet`, `MinCollateralSet`; plus lineage (`ColdkeyCollateralHotkeys`, `HotkeySuccessor` / `HotkeyRoot`, `ColdkeySuccessor` / `ColdkeyRoot`). ## Who controls the dials | Knob | Set by | Bounds | Notes | |---|---|---|---| | **p** — lock share | root or subnet owner | 0 – 0.95 | future registrations only; standing collateral never re-priced | | **k** — drain ratio | root or subnet owner | >0 – 10.0 (default 1.0) | snapshotted per position at registration | | `min_locked` — floor | the miner (own hotkey) | ≥ 0 (0 = off) | drain stops at floor; emission refills below it | | top-up | the miner | — | `do_add_collateral`; prefers free staked alpha, buys the shortfall; keeps drain snapshot | ## The whole thing in 8 lines 1. A subnet sets **p**: your registration cost splits into a recycled share `(1 − p)` and a locked share `p`. 2. The locked share buys alpha, stakes it to your hotkey, and freezes it as collateral. 3. You recover it by earning emission: the drain settles against **full hotkey emission** — miner incentive and validator dividends — releasing the lock back to free stake at rate `k`. 4. It doesn't decay on a clock — no work, no unlock. 5. You can't transfer or unstake it; a hotkey swap carries the bond to the new key (via `keep_stake=false` + lineage) but can't abandon it — and it earns no passive APY. 6. Dereg keeps it; re-registration credits it against the new requirement. 7. Subnet dissolution refunds it as free TAO. It's never destroyed — only the `(1 − p)` share is recycled. 8. When reading a balance: track `available = total − collateral − conviction lock`, or balances will read too high. > [!NOTE] > **See also** > > This mechanic first landed as a tracked runtime change — see the [Miner collateral protocol-change page](https://beta.taostats.io/docs/concepts/protocol-changes/miner-collateral) for the release-train history and source PRs. For how it interacts with the base registration flow, see [Neuron registration](https://beta.taostats.io/docs/concepts/chain-runtime/node-registration). --- # EVM contracts Smart contract evaluation has launched on Bittensor. _Source: https://beta.taostats.io/docs/concepts/chain-runtime/evm-contracts_ _Last reviewed: 2026-09-15_ Smart contract evaluation has launched on Bittensor. ## Smart Contracts Smart contracts are agreements that are codified in code. When two (or more) parties wish to execute a smart contract, they agree on the terms, and write those terms into code - the smart contract. Upon completion of the smart contract provisions, the contract is executed. ## EVM - Ethereum Virtual Machine EVM is used to execute smart contracts. Generally, this is done on the ethereum blockchain, but in the case of Bittensor, these are run solely on the Bittensor subtensor chain. It allows developers to write and deploy smart contracts in programming languages like Solidity. It should be noted that EVM is not native to substrate blockchains (like Bittensor.). To enable EVM and smart contracts to be run on Bittensor, an EVM implementation was added. Once you have created and compiled a smart contract, it must be deployed on the Bittensor (subtensor) EVM. Once a contract is deployed on the subtensor, any user can call and interact with the contract. ## Executing a Smart Contract on Bittensor A standard Bittensor wallet (your coldkey) is unable to execute smart contracts. Your coldkey wallet is controlled on the Bittensor side of the network (you have your password and 12 word mnemonic of the Bittensor chain). In order to create a smart contract, you must have an EVM Bittensor wallet. ### Create a Bittensor MetaMask coldkey wallet Inside the MetaMask browser extension, create a new account. Add a network manually: ``` Network name: "Subtensor" New RPC URL: https://rpc.blockmachine.io Chain ID: 964 Currency symbol: TAO ``` ## EVM wallet/ Substrate wallet interactions With a EVM MetaMask wallet - you can execute smart contracts. Your EVM wallet has no functionality on the Bittensor network (it cannot transfer funds, stake, etc.) Your Bittensor wallet cannot execute smart contracts. So how do these two types of wallets interact? ### EVM wallets on Bittensor Your EVM wallet (in Metamask) can execute smart contracts. It has an alias address in Bittensor that can receive funds from "regular" Substrate wallets. This bittensor 'alias' has no password on the Bittensor side, and cannot be used for any transactions on the Bittensor chain. Any funds that are transferred into the alias immediately appear in the EVM wallet. ![Bittensor wallet (orange) & EVM wallet (yellow) The EVM wallet has a Bittensor alias for receiving funds. These will immediately appear in the EVM wallet.](https://beta.taostats.io/images/docs/concepts/f3abfc30-image.png) #### Bittensor wallets on EVM In a similar way, Bittensor wallets have an alias address on EVM that can receive funds. This EVM 'alias' has no password and cannot be used to execute smart contracts on EVM, but can receive transfers or the execution of smart contracts. ![EVM wallet (yellow) can transfer funds to the Bittensor wallet alias. This appears in the Bittensor wallet immediately.](https://beta.taostats.io/images/docs/concepts/6ab81720-image.png) ![EVM wallet executes a smart contract, and the Bittensor wallet's alias receives the funds as a result of the execution.](https://beta.taostats.io/images/docs/concepts/3db4f59d-image.png) > [!NOTE] > **1 tao = 1e18 in Bittensor EVM.** > > Due to the precision of token in EVM, 1 tao is written as (1 billion)^2. ## Creating and executing Smart Contracts the Opentensor Foundation has up to date guides on running smart contracts on Bittensor: [https://docs.bittensor.com/evm-tutorials/](https://docs.bittensor.com/evm-tutorials/) ## Contract verification (from our friends at [Taonado](https://github.com/taonado/taonado-cash/blob/main/verify-contract.md) To verify the source code for a deployed contract on the taostats evm explorer. See hardhat.config.ts for configuration. This does not require a valid config.ts setup with keys etc.. `pnpm hardhat verify --network taostats 0xDEPLOYED_CONTRACT_ADDRESS "CONSTRUCTOR_PARAM_0" "CONSTRUCTOR_PARAM_1"` If you run into issues verifying, it is likely an issue with the `@openzeppelin/hardhat-upgrades` package changes to how contracts are tested before verified. There is a compatibility issue with Blockscout. In particular, [HardhatError HH110](https://v2.hardhat.org/hardhat-runner/docs/errors#HH110) : Invalid JSON-RPC response is possible with error: "Action not found." To fix this, you have to temporarily uninitialize the @openzeppelin/hardhat-upgrades package for the purposes of verifying any contract, which will run the expected verify method which works with Blockscout's RPC. Root cause is the @openzeppelin/hardhat-upgrades package checks if the address isBeacon by trying to get the implementation() address which the Blockscout eth-RPC returns an error message different than what is expected by the lib, so it incorrectly assumes there is an RPC issue. --- # Deploy the Subtensor The Bittensor subtensor code can be found on GitHub: https://github.com/opentensor/subtensor/ _Source: https://beta.taostats.io/docs/concepts/chain-runtime/deploy-a-dtao-chain_ _Last reviewed: 2026-09-15_ The Bittensor subtensor code can be found on GitHub: [https://github.com/opentensor/subtensor/](https://github.com/opentensor/subtensor/) Clone this repository locally, and switch to the dynamic branch: ```shell git clone git@github.com:opentensor/subtensor.git cd subtensor git fetch origin rao git checkout rao ``` Now we'll get the Subtensor up and running.. For installation you need rosetta. We'll also use Homebrew to install OpenSSL. (these instructions are from the GitHub Readme - so if you are in a different OS, check that out and work through the steps). ```shell softwareupdate --install-rosetta # Install Homebrew if necessary https://brew.sh/ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" # Make sure Homebrew is up-to-date, install openssl brew update brew install openssl ``` Now we need to install Rust. Again there's a link on the GitHub repo for those of you on different OS. ```shell # Install curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh # Configure source ~/.cargo/env #rust configuration rustup default stable rustup update rustup update nightly rustup target add wasm32-unknown-unknown --toolchain nightly ``` ### Config changes 1. Update the `scripts/localnet.sh` on line 34. In testing, raonet does not work with fastblocks. (this may change before launch). We want to have the pow-faucet to distribute tao to our wallets. ``` : "${FEATURES:=" pow-faucet raonet runtime-benchmarks"}" ``` 2. Increase the faucet amount (if desired). Add a few more zeros to this value to ensure that you have enough test tao.`https://github.com/opentensor/subtensor/blob/58c1f51cc9f0716545fbf99c10c8d761d19dd472/pallets/subtensor/src/subnets/registration.rs#L397` ``` let balance_to_add: u64 = 1_000_000_000_000; ``` ## build OK - everything is installed for the subtensor, so we can build and run it: ```shell cargo build sh scripts/localnet.sh ``` Your subtensor is now running. > [!NOTE] > **Calling the subtensor** > > When working with your local chain, add the > > `--subtensor.network local` or `--subtensor.network ws://127.0.0.1:9946` > > parameters to your btcli commands. They can be used interchanably for the subtensor running on your computer. ## Install Bittensor The Bittensor Github repo can be found in the same organization on Github: [https://github.com/opentensor/bittensor](https://github.com/opentensor/bittensor) We're going to install it, and again use the dynamic branch: ```shell git clone git@github.com:opentensor/bittensor.git cd bittensor git fetch origin rao git checkout rao python3 -m pip install -e . cd .. python3 -m pip install -e bittensor/ ``` Any time there is an update to the subtensor or Bittensor - you'll need to pull from Github and rebuild and install the dependencies again. You now have a running Bittensor-Rao subtensor, and are ready to start creating! --- # RPC connection to the chain How do you extract knowledge from the Bittensor chain? _Source: https://beta.taostats.io/docs/concepts/chain-runtime/rpc-connection-to-the-chain_ _Last reviewed: 2026-09-15_ How do you extract knowledge from the Bittensor chain? The [taostats API](https://beta.taostats.io/docs/api-reference#/) gets you 99.9% of the way there. There are some calls that may require direct access into the chain. There is a [Python SDK](https://github.com/opentensor/bittensor) for some direct access. But not even that gets you everything. The [Taostats RPC Connection](https://beta.taostats.io/docs/api-reference) gives you direct access into the chain. From the chain you can make many requests for granular information. > [!NOTE] > **The latest methods available from the Substrate RPC** ## how RPC works: See the [API documentation](https://beta.taostats.io/docs/api-reference) for endpoint details. With just an API key from taostats, you can make RPC calls using the [Bittensor SDK](https://docs.learnbittensor.org/sdk/bt-api-ref) --- # Security Security: Securing a wallet: ledgers, multisig & proxies, Multisig, explained: tutorial, Multisig: worked examples _Source: https://beta.taostats.io/docs/concepts/security_ _Last reviewed: 2026-09-15_ - [Securing a wallet: ledgers, multisig & proxies](https://beta.taostats.io/docs/concepts/security/securing-a-wallet) - [Multisig, explained: tutorial](https://beta.taostats.io/docs/concepts/security/multisig-tutorial) - [Multisig: worked examples](https://beta.taostats.io/docs/concepts/security/multisig-examples) --- # Securing a wallet: ledgers, multisig & proxies Securing a wallet — ledgers, multisig & proxies (canonical document by Rufus) _Source: https://beta.taostats.io/docs/concepts/security/securing-a-wallet_ _Last reviewed: 2026-09-15_ [Securing a wallet — ledgers, multisig & proxies (canonical document by Rufus)](https://beta.taostats.io/docs-embeds/concepts/security/canonical/securing-a-wallet.html) --- # Multisig, explained: tutorial Multisig, explained — tutorial (canonical document by Rufus) _Source: https://beta.taostats.io/docs/concepts/security/multisig-tutorial_ _Last reviewed: 2026-09-15_ [Multisig, explained — tutorial (canonical document by Rufus)](https://beta.taostats.io/docs-embeds/concepts/security/canonical/multisig-tutorial.html) --- # Multisig: worked examples Multisig — worked examples (canonical document by Rufus) _Source: https://beta.taostats.io/docs/concepts/security/multisig-examples_ _Last reviewed: 2026-09-15_ [Multisig — worked examples (canonical document by Rufus)](https://beta.taostats.io/docs-embeds/concepts/security/canonical/multisig-examples.html) --- # Legacy / Deprecated Legacy / Deprecated: TAO flow (deprecated), TAO emission does not add to 100, Best practices for installing software, Crypto safety: the basics _Source: https://beta.taostats.io/docs/concepts/legacy-deprecated_ _Last reviewed: 2026-09-15_ - [TAO flow (deprecated)](https://beta.taostats.io/docs/concepts/legacy-deprecated/tao-flow) - [TAO emission does not add to 100](https://beta.taostats.io/docs/concepts/legacy-deprecated/tao-emission-does-not-add-to-100) - [Best practices for installing software](https://beta.taostats.io/docs/concepts/legacy-deprecated/a-best-practices-guide-for-safely-installing-software) - [Crypto safety: the basics](https://beta.taostats.io/docs/concepts/legacy-deprecated/crypto-safety-the-basics) --- # TAO flow (deprecated) As of May 2026, there are two types of tao flow. _Source: https://beta.taostats.io/docs/concepts/legacy-deprecated/tao-flow_ _Last reviewed: 2026-09-15_ > [!WARNING] > **Superseded — 2026-06-23** > > Tao Flow and Net Tao Flow no longer drive subnet emission shares. As of 2026-06-30 (subtensor PRs [#2779](https://github.com/opentensor/subtensor/pull/2779), [#2781](https://github.com/opentensor/subtensor/pull/2781), and [#2800](https://github.com/opentensor/subtensor/pull/2800), live on chain), emission shares are proportional to `subnet-price EMA × (1 − miner_burned)`, renormalized across subnets. (#2800 removed the earlier `root_proportion` weighting from the share formula.) > > See the canonical page: [Price-based subnet emission shares](https://beta.taostats.io/docs/concepts/protocol-changes/price-based-emission-shares). > > This page is kept for historical context. Tao flow remains a useful stakeholder-activity metric (staking in/out of the subnet pool), but it is no longer an input to the emission equation. As of May 2026, there are two types of tao flow. The article attempts to first disambiguate them and then define them, and their uses. ## Tao Flow Introduced in November 2025, tao flow is the measurement of staking and unstaking through the subnet liquidity pool. Its original use was to determine the emissions of a subnet. This changed in May 2026, with the introduction of Net Tao Flow. Tao flow is still an interesting figure - it is a measure of how stakeholders are entering and exiting the subnet. $$ flow_{tao}^{block} = tao_{staked} - tao_{unstaked} $$ ## Net Tao Flow Introduced in May 2026 to counteract issues with tao flow. The principal issue is that while tao flow is a good metric, it does not account for subsidies from the chain. A new term, Protocol cost is added. $$ netTaoFlow = taoFlow - protocolCost $$ If netTaoFlow {'<0'}, it is set at 0 - there is no concept of negative emission. But to smooth these values, a 30 day [exponential moving average](#/concepts/legacy-deprecated/tao-flow/#exponential--moving-average-example) is used for both. $$ netTaoFlow = EMA(taoFlow) - EMA(protocolCost) $$ This new term is used to define the emissions delivered to a subnet. ### Protocol cost Each block, the subnet is subsidized by [Tao Emission ](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) - broken into Tao injected into the pool and chain buys. Root sells of alpha work in the opposite direction: when validators claim and swap their root‑alpha dividends, TAO leaves the pool, offsetting part of the subsidy. $$ ProtocolCost = tao_{injected} + tao_{chainBuy} - rootSells $$ #### Exponential Moving Average example To smooth this equation, each subnet's flow is placed in an exponential moving average with a half life of 30 days: $$ flow_{tao}^{EMA} = (99.997\%)\,flow_{tao}^{EMA} + (0.003\%)\cdot flow_{tao}^{block} $$ This video explains the launch of tao flow: ## Flow based emission Starting in November 2025, tao flow will begin to be a part of the tao emission equation. By December 2025, 100% of tao emitted will be based on tao flow. ### What is flow In every subnet, tao flows in and out of the liquidity pool through staking actions: Flow is *only staking* it is **NOT** based on emission, root proportion or neuron registration.We can then normalize the flows across all subnets: $$ tao_{in} = \dfrac{flow_{tao}}{\sum_{all\ SNs} flow_{tao}} \cdot tao_{emission} $$ > [!NOTE] > Note: this is the default tao\_in. The actual tao in *may* be smaller than this due to [Tao Excess](https://beta.taostats.io/docs/concepts/legacy-deprecated/tao-emission-does-not-add-to-100). This occurs when price and default tao emission result in "too much" alpha\_in injected into the pool. > > The alpha\_in is scaled to it's maximum emission, which results in scaling down the tao\_in. The difference is called excess tao. --- # TAO emission does not add to 100 Learn about tao excess and how it is calculated. _Source: https://beta.taostats.io/docs/concepts/legacy-deprecated/tao-emission-does-not-add-to-100_ _Last reviewed: 2026-09-15_ Learn about tao excess and how it is calculated. Looking at the Taostats Subnet page, you may notice that the Emissions do not always add to 100% ![Dark-themed subnet table with rank, subnet, tags, and a single emission-percentage column plus a total row summing less than 100%](https://beta.taostats.io/images/docs/concepts/taostats-subnet-emission-percent-table.png) If 1 tao is emitted per block, this means that just 0.817 tao is being awarded to subnets. Where is the other .183 tao going? ## The chain is buying this tao and injecting it into subnet Liquidity pools. ### Why?? [Tao Emission](https://beta.taostats.io/docs/concepts/how-emission-works/tao-emission) is calculated from EMA flow. [Alpha Emission](https://beta.taostats.io/docs/concepts/how-emission-works/alpha-emission) is calculated from tao emission and price - but it has a max value of 1. At the time of writing, Subnet 8 has: * a normalized EMA flow of 0.05635527424782002. * Price is 0.035997 This would mean that alpha\_in should be 1.55 $$ \dfrac{0.05635527424782002}{0.035997} = 1.565554748 $$ But since the maximum alpha that can be emitted into the pool is one, this is not possible. So we reset alpha\_in to 1, and calculate the tao\_in: $$ 1 \cdot 0.035997 = 0.035997 $$ The tao\_in cannot exceed 0.035997. We have what is called `excess tao` = default\_tao\_in - tao\_in $$ 0.0563552742 - 0.035997 = 0.0203582742 $$ On SN 8 there is 0.0204 excess tao per block. This tao is added to the liquidity pool, and the received alpha is recycled. This serves to increase the price to nearer the emission percentage. ## how can I find which are getting excess tao? On the taostats subnet page - look for the daily chain buy column. This is the per block value multiplied by 7200. ![Single dark-themed table column headed "Daily Chain Buys" listing tao values in descending order with a sort chevron](https://beta.taostats.io/images/docs/concepts/taostats-daily-chain-buys-column.png) ## how will Excess tao change after the halving? When tao halves in December 2025, all excess tao will drop to 0. Tao emissions will drop by 50%, and the max alpha\_in will still be 1. This means that it is unlikely for excess toa be become a concern until we begin seeing alpha halvings in 2028. --- # Best practices for installing software As a User, installing software in a safe and verifiable manner isn’t always simple. _Source: https://beta.taostats.io/docs/concepts/legacy-deprecated/a-best-practices-guide-for-safely-installing-software_ _Last reviewed: 2026-09-15_ As a User, installing software in a safe and verifiable manner isn’t always simple. This guide will provide you with a few pointers to install software without putting yourself at risk, or becoming susceptible to supply chain attacks. ### Use the source repository It's important to install software in a safe and reliable manner. This reduces the chance of installing a malicious imitation, instead of a genuine product. Avoid pulling or installing software from third party platforms like [PyPI](https://pypi.org/) or [Docker Hub](https://hub.docker.com/), as the builds hosted on these platforms are not guaranteed to be derived from the same source code you will find on GitHub. Instead, rely on installing or building projects directly from the repo as this guarantees the build on your machine is built from source and hasn't been intercepted by a bad actor who may have published a malicious build. ### Verify signatures If the developers are signing commits, check to see that the releases are signed. This is typically achieved by signing an [annotated tag](https://git-scm.com/book/en/v2/Git-Basics-Tagging). You can easily and visually check this in GitHub by looking for the verification on the commit. If the author has uploaded their GPG keys to GitHub, you can fetch them at `https://github.com/.gpg`. If you’ve cloned the repo, and have the authors public keys installed, you can check and verify a tag’s signature with `tag -v `. ![GitHub commit row showing a green "Verified" signature badge next to the author, date, and commit hash](https://beta.taostats.io/images/docs/concepts/taostats-github-verified-commit-badge.png) ### Installing packages When installing packages from GitHub, either clone down and checkout a tagged version, or point the project's language's toolchain directly at the repo and install from there. > 🚧 > > Never, *ever* install a project or dependency without specifying a version. One of the easiest and most commonly performed attacks, is to push a patched version and hope users blindly auto update. > > Only upgrade when instructed to by the project developers or when they announce a new version, via official/verified channels, and only to the version they have announced. > > To checkout and switch branches in one command, use: ```bash git checkout -b ``` #### Installing via a toolchain While this example is for a Python project, it applies to most programming languages and their toolchains. If a user wishes to install `bittensor` at `v7.3.0`, you can install it directly from GitHub using the following command: ```bash $ pip install --upgrade git+https://github.com/opentensor/bittensor.git@v7.3.0 $ btcli --help usage: btcli bittensor cli v7.3.0 ``` This avoids relying on an external dependency like PyPI to install the project (where malicious code is most likely to reside), but pip will still resolve it's *dependencies* from PyPI. This is the responsibility of the developers to check that any project dependencies have not been compromised ([see below](https://www.notion.so/A-Best-Practices-Guide-for-Safely-Installing-Software-38766d1f178f4ef89490cb999d61ba16?pvs=21)). #### Installing via Docker If you don't have the necessary toolchain for a given project, but you do have [Docker](https://docker.com/) installed and can locate a `Dockerfile` in the root of the project. You can build the project directly by pointing Docker at the repo. This avoids having to pull a container image from Docker Hub, which may be compromised. ```bash docker build \ https://github.com/opentensor/bittensor.git#v7.3.0 \ -t opentensor/bittensor:v7.3.0 ``` ## What Developers can do to help While it's not possible to produce *truly* reproducible builds in Python (it was never a requirement of pip, nor is Python built to do it), you can get close by relying on lock files to avoid supply chain attacks. If you notice the projects you are using don’t do some of the following things, request them via GitHub Issues. ### Manage project dependencies properly To guarantee software is resistant to supply chain attacks, correctly manage and verify the project’s dependencies. If you are still relying on `pip` and `setuptools` you’re probably doing it wrong! Consider an alternative like [Poetry](https://python-poetry.org/), to manage and build your projects. Poetry will generate lock files (via `poetry lock`) or a pinned and hashed `requirements.txt` (via `poetry export`) that will lock down all of your project dependencies and any transient dependencies. Users can depend on the hashed `requirements.txt` to install the project’s dependencies without relying on Poetry. This will stop any supply chain attacks that swap out packages for malicious variants, by guaranteeing the user is pulling and installing the exact modules, and verifying the contents haven't been modified. If the project isn’t a library, commit the lock files with the repo so that those either making changes, or just installing, will get exactly the same versions of packages. When bumping the version of a given dependency, verify the new version is legitimate and uncompromised. We suggest bumping, checking, and committing one dependency at a time. ### Make deployment easy If you provide a Docker container, make sure it’s entirely self sufficient. Invoking `docker build .` should work without any special environmental setup, this lets users remotely point to your repo with `docker build https://github.com/org/project.git#tag` and build directly from the repo. If you want to provide other alternative images that are lighter, or are specialised for unique environments, append a suffix and let the user choose with `docker build -f Dockerfile.foo`. If publishing to Docker hub, make sure there isn’t a `latest` tag; Docker defaults to `latest` if no tag is requested. This can lead to supply chain attacks in the event of a compromised Docker hub account. ### Check for vulnerabilities Use tools like [safety](https://pypi.org/project/safety/) and enable the [bandit](https://docs.astral.sh/ruff/rules/#flake8-bandit-s) linting rules inside of `ruff` to check that your packages don’t have known vulnerabilities and that you’re not introducing any yourself. Automate these tools to run when commits are pushed to GitHub. ### Authenticate everything Use 2 Factor Authentication to protect developer accounts, especially those with the ability to merge pull requests and publish new releases. [Limit permissions](https://en.wikipedia.org/wiki/Principle_of_least_privilege) and access to repos to only what is necessary. This minimizes potential damage if an account is compromised. For enhanced verification generate a GPG key, or use a [HSM](https://www.yubico.com/us/product/yubikey-5-series/yubikey-5-nfc/). Upload your GPG keys to places like [GitHub](https://docs.github.com/en/authentication/managing-commit-signature-verification/adding-a-gpg-key-to-your-github-account) and [Keybase](https://keybase.io), and announce their availability over your official channels. Sign commits and annotated tags to allow both GitHub and your more security concerned users that you really did publish those commits. If you release build artifacts, hash, sign, and provide the signatures alongside them too. ### Release Process Ensure developers adhere to a formal branching scheme. Proposed releases should be placed in a branch and a pull request set up to merge back into the `main/master` branch. Set up the repo to only allow a quorum of specific developers to merge the PR. Any small changes or hotfixes can then live in the release branch. Once approved, merge the branch into `main/master` and have whoever is responsible for releases, generate a commit with any version numbers inside the project bumped appropriately, the change log regenerated, and an annotated/signed tag. Github will pick this up and generate a release which you can then see on the project’s releases page. Once the release is finalised, you may then deploy the release to any suitable environments by either merging `main/master` into a environmental branch, or force moving a lightweight tag that represents the environment. Your CI should spot the change and start the release process. For libraries, once the merge is complete and the version ratified, use your CI to automatically use the project’s toolchain to build an artifact(s) and publish them to the appropriate repos. --- # Introduction Scammers are everywhere. _Source: https://beta.taostats.io/docs/concepts/legacy-deprecated/crypto-safety-the-basics_ _Last reviewed: 2026-09-15_ Scammers are everywhere. You may have gotten emails form Nigerian princes, or phone calls from the IRS demanding Home Depot gift cards... There are people up to no good, and it is your responsibility to keep yourself secure. Below are a few tips to help you. When it comes to high value objects - scammers are attracted, like a moth to a bright light. Bittensor is no exception, and members of the community have had wallets drained. All of the advantages of crypto - permissionless, anonymous - can be used against you... so be careful! ## Wallet safety Your tao is stored on the chain, and only those with wallet credentials can access your tao. ### Seed phrase/Mnemonic When you create a wallet you are given a 12 word phrase that can be used to recreate your wallet. Super useful if your computer dies, or you smash your phone use the seed phrase to create a new access point. However, if you **give out this phrase** you are giving this person **full access** to all of your tao in this wallet. NEVER DO THIS. * We have seen examples where the user knows not to share their seed phrase, but is tricked into sharing the "hex encoded" version of their seed phrase. This 2 steps for the hacker to access your wallet. ### Coldkey/hotkey Wallet addresses: 5GKH9FPPnWSUoeeTJp19wVtd84XqFW4pyK2ijV2GsFbhTrP1 are safe to share. You may lose some anonymity around your coldkey by sharing it, but it cannot be used nefariously. ## Social Media This holds for Twitter, Discord, Telegram - anywhere really. If you ask a question, and you get a random person offering to help you - assume it is a scam. **Especially** if it is a direct message. ### Your RPC Settings The below screenshot sounds very technical - but it means nothing. They are just trying to get your seed phrase. ![Dark-themed chat message bubble containing scam text urging the recipient to reset their wallet RPC settings](https://beta.taostats.io/images/docs/concepts/taostats-rpc-settings-scam-message.png) ### Discord Keep it in the open. Use channels for all messages. If you must DM: ensure it is the person you think you are speaking to. Leave a note in their profile, and make sure that note matches [Crypto Safety: Discord Direct Messages](https://www.youtube.com/watch?v=6uUtLxe3mXc) ![72 mutual Friends, and 8 mutual servers. If someone DMs you and you share no servers - They are a scammer.](https://beta.taostats.io/images/docs/concepts/57a9192e-image.png) ## In Doubt? * Ask in public. If someone wants to use a different server, or move to DMs - they may be trying to hide from the community - not keep you safe. * Don't do it. Educate yourself and make sure you understand what your action does, and how it could affect you/your wallets. * Too good to be true? You are a direct descendant of Queen Elizabeth II and she has left you 4,000 tao in her will? Stop and think about what you are about to do. ## What you can do? * If using Discord - set up 2 Factor Authentication - either Via SMS or with an authenticator app. This will prevent unauthorized takeovers of your Discord account. * Always verify who you are talking with. * Be wary of clicking any link. Especially messages to #open-a-ticket or #talk-to-an-admin (r similar). They are taking you to a new Discord server. --- # Bittensor CLI The Bittensor command line interface (CLI) allows programmatic access to the Bittensor ecosystem. _Source: https://beta.taostats.io/docs/concepts/command-line-tool_ _Last reviewed: 2026-09-15_ The Bittensor command line interface (CLI) allows programmatic access to the Bittensor ecosystem. As of September 2024, the BTCLI has is no longer part of the Bittensor package and is a standalone app. ## Installation ### From Source As of release 8.0.0 (September 2024), the btcli has its own repository separate from the SDK. ``` git clone https://github.com/opentensor/btcli.git cd btcli pip install . ``` ### From pip ``` pip install bittensor-cli ``` If you would like the SDK and the CLI: ``` pip install bittensor[cli] #for sdk + cli ``` Trouble? The most up-to-date instructions can be found in the [Bittensor documentation](https://beta.taostats.io/docs/concepts/command-line-tool). ## Using the CLI To get all of the latest commands from the CLI use `btcli --help` The command: `btcli --commands` shows a simple tree of possible commands The authoritative help is always what your installed version prints — run `btcli --help` locally, or see the [Bittensor CLI repository](https://github.com/opentensor/btcli). A sample of the top-level help output looks like this: ```shell btcli --help Command line interface (CLI) for Bittensor. Uses the values in the configuration file. These values can be overridden by passing them explicitly in the command line. ╭─ Options ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ --version Show BTCLI version │ │ --commands Show BTCLI commands │ │ --install-completion Install completion for the current shell. │ │ --show-completion Show completion for the current shell, to copy it or customize the installation. │ │ --help Show this message and exit. │ ╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ ╭─ Commands ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ config Config commands, aliases: `c`, `conf` │ │ stake Stake commands, alias: `st` │ │ subnets Subnets commands, alias: `s`, `subnet` │ │ sudo Sudo commands, alias: `su` │ │ wallet Wallet commands, aliases: `wallets`, `w` │ ╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ Made with ❤ by The Openτensor Foundaτion ``` ## Configuring the CLI The new `btcli config` allows you to set default parameters on your installation.