# 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://taostats.io/docs. The index of every docs page is https://taostats.io/llms.txt and the whole corpus is https://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://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://taostats.io/docs/concepts/protocol-changes) — Recent and upcoming protocol-level changes. - [Subnets](https://taostats.io/docs/concepts/subnets) — How subnets are structured, registered, and emit. - [Validators](https://taostats.io/docs/concepts/validators) — Running, measuring, and rewarding validators. - [Miners](https://taostats.io/docs/concepts/miners) — Mining mechanics, weights, and emission. - [Staking](https://taostats.io/docs/concepts/staking) — Stake, yield, and how returns are calculated. - [Tokenomics](https://taostats.io/docs/concepts/tokenomics) — TAO, alpha, emission, halving, and slippage. - [How emission works](https://taostats.io/docs/concepts/how-emission-works) — Where TAO and alpha emissions flow, and to whom. - [Wallets & accounts](https://taostats.io/docs/concepts/wallets-accounts) — Keys, signing, and connecting wallets. - [Chain & runtime](https://taostats.io/docs/concepts/chain-runtime) — How the Bittensor chain runs underneath. - [Security](https://taostats.io/docs/concepts/security) — Staying safe: keys, software, and best practices. - [Legacy / Deprecated](https://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://taostats.io/docs/concepts/protocol-changes_ _Last reviewed: 2026-10-14_ Recent and upcoming protocol-level changes on Bittensor, each with a full explainer. To see every runtime change with the date its pull request opened, merged, reached testnet and went live on mainnet, use the [protocol change tracker](https://taostats.io/docs/concepts/protocol-changes/change-tracker). - [Protocol change tracker](https://taostats.io/docs/concepts/protocol-changes/change-tracker) — Every runtime change from pull request to testnet to mainnet, with dates and open proposals. - [Root Reborn](https://taostats.io/docs/concepts/protocol-changes/root-reborn/tldr) — Root dividends held in the validator's basket of subnet alpha, rebalanced by trading. - [Null consensus](https://taostats.io/docs/concepts/protocol-changes/null-consensus) — Subnet owners can replace Yuma with Null: the top-stake validator sets miner pay, dividends follow stake (spec 474). - [The emission gate](https://taostats.io/docs/concepts/protocol-changes/emission-gate) — Emission gating mechanics (spec 440). - [Miner collateral](https://taostats.io/docs/concepts/protocol-changes/miner-collateral) — Collateral requirements for miners (PRs #2953 + #2960). - [Superellipse pools](https://taostats.io/docs/concepts/protocol-changes/superellipse-pools) — Pools move to a bounded ellipse curve; balances no swap can reach fund a per-subnet lending vault (PR #3211). - [Shorts and longs](https://taostats.io/docs/concepts/protocol-changes/shorts-and-longs) — Borrow alpha against TAO (short) or TAO against alpha (long) from the lending vault (PR #3211). --- # Protocol change tracker Every Bittensor runtime change with the date its pull request opened, merged, reached testnet and went live on mainnet. _Source: https://taostats.io/docs/concepts/protocol-changes/change-tracker_ _Last reviewed: 2026-10-15_ This page tracks every change to the Bittensor chain runtime in [subtensor](https://github.com/RaoFoundation/subtensor), from pull request to production. For each change it shows when the pull request opened, when it merged, which runtime spec it shipped in, and when testnet and mainnet (Finney) first ran that spec. The data refreshes from the chains and GitHub every four hours. > [!NOTE] > **Where the dates come from** > > - **Opened** and **merged** come from the pull request on GitHub. > - **Release** is the first subtensor release (`vNNN`) cut after the merge, which is the runtime spec that contains the change. > - **Testnet** and **mainnet** are the dates each chain first ran that spec or a later one, read on-chain. Git branch dates are not used. > - **Days to mainnet** counts from the pull request opening to the mainnet upgrade. > - Only pull requests that change chain code (pallets, runtime, precompiles, node) are listed. SDK, CLI, CI, test and docs changes are left out. ## Status at a glance - **Mainnet (Finney):** spec 478, live since 2026-10-13 - **Testnet:** spec 479, live since 2026-10-14 - **Merged chain-code changes:** 46, 46 live on mainnet; median 1 days from pull request to mainnet, longest 11 _Snapshot of 2026-10-14. The web page refreshes every four hours._ ## Days to mainnet The last 20 runtime releases that reached mainnet. | Release spec | Mainnet | Days to mainnet | Changes | | --- | --- | --- | --- | | 445 | 2026-08-12 | 6 | 3 | | 446 | 2026-08-14 | 2 | 1 | | 447 | 2026-08-14 | 0 | 1 | | 448 | 2026-08-21 | 3 | 1 | | 450 | 2026-08-27 | 6 | 2 | | 452 | 2026-08-29 | 1 | 3 | | 453 | 2026-09-03 | 0 | 1 | | 454 | 2026-09-04 | 0 | 1 | | 459 | 2026-09-15 | 8 | 4 | | 464 | 2026-09-17 | 6 | 4 | | 466 | 2026-09-18 | 1 | 3 | | 467 | 2026-09-18 | 0 | 1 | | 468 | 2026-09-21 | 1 | 1 | | 469 | 2026-09-22 | 0 | 1 | | 470 | 2026-09-24 | 2 | 1 | | 472 | 2026-10-02 | 9 | 1 | | 473 | 2026-10-05 | 3 | 1 | | 475 | 2026-10-07 | 7 | 2 | | 477 | 2026-10-12 | 4 | 4 | | 478 | 2026-10-13 | 1 | 1 | ## Runtime upgrades Every spec either chain has run since spec 437, newest first. **Never on testnet**: mainnet ran a spec that testnet skipped. **Testnet only**: a newer spec replaced it before it reached mainnet. **In testing**: testnet runs a spec newer than mainnet's. **Mainnet first**: mainnet upgraded before testnet. | Spec | Mainnet | Testnet | Days on testnet first | | --- | --- | --- | --- | | 479 | — | 2026-10-14 | in testing | | 478 | 2026-10-13 | 2026-10-13 | 0 | | 477 | 2026-10-12 | 2026-10-08 | 4 | | 476 | — | 2026-10-08 | testnet only | | 475 | 2026-10-07 | 2026-10-07 | 0 | | 473 | 2026-10-05 | 2026-10-05 | 0 | | 472 | 2026-10-02 | 2026-10-02 | 0 | | 471 | — | 2026-09-24 | testnet only | | 470 | 2026-09-24 | 2026-09-23 | 1 | | 469 | 2026-09-22 | 2026-09-22 | 0 | | 468 | 2026-09-21 | 2026-09-21 | 0 | | 467 | 2026-09-18 | 2026-09-18 | 0 | | 466 | 2026-09-18 | 2026-09-18 | 0 | | 465 | — | 2026-09-17 | testnet only | | 464 | 2026-09-17 | 2026-09-17 | 0 | | 463 | — | 2026-09-16 | testnet only | | 461 | — | 2026-09-16 | testnet only | | 460 | — | 2026-09-15 | testnet only | | 459 | 2026-09-15 | 2026-09-15 | 0 | | 458 | 2026-09-14 | 2026-09-14 | 0 | | 457 | 2026-09-14 | — | never on testnet | | 456 | 2026-09-14 | — | never on testnet | | 455 | 2026-09-07 | 2026-09-08 | mainnet first | | 454 | 2026-09-04 | 2026-09-04 | 0 | | 453 | 2026-09-03 | 2026-09-03 | 0 | | 452 | 2026-08-29 | 2026-08-29 | 0 | | 451 | — | 2026-08-28 | testnet only | | 450 | 2026-08-27 | 2026-08-27 | 0 | | 449 | — | 2026-08-25 | testnet only | | 448 | 2026-08-21 | 2026-08-21 | 0 | | 447 | 2026-08-14 | 2026-08-14 | 0 | | 446 | 2026-08-14 | 2026-08-14 | 0 | | 445 | 2026-08-12 | 2026-08-12 | 0 | | 443 | 2026-08-04 | 2026-08-04 | 0 | | 442 | 2026-08-04 | 2026-08-04 | 0 | | 441 | 2026-08-03 | 2026-08-03 | 0 | | 440 | 2026-07-27 | 2026-07-27 | 0 | | 439 | 2026-07-27 | 2026-07-24 | 3 | | 438 | 2026-07-23 | 2026-07-23 | 0 | | 437 | 2026-07-22 | 2026-07-22 | 0 | ## Merged changes Newest merge first. **Release** is the runtime spec the change shipped in. A dash under testnet or mainnet means that chain has not yet run a runtime containing it. | PR | Change | Release | Opened | Merged | Testnet | Mainnet | Days to mainnet | | --- | --- | --- | --- | --- | --- | --- | --- | | [#3237](https://github.com/RaoFoundation/subtensor/pull/3237) | Release 478 | 478 | 2026-10-12 | 2026-10-13 | 2026-10-13 | 2026-10-13 | 1 | | [#3221](https://github.com/RaoFoundation/subtensor/pull/3221) | Bump runtime spec to 477 and Python release versions | 477 | 2026-10-08 | 2026-10-08 | 2026-10-08 | 2026-10-12 | 4 | | [#3218](https://github.com/RaoFoundation/subtensor/pull/3218) | fix logs | 477 | 2026-10-08 | 2026-10-08 | 2026-10-08 | 2026-10-12 | 4 | | [#3219](https://github.com/RaoFoundation/subtensor/pull/3219) | Fix oversized testnet root claim weight reservation | 477 | 2026-10-08 | 2026-10-08 | 2026-10-08 | 2026-10-12 | 4 | | [#3217](https://github.com/RaoFoundation/subtensor/pull/3217) | Allow subnet owners to configure PoW difficulty | 476 | 2026-10-08 | 2026-10-08 | 2026-10-08 | 2026-10-12 | 4 | | [#3214](https://github.com/RaoFoundation/subtensor/pull/3214) | Make basket minimum trade amount sudo-adjustable | 475 | 2026-10-06 | 2026-10-07 | 2026-10-07 | 2026-10-07 | 1 | | [#3206](https://github.com/RaoFoundation/subtensor/pull/3206) | feat: add Null consensus, precise emissions and PoW registration | 475 | 2026-09-30 | 2026-10-06 | 2026-10-07 | 2026-10-07 | 7 | | [#3208](https://github.com/RaoFoundation/subtensor/pull/3208) | release-473 | 473 | 2026-10-02 | 2026-10-03 | 2026-10-05 | 2026-10-05 | 3 | | [#3198](https://github.com/RaoFoundation/subtensor/pull/3198) | Prevent Fee-Draining Basket Swaps and Clean Up Stale Staking Hotkeys | 471 | 2026-09-23 | 2026-09-24 | 2026-09-24 | 2026-10-02 | 9 | | [#3196](https://github.com/RaoFoundation/subtensor/pull/3196) | Add swap_basket_many extrinsic | 470 | 2026-09-22 | 2026-09-23 | 2026-09-23 | 2026-09-24 | 2 | | [#3192](https://github.com/RaoFoundation/subtensor/pull/3192) | spec 469: v468 bug fixes + failed-call fee refunds | 469 | 2026-09-22 | 2026-09-22 | 2026-09-22 | 2026-09-22 | 0 | | [#3184](https://github.com/RaoFoundation/subtensor/pull/3184) | spec 468: enable basket trading + skip dust rows on root claims | 468 | 2026-09-20 | 2026-09-21 | 2026-09-21 | 2026-09-21 | 1 | | [#3183](https://github.com/RaoFoundation/subtensor/pull/3183) | spec 467: halve transaction fees (native + EVM) | 467 | 2026-09-18 | 2026-09-18 | 2026-09-18 | 2026-09-18 | 0 | | [#3182](https://github.com/RaoFoundation/subtensor/pull/3182) | Spec 466: fee cap only — restore 4s block budget | 466 | 2026-09-18 | 2026-09-18 | 2026-09-18 | 2026-09-18 | 0 | | [#3181](https://github.com/RaoFoundation/subtensor/pull/3181) | Spec 466: cap staking scan fees at four hotkeys | 466 | 2026-09-18 | 2026-09-18 | 2026-09-18 | 2026-09-18 | 0 | | [#3179](https://github.com/RaoFoundation/subtensor/pull/3179) | spec 465: safer-only hotfix pack | 466 | 2026-09-17 | 2026-09-17 | 2026-09-18 | 2026-09-18 | 1 | | [#3178](https://github.com/RaoFoundation/subtensor/pull/3178) | Unify runtime on spec 464 (baskets + 463 security + torsion) | 464 | 2026-09-17 | 2026-09-17 | 2026-09-17 | 2026-09-17 | 0 | | [#3169](https://github.com/RaoFoundation/subtensor/pull/3169) | Hotfix 2 (spec 462): nonce persistence, fee-exempt call pricing, staking bookkeeping | 464 | 2026-09-16 | 2026-09-16 | 2026-09-17 | 2026-09-17 | 1 | | [#3155](https://github.com/RaoFoundation/subtensor/pull/3155) | feat: swap_basket — validator basket trading (consolidated) | 464 | 2026-09-11 | 2026-09-16 | 2026-09-17 | 2026-09-17 | 6 | | [#3164](https://github.com/RaoFoundation/subtensor/pull/3164) | share-pool: start a pool epoch on open so pre-upgrade leftover rows are retired | 464 | 2026-09-15 | 2026-09-15 | 2026-09-17 | 2026-09-17 | 2 | | [#3162](https://github.com/RaoFoundation/subtensor/pull/3162) | share-pool: keep denominator consistent with stored shares; reconcile root pot | 459 | 2026-09-15 | 2026-09-15 | 2026-09-15 | 2026-09-15 | 0 | | [#3160](https://github.com/RaoFoundation/subtensor/pull/3160) | release 458 | 459 | 2026-09-14 | 2026-09-14 | 2026-09-15 | 2026-09-15 | 1 | | [#3158](https://github.com/RaoFoundation/subtensor/pull/3158) | release-v446 | 459 | 2026-09-14 | 2026-09-14 | 2026-09-15 | 2026-09-15 | 1 | | [#3146](https://github.com/RaoFoundation/subtensor/pull/3146) | release-455 | 459 | 2026-09-07 | 2026-09-07 | 2026-09-15 | 2026-09-15 | 8 | | [#3143](https://github.com/RaoFoundation/subtensor/pull/3143) | release-454 | 454 | 2026-09-04 | 2026-09-04 | 2026-09-04 | 2026-09-04 | 0 | | [#3138](https://github.com/RaoFoundation/subtensor/pull/3138) | release-453 | 453 | 2026-09-03 | 2026-09-03 | 2026-09-03 | 2026-09-03 | 0 | | [#3131](https://github.com/RaoFoundation/subtensor/pull/3131) | Bump spec_version to 452 | 452 | 2026-08-29 | 2026-08-29 | 2026-08-29 | 2026-08-29 | 0 | | [#3130](https://github.com/RaoFoundation/subtensor/pull/3130) | Align precompile execution with the current call frame | 452 | 2026-08-29 | 2026-08-29 | 2026-08-29 | 2026-08-29 | 0 | | [#3126](https://github.com/RaoFoundation/subtensor/pull/3126) | Runtime 451 hotfix: harden Root Reborn basket claims | 452 | 2026-08-28 | 2026-08-28 | 2026-08-29 | 2026-08-29 | 1 | | [#3117](https://github.com/RaoFoundation/subtensor/pull/3117) | Release 450: canonical on-chain beta pricing, display units, and curated beta | 450 | 2026-08-26 | 2026-08-27 | 2026-08-27 | 2026-08-27 | 1 | | [#3109](https://github.com/RaoFoundation/subtensor/pull/3109) | Release 449: enable root weight setting with a 1/16 concentration cap | 450 | 2026-08-21 | 2026-08-25 | 2026-08-27 | 2026-08-27 | 6 | | [#3089](https://github.com/RaoFoundation/subtensor/pull/3089) | Release spec 448: live root-claim fee quotes and SDK 11.2.0.dev0 | 448 | 2026-08-18 | 2026-08-21 | 2026-08-21 | 2026-08-21 | 3 | | [#3083](https://github.com/RaoFoundation/subtensor/pull/3083) | Conviction Normalization: single-hotkey 18% takeover gate (spec 447) | 447 | 2026-08-14 | 2026-08-14 | 2026-08-14 | 2026-08-14 | 0 | | [#3077](https://github.com/RaoFoundation/subtensor/pull/3077) | Release 446 | 446 | 2026-08-12 | 2026-08-13 | 2026-08-14 | 2026-08-14 | 2 | | [#3071](https://github.com/RaoFoundation/subtensor/pull/3071) | Restore miner-burn emission scaling | 445 | 2026-08-11 | 2026-08-12 | 2026-08-12 | 2026-08-12 | 1 | | [#3076](https://github.com/RaoFoundation/subtensor/pull/3076) | reduce bloat | 445 | 2026-08-12 | 2026-08-12 | 2026-08-12 | 2026-08-12 | 0 | | [#3058](https://github.com/RaoFoundation/subtensor/pull/3058) | Release v444: remove miner-burn scaling from subnet emission shares | 445 | 2026-08-06 | 2026-08-10 | 2026-08-12 | 2026-08-12 | 6 | | [#3042](https://github.com/RaoFoundation/subtensor/pull/3042) | chore(subtensor): gate stake_into_basket pending state-growth review | 443 | 2026-08-04 | 2026-08-04 | 2026-08-04 | 2026-08-04 | 0 | | [#3035](https://github.com/RaoFoundation/subtensor/pull/3035) | hotfix: stop ineligible root stake diverting into ALPHA dividends | 442 | 2026-08-04 | 2026-08-04 | 2026-08-04 | 2026-08-04 | 0 | | [#2968](https://github.com/RaoFoundation/subtensor/pull/2968) | release-root-reborn | 441 | 2026-07-23 | 2026-08-03 | 2026-08-03 | 2026-08-03 | 11 | | [#2990](https://github.com/RaoFoundation/subtensor/pull/2990) | release-v440: emission gate | 440 | 2026-07-27 | 2026-07-27 | 2026-07-27 | 2026-07-27 | 0 | | [#2985](https://github.com/RaoFoundation/subtensor/pull/2985) | Fix claim root weight accounting | 440 | 2026-07-25 | 2026-07-27 | 2026-07-27 | 2026-07-27 | 2 | | [#2984](https://github.com/RaoFoundation/subtensor/pull/2984) | Release v439 | 439 | 2026-07-24 | 2026-07-24 | 2026-07-24 | 2026-07-27 | 3 | | [#2970](https://github.com/RaoFoundation/subtensor/pull/2970) | V438 Release | 438 | 2026-07-23 | 2026-07-23 | 2026-07-23 | 2026-07-23 | 0 | | [#2960](https://github.com/RaoFoundation/subtensor/pull/2960) | Runtime 437: collateral, key lineage, and bonded swap hardening | 437 | 2026-07-22 | 2026-07-22 | 2026-07-22 | 2026-07-22 | 0 | | [#2953](https://github.com/RaoFoundation/subtensor/pull/2953) | The v435 upgrade: miner registration collateral | 437 | 2026-07-21 | 2026-07-21 | 2026-07-22 | 2026-07-22 | 1 | ## Open proposals Open, non-draft pull requests against subtensor `main` that change chain code. None of them is on testnet or mainnet, and some will never merge. | PR | Proposal | Opened | Open for (days) | | --- | --- | --- | --- | | [#3254](https://github.com/RaoFoundation/subtensor/pull/3254) | etao: per-subnet emission weight vector [burn, recycle, owner, validator, miner] with TAO-weight multiplier (spec 479) | 2026-10-14 | 0 | | [#3239](https://github.com/RaoFoundation/subtensor/pull/3239) | Keep coldkeys locked after sudo swap reset | 2026-10-13 | 1 | | [#3231](https://github.com/RaoFoundation/subtensor/pull/3231) | Run a due Null epoch first so earlier subnets cannot starve it | 2026-10-11 | 3 | | [#3225](https://github.com/RaoFoundation/subtensor/pull/3225) | test(runtime): add ±20% fee regression snapshots and EVM transaction coverage | 2026-10-09 | 5 | | [#3223](https://github.com/RaoFoundation/subtensor/pull/3223) | fix warnings | 2026-10-09 | 5 | | [#3220](https://github.com/RaoFoundation/subtensor/pull/3220) | Introduce experimental hashed accounts with mnemonic-derived key rotation | 2026-10-08 | 6 | | [#3212](https://github.com/RaoFoundation/subtensor/pull/3212) | test(runtime): move fee baseline pins to rstest cases with insta snapshots | 2026-10-05 | 9 | | [#3211](https://github.com/RaoFoundation/subtensor/pull/3211) | Add superellipse pools, reserve-funded lending and price-impact controls | 2026-10-05 | 9 | | [#3210](https://github.com/RaoFoundation/subtensor/pull/3210) | Migrate dynamic subnet pools to fixed translated superellipses | 2026-10-02 | 12 | | [#3207](https://github.com/RaoFoundation/subtensor/pull/3207) | Preserve stake and dividends during alpha migration | 2026-10-02 | 12 | | [#3190](https://github.com/RaoFoundation/subtensor/pull/3190) | Refund the StakingHotkeys walk on unstake-side failure and prune ghost hotkeys | 2026-09-21 | 23 | | [#3180](https://github.com/RaoFoundation/subtensor/pull/3180) | Cap staking scan fees at four hotkeys | 2026-09-17 | 27 | | [#3137](https://github.com/RaoFoundation/subtensor/pull/3137) | Extend linked orders expiration to 180 days | 2026-09-03 | 41 | | [#3135](https://github.com/RaoFoundation/subtensor/pull/3135) | Add pallet-derivatives: longs and shorts on subnet alpha (spec 455) | 2026-09-02 | 42 | | [#3110](https://github.com/RaoFoundation/subtensor/pull/3110) | Canonical rails: buy staked subnet alpha from MetaMask with USDC | 2026-08-21 | 54 | | [#3101](https://github.com/RaoFoundation/subtensor/pull/3101) | Add continuous stake reporting throughout subnet dissolution lifecycle | 2026-08-20 | 55 | | [#3041](https://github.com/RaoFoundation/subtensor/pull/3041) | Add Validate proxy support to runtime and Python SDK | 2026-08-04 | 71 | | [#3038](https://github.com/RaoFoundation/subtensor/pull/3038) | fix: sum emission across mechanisms instead of weighting it | 2026-08-04 | 71 | | [#3029](https://github.com/RaoFoundation/subtensor/pull/3029) | 1τ/1α pool seed + depth-graduated emission price cap | 2026-08-03 | 72 | | [#3023](https://github.com/RaoFoundation/subtensor/pull/3023) | Subnet owner right of first refusal over eviction | 2026-07-31 | 75 | | [#3009](https://github.com/RaoFoundation/subtensor/pull/3009) | Release v441 - Add childkey cooldown in subnet tempos | 2026-07-28 | 78 | | [#2997](https://github.com/RaoFoundation/subtensor/pull/2997) | Refund Unused Extrinsic Weight (fee) | 2026-07-27 | 79 | ## Shipped is not always switched on Some features ship in a runtime upgrade with a switch that is off. They do nothing until a root (sudo) call turns them on, so the mainnet date is the date the code arrived, not the date users could use it. Each feature's explainer page says when its switch is on. --- # 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://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://taostats.io/docs/concepts/staking/root-validator-baskets) for the mechanics. - [TL;DR](https://taostats.io/docs/concepts/protocol-changes/root-reborn/tldr) — The short version — what changes and what you actually do. - [Full explainer](https://taostats.io/docs/concepts/protocol-changes/root-reborn/explainer) — The complete walkthrough of baskets, claiming, and mechanics. - [Visual demo](https://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://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://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://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) --- # Null consensus (spec 474) Subnet owners can switch their subnet from Yuma to Null: the top-stake validator sets miner pay and every staker earns dividends by stake. _Source: https://taostats.io/docs/concepts/protocol-changes/null-consensus_ _Last reviewed: 2026-10-06_ > [!WARNING] > **Not live on mainnet yet** > > Null consensus ships in runtime **spec 474** ([subtensor PR #3206](https://github.com/RaoFoundation/subtensor/pull/3206), merged 2026-10-06). Finney runs spec 473. When 474 ships, every subnet stays on Yuma until its owner switches. ## The short version Null is a second epoch mode, alongside Yuma. A subnet owner or root can switch a subnet to it. On a Null subnet: - **The validator with the most stake sets all miner pay.** Only that UID's weights count. - **Dividends follow stake.** Every staked UID earns its stake share, active or not. - **No bonds, consensus or clipping.** Weights are used exactly as sent. - **The emission split is unchanged.** The owner cut comes first, then miners and validators split the rest. Yuma stays the default on every existing and new subnet. The root subnet cannot use Null. ## Yuma vs Null | | Yuma | Null | |---|---|---| | Who sets miner pay | All permitted validators, stake-weighted | Only the UID with the most stake | | Validator permits | Up to `max_allowed_validators` | Exactly one, the top-stake UID | | Validator dividends | By bonds | By stake. Inactive stakers still earn | | Bonds, consensus, clipping | Yes | None | | Weights | Normalised and clipped | Raw `u16` values, used as stored | | Max UIDs per subnet | 256 ÷ mechanisms | 2,500 ÷ mechanisms | ## How miner pay is set | Rule | Detail | |---|---| | Who | The registered UID with the most stake. One winner per epoch | | Tie | The lowest UID wins | | Inactive | Still counts. Inactivity does not remove stake | | Owner | No special treatment. The owner only wins with the most stake | | Empty or all-zero weights | Miner pay is split equally across every registered UID | | No staked UID on the subnet | The validator half goes to miners | This is a single point of control by design: whoever holds the most stake on a Null subnet decides every miner's share. ## For subnet owners ```bash btcli hparams set --netuid 123 --name epoch_consensus --value Null btcli hparams set --netuid 123 --name max_allowed_uids --value 2500 btcli hparams trim-null --netuid 123 --switch-to-yuma ``` | Item | Rule | |---|---| | Who can switch | Subnet owner or root (`sudo_set_epoch_consensus`), within the normal owner rate limit and admin window | | Root subnet | Cannot use Null | | Capacity on Null | Up to 2,500 ÷ mechanisms. Switching does not raise `max_allowed_uids`; the owner sets it | | Back to Yuma | Registered UIDs must fit 256 ÷ mechanisms, so trim first | | Trimming | At most 64 UIDs per batch (`sudo_trim_null_uids_batch`) | | Pending commits | Must clear before any mode change | | Validator limit | Set to 1 on entering Null. The previous value is saved and restored on return to Yuma | ## Registration: burn, proof of work or both Burn and proof-of-work registration are separate switches, both settable by the subnet owner or root: | Switch | Default | |---|---| | `registration_allowed` (burn) | On | | `network_pow_registration_allowed` (PoW) | Off | The chain rejects turning off the last enabled route, so to move from PoW back to burn, turn burn on first. This works on both Null and Yuma subnets. Root stays burn-only. ```bash btcli hparams set --netuid 123 --name network_pow_registration_allowed --value true btcli hparams set --netuid 123 --name registration_allowed --value false btcli subnets register --netuid 123 --pow --yes ``` PoW difficulty moves with demand, the same way the burn price does: | Item | Rule | |---|---| | After a PoW registration | Difficulty × `burn_increase_mult` (default 1.26) | | Every block | Decays toward its floor using `burn_half_life` (default 360 blocks) | | Burn price | Moves only on burn registrations. PoW does not touch it | | PoW switched off | Difficulty keeps decaying, so turning PoW back on does not reset it | ## Commit reveal on Null Commit reveal works on Null subnets with a larger payload: up to 32 KiB per commit, against 5,000 bytes on Yuma. Each Null subnet's commit queue is capped at 64 KiB and 64 commits per epoch, shared across mechanisms. ## Also in spec 474 A child hotkey can have at most **100 parents** per subnet. ## Known limits The PR's own cost notes (`.maintain/null-4k-cost.md`) measured one Null epoch at 4,096 UIDs at a charged weight of 4.9 to 7.0 seconds, above the 4-second block limit. Capacity was set to 2,500 UIDs instead. > [!NOTE] > **Sources:** subtensor `main` at merge commit `02214123e` (spec 474): `subnets/mechanism.rs` (`do_set_epoch_consensus`, `NULL_UID_BUDGET`), `epoch/run_epoch.rs` (Null epoch, `null_validator_winner`), `subnets/uids.rs` (`NULL_PRUNING_BATCH`), `subnets/registration.rs` (PoW difficulty), `staking/set_children.rs` (`MAX_PARENTS_PER_CHILD`), `lib.rs` (commit limits), `admin-utils/src/lib.rs`. Finney spec read on two RPC endpoints, 2026-10-06. --- # The emission gate (spec 440) Every block, the chain hands out TAO emission and each subnet competes for a slice. _Source: https://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://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 the demand share of the **32nd-largest subnet**, recomputed every **360 blocks**: 1. Sort all subnets with positive demand **largest → smallest**. 2. θ is the share of the subnet at rank **N = 32** (`EmissionBarRank`). 3. If fewer than 32 subnets have demand, θ is the smallest positive share, so every subnet passes. Rank mode keeps exactly the top 32 subnets at or above the gate midpoint as the demand distribution shifts. Only subnets with demand count, so spinning up empty subnets can't move the bar. Setting `EmissionBarRank` to 0 switches the chain to **quantile mode**: walk down the sorted shares, accumulating them, and stop when the running total crosses `EmissionBarQuantile` (q, default 0.61). Rank mode overrides q whenever N > 0, and N is 32 on mainnet. ## 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. - **Three root knobs.** `N` (`sudo_set_emission_bar_rank`, default 32, bar position), `q` (`sudo_set_emission_bar_quantile`, default 0.61, used only when N = 0) and `h` (`sudo_set_emission_gate_exponent`, default 3, cliff sharpness) are all root-only. A change to any of them 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), in quantile mode before rank mode existed: 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://taostats.io/docs/concepts/protocol-changes/price-based-emission-shares) · [Tao Emission](https://taostats.io/docs/concepts/how-emission-works/tao-emission) · [Subnet Emissions](https://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://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 whole payment is swapped TAO → alpha through the subnet pool at the market price, in one fill-or-kill swap that fails if the price would go more than 5% above spot. The `p` share of the alpha bought is what'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://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. --- # Superellipse pools (PR #3211) Subnet pools move from the balancer curve to a bounded ellipse. Price is unchanged at the switch; balances no swap can reach move to a per-subnet lending vault. _Source: https://taostats.io/docs/concepts/protocol-changes/superellipse-pools_ _Last reviewed: 2026-10-07_ > [!WARNING] > **Not live on mainnet yet** > > This page describes [subtensor PR #3211](https://github.com/RaoFoundation/subtensor/pull/3211) (open, commit `7f634b4`). Finney runs spec 473. Loans from the lending vault are covered in [Shorts and longs](https://taostats.io/docs/concepts/protocol-changes/shorts-and-longs). ## What changes Every subnet pool gets a new pricing rule. At the switch: - the price is the same; - small swaps move the price by the same amount as today; - big swaps move the price more than they do today; - there is a hard top and bottom price that no swap can pass. The balancer curve runs forever in both directions. The new curve is a section of an ellipse and stops at two fixed points. Superellipses are a family of curves; the chain fixes `n = 2`, so the curve is a plain ellipse. Because the curve stops, part of each pool can never be paid out by any swap. That part moves out of the pool into a **lending vault**. No new TAO or alpha is created. | Name | What it is | |---|---| | Trading pool | The pool swaps trade against. Today's pool, with less in it. | | Lending vault | A separate account per subnet. It holds the balances swaps can't reach and lends them out. | | Shorts / longs | Loans from the vault. A short borrows alpha against TAO; a long borrows TAO against alpha. | ![Pool balances: the balancer curve today vs the bounded ellipse](https://taostats.io/images/docs/concepts/superellipse-pool-curves.png) The chart is drawn at 50:50 weights. Every subnet runs at 50:50 (128 subnets checked on chain, 2026-10-07). ## How the curve is set Each pool stores four numbers: an alpha scale, a TAO scale, and a centre point (one alpha value, one TAO value). The pool balances always sit on an ellipse around that centre, and the centre sits beyond the balances. | Number | Set from | At 50:50 | |---|---|---| | Alpha scale | Pool alpha × 2 × weight | Equals pool alpha | | TAO scale | Pool TAO × 2 × (1 − weight) | Equals pool TAO | | Centre (alpha) | Pool alpha + alpha scale | 2 × pool alpha | | Centre (TAO) | Pool TAO + TAO scale | 2 × pool TAO | - **Fixed at the switch.** Swaps don't change the four numbers. There is no call to tune pool depth. - **Same shape everywhere.** The scales come from the current weight, and every weight is 50:50. - **Emission shifts the centre.** Emission adds TAO and alpha to the pool and moves the centre by the same amounts. Price, small-swap moves and the price limits stay as they were: emission does not make the pool deeper. ### Price limits | End | Price | Reached when | |---|---|---| | Top (buying) | Infinite | Pool alpha falls to about 59% of its level at the switch | | Bottom (selling) | Zero | Pool TAO falls to about 59% of its level at the switch | A swap must finish strictly inside these ends. A swap that would reach an end fails. ### The switch - At the switch, the balances outside the curve's reach move to that subnet's vault. Vault funding happens once: a subnet that already has a vault is skipped, so later emission stays in the trading pool, beyond the reach of swaps. - Up to 256 vaults. All 128 current subnets fit. - Root and empty pools are left out. - Lending turns on only after every pool has switched. ## Balancer vs ellipse | | Balancer (today) | Ellipse | |---|---|---| | Price at the switch | — | Same | | Small swaps | — | Same move | | Big swaps | Price moves less | Price moves more | | Buying | Never runs out; price rises forever | Price infinite at a fixed point | | Selling | Price nears 0, never reaches it | Price is 0 at a fixed point | | Most alpha one buy can take | Approaches 100% | 41.4% of the pool at the switch | | Most TAO one sell can take | Approaches 100% | 41.4% of the pool at the switch | | Balances swaps can't reach | None | About 59% of each side, held in the vault | | Emission | Lands in the pool and can be swapped | Shifts the centre; the added depth can't be swapped | ## Worked numbers At 50:50, from the pool at the switch, swap fees left out. **Buying alpha with TAO** | TAO in (% of pool TAO) | Balancer: alpha out | Balancer: price | Ellipse: alpha out | Ellipse: price | |---|---|---|---|---| | 1% | 0.99% | ×1.02 | 0.99% | ×1.02 | | 10% | 9.1% | ×1.21 | 9.1% | ×1.21 | | 25% | 20.0% | ×1.56 | 19.9% | ×1.60 | | 50% | 33.3% | ×2.25 | 32.3% | ×2.65 | | 75% | 42.9% | ×3.06 | 39.2% | ×5.57 | | 90% | 47.4% | ×3.61 | 41.1% | ×14.1 | | 100% | 50.0% | ×4.00 | Not possible | Infinite | **Selling alpha for TAO** | Alpha in (% of pool alpha) | Balancer: TAO out | Balancer: price | Ellipse: TAO out | Ellipse: price | |---|---|---|---|---| | 1% | 0.99% | ×0.98 | 0.99% | ×0.98 | | 10% | 9.1% | ×0.83 | 9.1% | ×0.83 | | 25% | 20.0% | ×0.64 | 19.9% | ×0.63 | | 50% | 33.3% | ×0.44 | 32.3% | ×0.38 | | 75% | 42.9% | ×0.33 | 39.2% | ×0.18 | | 90% | 47.4% | ×0.28 | 41.1% | ×0.07 | | 100% | 50.0% | ×0.25 | Not possible | 0 | Up to about 10% of the pool the two curves agree. Past 25% the ellipse moves the price more, and much more near the ends. ## The lending vault The vault holds the unreachable balances: TAO as a balance, alpha as stake. Borrowers draw from the vault, never the trading pool. Total borrowing in each asset is capped at 10% of the vault. See [Shorts and longs](https://taostats.io/docs/concepts/protocol-changes/shorts-and-longs). ## When a subnet is deregistered This applies only when a subnet is removed from the network. 1. New loans and interest stop at the removal block. 2. Shorts settle against their locked TAO and sale proceeds, at the higher of spot and the 24-hour average. The debt returns to the vault; any surplus goes to the owner; any shortfall is booked as a loss. 3. Everything in the vault that isn't lent out moves back into the trading pool, TAO and alpha. 4. Alpha holders are paid from the trading pool's TAO, as today. 5. Longs settle last, from what their alpha was paid. A long owing 50 τ against a 70 τ payout repays 50 τ and gets 20 τ back. With a 20 τ payout, the chain takes 20 τ and books a 30 τ loss. Nothing is taken from the borrower's other funds. 6. The netuid can't be reused until every loan record is cleared. So the roughly 59% held in the vault is paid out to alpha holders at removal, less anything still lent out. TAO recovered from longs is kept apart from the holders' payout, so it isn't counted twice. ## What it means for Taostats data | Area | Change | |---|---| | Pool depth | At the switch, pool TAO and pool alpha drop by about 59% while price stays the same. The moved balances sit in vault accounts. | | Alpha in / out | Alpha moved to the vault becomes stake, so alpha out rises by the amount alpha in falls. | | Total stake | TAO moved to the vault leaves total stake. | | Price-impact quotes | The balancer formula matches up to about 10% of the pool. Past that it understates the move and allows swaps the chain rejects. | | Swap limits | The most alpha a buy can take and the most TAO a sell can take, fixed until the pool moves. | | Emission | Shown reserves grow with emission, but the extra can't be swapped, so reserves overstate real depth more over time. | Storage names and affected API fields are not yet confirmed on chain; they are checked once the PR reaches a testnet. Source: [Superellipse pools (Rufus)](https://s3.hippius.com/rufus/public/superellipse-pools.html) · [PR #3211](https://github.com/RaoFoundation/subtensor/pull/3211) --- # Shorts and longs on subnet alpha (PR #3211) Borrow alpha against TAO (a short) or TAO against alpha (a long) from a subnet's lending vault: 25% max loan, 100% annual interest burned, no price liquidation. _Source: https://taostats.io/docs/concepts/protocol-changes/shorts-and-longs_ _Last reviewed: 2026-10-07_ > [!WARNING] > **Not live on mainnet yet** > > This page describes [subtensor PR #3211](https://github.com/RaoFoundation/subtensor/pull/3211) (open, commit `7f634b4`). Finney runs spec 473. Loans come from the lending vault created by [superellipse pools](https://taostats.io/docs/concepts/protocol-changes/superellipse-pools). ## Terms | Term | Meaning | |---|---| | Trading pool | The subnet's swap pool, on the ellipse curve. | | Lending vault | A separate per-subnet store of TAO and alpha. All loans come from here. | | Short | Lock TAO, borrow alpha, the chain sells it. You gain if the alpha price falls. | | Long | Lock alpha, borrow TAO you can spend. | | Collateral | What you lock: TAO for a short, alpha for a long. | | Loan record | The chain's record of one open short or long. One per coldkey per subnet. | ## Where loans come from The ellipse curve leaves TAO and alpha in each pool that no swap can reach. The upgrade moves that into the lending vault; no new tokens are created ([how](https://taostats.io/docs/concepts/protocol-changes/superellipse-pools#the-lending-vault)). Loans never come out of the trading pool. Lending starts only once the pool switch completes on every subnet. Governance (root) can pause new loans; repaying, collection and settlement stay available. ## Rules | Rule | Value | |---|---| | Max loan | 25% of collateral value | | Leverage | None | | Interest | 100% a year on the loan's opening value | | Where interest goes | The TAO burn address. Total issuance is not reduced. | | Opening or closing fee | None | | Price-triggered liquidation | None | | Cap per subnet | Loans of each asset ≤ 10% of the lending vault | | Max loan records | 128 per subnet, 256 chain-wide | | Max subnets with a vault | 256 | | Reference price | 24-hour moving average | Interest is fixed at opening, accrues per block, is paid from your collateral and is collected weekly. The burn address is the chain's standard one, used by other TAO burns. It is derived from a fixed ID with no private key, so nobody can spend from it. The TAO stays in that account and still counts in total issuance; it is not recycled. The one exception: amounts too small to create an account are recycled. ## A short, step by step Example from the PR: lock 1,000 τ. | Step | What happens | |---|---| | Open | Borrow alpha worth up to 250 τ, say 700 α. The chain sells it at once and locks the TAO it gets. | | While open | The debt stays 700 α. Interest is 250 τ a year, about 4.79 τ a week, taken from your 1,000 τ. | | Close | The chain buys back 700 α with your locked TAO and returns it to the vault. You get the remaining TAO. | | Close, other way | Repay the 700 α from your own hotkey instead. No buyback. | The 1,000 τ covers about four years of interest if nothing else happens. If the alpha price rises too far, the buyback can't be paid for and the close fails, leaving the loan record unchanged. You can still close by repaying the alpha yourself. Our own arithmetic: about 1,250 τ is locked (1,000 τ plus 250 τ of sale proceeds), so the price would need to rise roughly 5× before a buyback fails, less interest already paid and price impact. ## A long, step by step | Step | What happens | |---|---| | Open | Lock alpha from a hotkey. Receive TAO worth up to 25% of it, to spend however you like. | | While open | Interest is taken from the locked alpha. The chain sells that alpha in the trading pool and sends the TAO to the burn address. | | Close | Repay the TAO you borrowed. Your remaining alpha returns to the same hotkey. | ## When the collateral runs out There is no liquidation on price. A loan ends early only when its collateral can no longer pay interest. The chain then closes it and keeps what's left; anything it can't recover is booked as a loss. The loan can't be reopened. The PR states plainly that the high interest and small loan size do not guarantee every loan is repaid. ## When a subnet is deregistered - New loans stop and interest freezes. - Shorts settle at the higher of spot and the 24-hour average. Any surplus goes to the owner; any shortfall is booked as a loss. - What shorts repaid, plus the vault's unlent TAO and alpha, go back into the trading pool. - Alpha holders are paid from the trading pool's TAO, as today. - Longs settle last. The payout repays the loan first and the rest goes to the owner: 50 τ owed against a 70 τ payout leaves 20 τ for the owner. A 20 τ payout leaves a 30 τ loss, and the owner is not chased for it. Full detail: [Superellipse pools — when a subnet is deregistered](https://taostats.io/docs/concepts/protocol-changes/superellipse-pools#when-a-subnet-is-deregistered). ## btcli ```bash # Lock 700 free alpha from this hotkey and receive transferable TAO. btcli lending open --netuid 64 --side long --collateral 700 --hotkey -w mywallet # Repay the original debt and release remaining collateral. btcli lending close --netuid 64 -w mywallet # A short can instead repay with alpha already held on its saved hotkey. btcli lending close --netuid 64 --repay-from-wallet -w mywallet # List all positions on a subnet, or one owner's position. btcli lending list --netuid 64 btcli lending list --netuid 64 --coldkey ``` ## What it means for Taostats data - **Loan pages:** all open loan records, closed ones, and a per-subnet tab. Columns: collateral, debt, interest paid, weeks of interest left. There is no "underwater" state. - **Vault per subnet:** TAO and alpha in the vault, amount lent, and room left under the 10% cap. - **Burn tracking:** interest is a new source of TAO sent to the burn address. It shows as transfers into that account plus a per-subnet interest-burned event, not as a drop in issuance. - **Pool numbers:** see [Superellipse pools](https://taostats.io/docs/concepts/protocol-changes/superellipse-pools#what-it-means-for-taostats-data). > [!NOTE] > **Previously:** an earlier shorting design (PR #2764/#3135) lent from the trading pool, allowed up to 1.5× on longs, charged 52% a year on shorts and recycled interest. PR #3211 replaces it. Source: [Shorts and longs (Rufus)](https://s3.hippius.com/rufus/public/shorts-and-longs.html) · [PR #3211](https://github.com/RaoFoundation/subtensor/pull/3211) --- # Subnets Subnets: Subnet architecture, Subnet pools, Subnet parameters, Subnet registration, Subnet deregistration, Subnet owner, Subnet owner startup guide, Subnet… _Source: https://taostats.io/docs/concepts/subnets_ _Last reviewed: 2026-09-15_ - [Subnet architecture](https://taostats.io/docs/concepts/subnets/subnet) - [Subnet pools](https://taostats.io/docs/concepts/subnets/subnet-pools) - [Subnet parameters](https://taostats.io/docs/concepts/subnets/subnet-parameters) - [Subnet registration](https://taostats.io/docs/concepts/subnets/subnet-registration) - [Subnet deregistration](https://taostats.io/docs/concepts/subnets/subnet-deregistration) - [Subnet owner](https://taostats.io/docs/concepts/subnets/subnet-owner) - [Subnet owner startup guide](https://taostats.io/docs/concepts/subnets/subnet-owner-startup-guide) - [Subnet Emissions (TAO / Pool)](https://taostats.io/docs/concepts/subnets/subnet-emissions) - [Subnet Emissions (Alpha)](https://taostats.io/docs/concepts/how-emission-works/split-alpha-out) - [Subnet Mechanisms](https://taostats.io/docs/concepts/subnets/subnet-mechanisms) --- # Subnet architecture The Bittensor network's primary division is into a group of subnets. _Source: https://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://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: * A subnet can run up to 2 mechanisms. Root can raise that network-wide limit (`MaxMechanismCount`) to a hard cap of 16. * 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 [subnet hyperparameters](https://taostats.io/docs/new/subnets/get-subnets-hyperparameters) endpoint, via the `mechanism_count` (number of mechanisms) and `mechanism_emission_split` (per-mechanism emission distribution) fields. ### Mechanism architecture Subnets can have 256 [neurons](https://taostats.io/docs/start-here/glossary#neuron) (netuids 0 and 1 are exceptions to this rule), set in the subnet [hyperparameters](https://taostats.io/docs/concepts/subnets/subnet-parameters). 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://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://taostats.io/docs/concepts/validators/validation) * [Validator (Persona)](https://taostats.io/docs/concepts/validators/validator) * [Emissions for Validators](https://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://taostats.io/docs/start-here/glossary#emission). * [Miner (Architecture)](https://taostats.io/docs/concepts/miners/mining) * [Miner (Persona)](https://taostats.io/docs/concepts/miners/miner) * [Emission for Miners](https://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://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://taostats.io/docs/concepts/subnets/subnet-pools) is seeded from the registration cost: the whole lock cost is paid into the pool as TAO, and a matching amount of alpha is minted to set the opening price. Nothing 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. The whole lock cost is paid into the [Subnet Pools](https://taostats.io/docs/concepts/subnets/subnet-pools). You can determine the current price using the [Bittensor CLI](https://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://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://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://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://taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha) as subnets mature. * Under [Root Reborn](https://taostats.io/docs/concepts/protocol-changes/root-reborn/explainer), root dividends are handled through [validator baskets](https://taostats.io/docs/concepts/staking/root-validator-baskets) and redeemed with a manual `claim_root`. ## Related * [Staking in dTao](https://taostats.io/docs/concepts/staking/staking-in-dtao) * [Root Validator Baskets](https://taostats.io/docs/concepts/staking/root-validator-baskets) * [Emissions: Root vs. Alpha Stake](https://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://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://taostats.io/docs/understanding-taostats/subnets/subnets) * **Subnet pools & pricing:** [Subnet Pools](https://taostats.io/docs/concepts/subnets/subnet-pools) ## Related * [Subnets](https://taostats.io/docs/understanding-taostats/subnets/subnets) * [Subnet emission overview](https://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://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://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://taostats.io/docs/concepts/tokenomics/tao#distribution-of-emitted-tao) * [Alpha Emission](https://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://taostats.io/docs/concepts/subnets/subnet-registration): the whole lock cost is paid in as TAO (`tao_in`), and a matching amount of alpha is minted (`alpha_in`) to set the opening price. Nothing 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://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 | legacy; stored but not used by the current epoch | | `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) | fixed | fixed at 65535 (no cap); not settable | | `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 | legacy; no longer used for subnet registration pricing | | `activity_cutoff` | blocks (12s) | ✅ yes | legacy absolute value; superseded by `activity_cutoff_factor` | | `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 | disabled | PoW registration is removed; setting it always fails | | `target_regs_per_interval` | integer | sudo only | legacy on subnets; only the root network still enforces it | | `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 | legacy; no longer used for subnet registration pricing | | `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 | read-only | reported value: 3 if `yuma3_enabled`, else 2 | | `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://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**: Defaults to 10. Rho is still stored and reported per subnet, but the current Yuma epoch doesn't read it. It has no effect on emissions or consensus. * **kappa**: Defaults to 32767 (0.5). Kappa is the stake majority used for consensus. For each miner, Yuma takes the stake-weighted median of validator weights at the κ point: the highest weight that validators holding at least κ of the active stake agree on. Validator weights above that consensus value are clipped. Only root can change it. * **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**: Fixed at 65535 (1.0) on every subnet, so a validator can put its whole weight on one miner. It can't be changed. * **Tempo**: Blocks between epochs. New subnets start at 360 (about 72 minutes). The subnet owner can set any value from 360 to 50,400 blocks, at most once per 360 blocks; root can set any value. Changing tempo restarts the epoch cycle. * **min\_difficulty / max\_difficulty / difficulty**: Left over from proof-of-work registration, which has been removed. All neuron registration is burned registration, so these values have no effect. * **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. * **Registration price (`burn`, `burn_increase_mult`, `burn_half_life`)**: The cost to register a neuron goes up by `burn_increase_mult` after every registration and decays every block with a half-life of `burn_half_life` blocks. It always stays between `min_burn` and `max_burn`. `adjustment_interval` and `adjustment_alpha` are legacy settings that no longer affect subnet registration price. * **activity\_cutoff\_factor**: Sets the activity cutoff in thousandths of a tempo: cutoff blocks = factor × tempo / 1000. The default of 13,889 gives 5,000 blocks at tempo 360. A validator that hasn't set weights within the cutoff is treated as inactive, and its weights are ignored by consensus. The subnet owner can set it from 1,000 to 50,000 (1 to 50 tempos). The older absolute `activity_cutoff` value is superseded by the factor. * **registration\_allowed**: Only root can change this. When registration is off, no one can register a neuron on the subnet, and the subnet receives no tao emission. Its share goes to the other subnets. * **target\_regs\_per\_interval**: Legacy on normal subnets: the registration price controls demand, and the only hard limit is `max_regs_per_block`. The root network still uses it, capping root registrations per root tempo at 3× this value. * **min\_burn/max\_burn**: The floor and ceiling of the neuron registration price (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)** : * The weight given to old bonds in the bond EMA, scaled so 1,000,000 = 1.0 (default 900,000 = 0.9). Each epoch, new bond = (1 − m) × this epoch's bond + m × old bond.\ A **high** value keeps bonds slow-moving: bonds take many epochs to build, and they also take many epochs to fade after a validator stops setting weights.\ A **low** value makes bonds follow current weights quickly, in both directions. With liquid alpha enabled, the smoothing factor is set per bond between `alpha_low` and `alpha_high` instead. * **Max Validators**: The number of validator permits on the subnet, given to the highest-stake hotkeys. New subnets start with 64. Only root can change it. * **Adjustment alpha:** Legacy. It no longer affects the subnet registration price; see `burn_increase_mult` and `burn_half_life`. * **Commit Reveal Period**: Weights are encrypted for this many epochs (tempos) before auto-reveal, to prevent [Weight Copying](https://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://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://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://taostats.io/docs/new/subnets/get-subnets-registration-cost) * [Get Subnet Registration Cost (history)](https://taostats.io/docs/new/subnets/get-subnets-registration-cost-history) Or view the historical chart on the [Subnet Home](https://taostats.io/subnets). ### Where the cost goes The whole registration cost is paid into the subnet's liquidity pool, with a matching amount of alpha minted to hold the price. Nothing 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://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://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://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://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. The whole lock seeds the subnet pool. 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://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://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://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://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, or recycled if the subnet's `RecycleOrBurn` setting is `Recycle` (see [Subnet Owner Neuron](https://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://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://taostats.io/docs/concepts/subnets/subnet-emissions) for how emission is computed and its implications for owner self-emission. * See [Subnet Owner](https://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://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://taostats.io/docs/concepts/protocol-changes/emission-gate) and [Price-based emission shares](https://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://taostats.io/docs/concepts/how-emission-works/tao-emission), [Alpha Emission](https://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 bar θ (the demand share of the 32nd-largest subnet) 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://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://taostats.io/docs/concepts/protocol-changes/emission-gate) for θ, `h`, `N`, 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://taostats.io/docs/concepts/protocol-changes/emission-gate) for the gate, and [Price-based emission shares](https://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://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://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://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://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://taostats.io/docs/concepts/how-emission-works/split-alpha-out). For the broader emission flow, see [Subnet Emission: tao and alpha](https://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 2 mechanisms. The subnet owner sets the count with `sudo_set_mechanism_count`; root can raise the network-wide limit (`MaxMechanismCount`) to a hard cap of 16. ## 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://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://taostats.io/docs/concepts/miners/consensus-for-miners) — how `incentive` is awarded inside a mechanism. * [Dividends for Validators](https://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://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://taostats.io/docs/concepts/chain-runtime/consensus) and [Validation](https://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://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://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://taostats.io/docs/concepts/subnets/subnet-owner) can do: it changes what every miner is optimising for. ## Related * [Consensus](https://taostats.io/docs/concepts/chain-runtime/consensus) — how weights become emissions (Yuma) * [Validation](https://taostats.io/docs/concepts/validators/validation) — the validator's role in scoring * [Weight copying](https://taostats.io/docs/concepts/validators/weight-copying) — the main gaming vector * [Subnet emissions](https://taostats.io/docs/concepts/subnets/subnet-emissions) — where the rewarded emissions come from * [Subnet owner](https://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://taostats.io/docs/concepts/validators_ _Last reviewed: 2026-09-15_ - [Validation (architecture)](https://taostats.io/docs/concepts/validators/validation) - [Running a Validator](https://taostats.io/docs/concepts/validators/validator) - [Weight copying](https://taostats.io/docs/concepts/validators/weight-copying) - [Dividends for Validators](https://taostats.io/docs/concepts/validators/dividends-for-validators) - [Child & parent hotkeys](https://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://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://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://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://taostats.io/docs/concepts/validators/dividends-for-validators), [Emissions: Root vs. Alpha Stake](https://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://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://taostats.io/docs/concepts/validators/child-hotkeys) for more details. ### Weight copying [Weight Copying](https://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://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://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://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://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://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://taostats.io/images/docs/concepts/taostats-validator-subnet-data-table.png) See [Taostats: For Validators](https://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://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://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://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://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://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 consensus weights (or other validators' weights) instead of evaluating miners itself. 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. Some subnets also block weight-copying validators from their data, forcing every validator to take part. ## Responses to Weight copying: Commit Reveal [Commit Reveal](https://taostats.io/docs/concepts/chain-runtime/commit-reveal-30) is on by default on every subnet. Validators submit their weights timelock-encrypted, and the chain only decrypts and uses them `commit_reveal_period` tempos later (the subnet owner can change this period or turn Commit Reveal off). A weight copier only ever sees weights that are already stale, which costs it Vtrust and makes copying much less profitable. The Bittensor team have published a [blog post](https://blog.bittensor.com/weight-copying-in-bittensor-422585ab8fa5) and a [technical whitepaper](https://docs.bittensor.com/papers/BT-Consensus-based-Weights.pdf) on commit reveal and its effect on weight copying. --- # Dividends for Validators If a validator is judged to be out of consensus, their VTrust (validator trust) decreases. _Source: https://taostats.io/docs/concepts/validators/dividends-for-validators_ _Last reviewed: 2026-09-15_ > [!NOTE] > **How we got here** > > [Subnet Emission: tao and alpha](https://taostats.io/docs/concepts/subnets/subnet-emissions) > > [Alpha Distribution Mechanisms](https://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://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://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://taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys)). > > It is then divided into root emission (held as alpha in the validator's root basket until stakers claim it) and alpha emission — see [Emissions: Root vs. Alpha Stake](https://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://taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys) — dividing dividends to parent/child hotkeys. * [Emissions: Root vs. Alpha Stake](https://taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha) — dividing between root & alpha proportions. * [Stakeholder Emissions: Root](https://taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root) & [Stakeholder Emissions: Alpha](https://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://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://taostats.io/docs/concepts/validators/validation) and [Emission and parent hotkeys](https://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://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://taostats.io/docs/concepts/validators/validation) * [Emission and parent hotkeys](https://taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys) * [Dividends for Validators](https://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://taostats.io/docs/concepts/miners_ _Last reviewed: 2026-09-15_ - [I want to mine on Bittensor](https://taostats.io/docs/concepts/miners/i-want-to-mine-on-bittensor) - [Mining (architecture)](https://taostats.io/docs/concepts/miners/mining) - [Running a Miner](https://taostats.io/docs/concepts/miners/miner) - [Miner Emission](https://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://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://taostats.io/images/docs/concepts/taostats-mining-advice-chat-message.png) ## The Basics * [Miner (Architecture)](https://taostats.io/docs/concepts/miners/mining): Interaction to mining on Bittensor. * [Emission for Miners](https://taostats.io/docs/concepts/miners/consensus-for-miners) : How you are rewarded with emissions. * [Taostats: For Miners](https://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://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://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://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://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://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://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://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://taostats.io/docs/concepts/miners/mining) in a subnet. To mine, research all of the subnets (see the [Bittensor Subnets](https://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://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://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://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 hotkey is burned, or recycled if the subnet's `RecycleOrBurn` setting is `Recycle`. ### 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://taostats.io/docs/understanding-taostats/miners/taostats-for-miners) --- # Miner Emission How is emission calculated for Miners? _Source: https://taostats.io/docs/concepts/miners/consensus-for-miners_ _Last reviewed: 2026-09-15_ > [!NOTE] > **How we got here** > > [Subnet Emission tao and alpha](https://taostats.io/docs/concepts/subnets/subnet-emissions) > > [Distribution of alpha\_out to participants](https://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/weights) . 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, or recycled if the subnet's `RecycleOrBurn` setting is `Recycle`. See [Burning](https://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://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://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://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://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://taostats.io/docs/concepts/staking/staking-in-dtao) - [Root Validator Baskets](https://taostats.io/docs/concepts/staking/root-validator-baskets) - [Taostats for Staking](https://taostats.io/docs/concepts/staking/taostats-for-staking) - [Price Impact and Slippage](https://taostats.io/docs/concepts/staking/slippage) - [Stake weight](https://taostats.io/docs/concepts/staking/stake-weight) - [Yield](https://taostats.io/docs/concepts/staking/yield) --- # Staking in dTao Staking tao/alpha is how investors earn yield. _Source: https://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://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://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://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://taostats.io/docs/concepts/staking/root-validator-baskets)** (the short canonical reference) and the [Root Reborn explainer](https://taostats.io/docs/concepts/protocol-changes/root-reborn/explainer) and [TL;DR](https://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://taostats.io/docs/concepts/subnets/subnet-pools) into alpha. This will incur [Slippage](https://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://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://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. ### 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://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://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://taostats.io/docs/concepts/staking/slippage). --- # Taostats for Staking Understand how to read the data in order to stake your tao _Source: https://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://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://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://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://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://taostats.io/docs/concepts/validators/validator) 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://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://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://taostats.io/docs/concepts/staking/root-validator-baskets_ _Last reviewed: 2026-10-09_ Root Validator Baskets are the mechanism [Root Reborn](https://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://taostats.io/docs/concepts/protocol-changes/root-reborn/explainer) and its [TL;DR](https://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. To rebalance several positions at once, a validator submits `swap_basket_many(hotkey, legs)` — up to **64** legs, each `(origin_netuid, destination_netuid, amount, min_amount_out)`. The basket is valued once, every leg passes the same guardrails as a single swap, and the batch is atomic: if any leg fails, every leg rolls back. An empty batch fails with `BasketSwapBatchEmpty`. ### Guardrails Every `swap_basket` (and every leg of a `swap_basket_many`) 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` | | Minimum size | The TAO value in the middle of the trade must be at least the basket minimum trade size or the network minimum stake, whichever is higher. Root sets the basket minimum (`BasketMinTradeTao`), so it can change; read the current value from chain storage | `AmountTooLow` | | 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. 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. Governance sets the four dust thresholds with `sudo_set_basket_claim_dust`: | Storage | Default | |---|---| | `BasketClaimRowDustBps` | 10 bps (0.1% of NAV) | | `BasketClaimRowDustCapTao` | τ1 | | `BasketClaimSliceDustTao` | τ0.0001 | | `BasketClaimForfeitCapTao` | τ0.01 (0 turns dust skipping off) | To see what a claim will pay before you make it, call the runtime API `get_basket_claim_preview(hotkey, coldkey)`, or `get_root_basket_claim_previews(coldkey)` for everything a `claim_root` would touch. It returns your full entitlement (`accrued_tao`), what the claim pays (`redeemable_tao`), the estimated forfeit (`forfeited_tao_est`), and the rows sold versus 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, `basket_trading_status`, and dust-aware claim previews. These power basket performance, composition, and pending-claim metrics on Taostats. ## Related * [Root Reborn — full explainer](https://taostats.io/docs/concepts/protocol-changes/root-reborn/explainer) * [Root Reborn — TL;DR](https://taostats.io/docs/concepts/protocol-changes/root-reborn/tldr) * [Stakeholder Emissions: Root](https://taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root) * [Dividends for Validators](https://taostats.io/docs/concepts/validators/dividends-for-validators) * [Staking in dTao](https://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://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://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://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://taostats.io/docs/concepts/chain-runtime/mev-shield) trading ahead of your transaction on purpose), which Taostats defends against with [MEV Shield](https://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://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://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}} $$ Here `k` is the product of the two reserves before the trade (`α_pool × tao_pool`). 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://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://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://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://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://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://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://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://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://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. ## APR: Annual Percentage Rate nom/1k/24BTday is the daily yield × 1,000. To get the annual rate, divide nom/1k/24BTday by 1,000, then multiply by 365. This is a simple annual rate (APR). It doesn't assume that rewards are restaked and compound, so an APY figure for the same daily yield would be higher. --- # Tokenomics Learn how tao and alpha tokens are emitted and distributed to participants on Bittensor. _Source: https://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 recycled tao (registration costs, fees) returns to 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://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 total issuance are available from the API, for example: ```bash curl -H "Authorization: $TAOSTATS_API_KEY" \ "https://api.taostats.io/v1/tokenomics/emission?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://taostats.io/docs/concepts/staking/staking-in-dtao) for how to participate. ## In this section - [Tokenomics](https://taostats.io/docs/concepts/tokenomics/tokenomics) - [TAO](https://taostats.io/docs/concepts/tokenomics/tao) - [Alpha tokens](https://taostats.io/docs/concepts/tokenomics/alpha-tokens) - [Alpha emission](https://taostats.io/docs/concepts/how-emission-works/alpha-emission) — *see How emission works* - [Halving](https://taostats.io/docs/concepts/tokenomics/halving) - [Burning](https://taostats.io/docs/concepts/tokenomics/burning) - [Recycling](https://taostats.io/docs/concepts/tokenomics/recycling) - [Price Impact and Slippage](https://taostats.io/docs/concepts/staking/slippage) --- # Tokenomics Learn how tao and alpha tokens are emitted and distributed to participants on Bittensor. _Source: https://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://taostats.io/docs/concepts/tokenomics/tao): The emission and distribution of tao into the subnets. [Alpha Tokens](https://taostats.io/docs/concepts/tokenomics/alpha-tokens): Each subnet has a token that can be purchased with tao. [Subnet emission overview](https://taostats.io/docs/concepts/how-emission-works/split-alpha-out): Alpha emission is divided between the participants and the subnet pool. [Halving](https://taostats.io/docs/concepts/tokenomics/halving): Bittensor tokens (tao and alpha) follow the Bitcoin halving schedule. [Recycling](https://taostats.io/docs/concepts/tokenomics/recycling): Neuron registrations, fees and swap costs result in tao/alpha being recycled, [Staking](https://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 destroyed without reducing issuance. They are never emitted again. * **Recycled**: Tokens subtracted from issuance. 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://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://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://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://taostats.io/docs/concepts/how-emission-works/tao-emission)** for the full mechanic and **[Price-based subnet emission shares](https://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://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://taostats.io/docs/concepts/tokenomics/halving) --- # Alpha tokens Alpha is the generic name for subnet tokens. _Source: https://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://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://taostats.io/docs/concepts/staking/slippage) on every transaction in and out of a Subnet Pool. ## [Subnet Pools](https://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://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://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 * Neuron registration (miners & validators) is paid in tao and swapped to alpha through the pool. The alpha bought with the registration cost is recycled. ## Related * [Alpha emission](https://taostats.io/docs/concepts/how-emission-works/alpha-emission) — how `alpha_in` and `alpha_out` are minted each block. * [Subnet Pools](https://taostats.io/docs/concepts/subnets/subnet-pools) — the liquidity pool that sets the alpha price. * [Price Impact and Slippage](https://taostats.io/docs/concepts/staking/slippage) — why the quoted price isn't the exact amount you receive. * [Staking in dTao](https://taostats.io/docs/concepts/staking/staking-in-dtao) — how to stake tao into a subnet's alpha. * [Subnet emission overview](https://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://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://taostats.io/images/docs/concepts/halving-schedule.jpg) ## See also * [Alpha Emission](https://taostats.io/docs/concepts/how-emission-works/alpha-emission) — how alpha emission is calculated each block. * [Tao Emission](https://taostats.io/docs/concepts/how-emission-works/tao-emission) — how 0.5 τ/block is distributed across subnets. --- # Burning Burned tao or alpha is destroyed but still counts as issued, so it is never emitted again. _Source: https://taostats.io/docs/concepts/tokenomics/burning_ _Last reviewed: 2026-10-05_ Burned tao or alpha is destroyed. It still counts as issued, so the chain never emits it again. > [!NOTE] > **Recycled vs. burned** > > **Recycled** tao/alpha is subtracted from issuance. It is gone from circulation, and the chain can emit it again. See [Recycling](https://taostats.io/docs/concepts/tokenomics/recycling). > > **Burned** tao/alpha is destroyed without reducing issuance. It is never emitted again. > > On Bittensor, most things called a "burn" are recycles. The registration "burn" cost and transaction fees are both recycled. ## Tao Tao is burned by sending it to the chain's burn address. Total issuance does not change. This is rare. It happens only to a swap's block-author fee when the block has no known author. ## Alpha Burned alpha is removed from its holder, but the subnet's alpha issuance (`SubnetAlphaOut`) does not change. * **Subnet owner hotkey incentive**: miner emission to the owner hotkey is burned, unless the subnet's `RecycleOrBurn` setting is `Recycle`. `Burn` is the default. * **`burn_alpha`**: any staker can burn their own alpha with this extrinsic. This does not work on root. * **Swap fees with no block author**: an alpha-denominated swap fee is burned when the block has no known author. * **Root validator baskets**: basket alpha that can no longer be sold, for example on a dissolved subnet, is written off by burning. The chain emits a `BasketAlphaWrittenOff` event. See [Root validator baskets](https://taostats.io/docs/concepts/staking/root-validator-baskets). --- # Recycling Recycling removes tao or alpha from issuance so the chain can emit it again later. _Source: https://taostats.io/docs/concepts/tokenomics/recycling_ _Last reviewed: 2026-10-05_ Recycling removes tao or alpha from issuance. The tokens return to the unissued supply and can be emitted again later. > [!NOTE] > **Recycled vs. burned** > > **Recycled** tao/alpha is subtracted from issuance. It is gone from circulation, and the chain can emit it again. Recycling tao pushes the [halving](https://taostats.io/docs/concepts/tokenomics/halving) later. > > **Burned** tao/alpha is destroyed without reducing issuance. It still counts as issued, so it is never emitted again. See [Burning](https://taostats.io/docs/concepts/tokenomics/burning). ## Tao recycling Recycled tao is subtracted from `TotalIssuance`. * **Root registration**: the root registration cost is recycled directly, with no swap into alpha. * **Hotkey and coldkey swaps**: the swap cost is recycled. * **Transaction fees**: extrinsic fees are recycled, not paid to the block author. Fees paid in alpha are sold for tao from the subnet pool, and that tao is recycled. Any part of the fee that the transaction did not use is refunded to the payer in tao. * **Subnet dissolution**: any tao left on the subnet account after stakers and the owner are paid out is recycled. This includes the tao share of protocol alpha and, for newer subnets, of the pool's alpha reserve. See [Subnet Deregistration](https://taostats.io/docs/concepts/subnets/subnet-deregistration). Subnet registration does **not** recycle anything. The whole lock cost seeds the new subnet's pool. See [Subnet Registration](https://taostats.io/docs/concepts/subnets/subnet-registration). ## Alpha recycling Recycled alpha is subtracted from the subnet's alpha issuance (`SubnetAlphaOut`). * **Neuron registration**: the registration fee is paid in tao and swapped through the [subnet pool](https://taostats.io/docs/concepts/subnets/subnet-pools) into alpha. The alpha bought with the burned share is recycled. The tao stays in the pool. On subnets with [miner collateral](https://taostats.io/docs/concepts/chain-runtime/miner-collateral), the collateral share is staked to the hotkey instead of being recycled. * **Subnet owner hotkey incentive**: if the subnet's `RecycleOrBurn` setting is `Recycle`, miner emission to the owner hotkey is recycled. Otherwise it is [burned](https://taostats.io/docs/concepts/tokenomics/burning). * **Root alpha that is not sold**: when the sum of all subnets' moving alpha prices is at or below 1 tao, root's share of alpha dividends is not sold. It is recycled instead. Root's share is also recycled when no root validator on the subnet qualifies for it. * **Childkey burn**: when a parent hotkey's emission passes to a childkey owned by a different coldkey, the network's childkey-burn proportion of that emission is recycled. * **`recycle_alpha`**: any staker can recycle their own alpha with this extrinsic. This does not work on root. Alpha bought by chain buys is **not** recycled. It is held as protocol alpha (`SubnetProtocolAlpha`). See [Tao Emission](https://taostats.io/docs/concepts/how-emission-works/tao-emission). --- # How emission works Every block the chain emits TAO, mints alpha in each subnet, and distributes it down to individual stakeholders. _Source: https://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://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://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://taostats.io/docs/concepts/how-emission-works/split-alpha-out)** — owner 18%, miners 41%, validators 41%. 4. **[Parent / child hotkeys](https://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://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://taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root)** and **[alpha](https://taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-alpha)**. ## Pages in this section - [1. TAO emission](https://taostats.io/docs/concepts/how-emission-works/tao-emission) - [2. Alpha emission](https://taostats.io/docs/concepts/how-emission-works/alpha-emission) - [3. Split alpha_out (owner / miners / validators)](https://taostats.io/docs/concepts/how-emission-works/split-alpha-out) - [4. Parent / child hotkeys](https://taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys) - [5. Root vs alpha split](https://taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root-vs-alpha) - [6a. Stakeholder emissions: root](https://taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root) - [6b. Stakeholder emissions: alpha](https://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://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://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://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 whose bar θ is the demand share of the 32nd-largest subnet: 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 bar, and the root knobs (`N`, `q`, `h`), see the canonical page: **[The emission gate (spec 440)](https://taostats.io/docs/concepts/protocol-changes/emission-gate)**. For how demand itself is built, see [Price-based subnet emission shares](https://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://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://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://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://taostats.io/docs/concepts/how-emission-works)** > > How we got here: > > 1. [TAO emission](https://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://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://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://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://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://taostats.io/docs/concepts/tokenomics/halving). To learn how this 1 α is split across participants, see [Subnet emission overview](https://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://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://taostats.io/docs/concepts/tokenomics/halving) — current emission ceilings and the halving schedule. * [Tao Emission](https://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://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://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://taostats.io/docs/concepts/how-emission-works)** > > How we got here: > > 1. [TAO emission](https://taostats.io/docs/concepts/how-emission-works/tao-emission) — TAO split across subnets. > 2. [Alpha emission](https://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://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://taostats.io/docs/concepts/miners/consensus-for-miners)** receive **41%** of emissions. * **[Validators](https://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://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://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://taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root) and [alpha](https://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://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://taostats.io/docs/concepts/how-emission-works)** > > How we got here: > > 1. [TAO emission](https://taostats.io/docs/concepts/how-emission-works/tao-emission) — TAO split across subnets. > 2. [Alpha emission](https://taostats.io/docs/concepts/how-emission-works/alpha-emission) — each subnet mints `alpha_in` + `alpha_out`. > 3. [Split `alpha_out` among participants](https://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://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://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://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://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://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://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://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://taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root) / [alpha](https://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://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://taostats.io/docs/concepts/how-emission-works)** > > How we got here: > > 1. [TAO emission](https://taostats.io/docs/concepts/how-emission-works/tao-emission) — TAO split across subnets. > 2. [Alpha emission](https://taostats.io/docs/concepts/how-emission-works/alpha-emission) — each subnet mints `alpha_in` + `alpha_out`. > 3. [Split `alpha_out` among participants](https://taostats.io/docs/concepts/how-emission-works/split-alpha-out) — owner / miners / validators. > 4. [Parent / child hotkeys](https://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://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://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://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://taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-root)** * **Step 6b — [Stakeholder emissions: alpha](https://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://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://taostats.io/docs/concepts/how-emission-works)** > > How we got here: > > 1. [TAO emission](https://taostats.io/docs/concepts/how-emission-works/tao-emission) — TAO split across subnets. > 2. [Alpha emission](https://taostats.io/docs/concepts/how-emission-works/alpha-emission) — each subnet mints `alpha_in` + `alpha_out`. > 3. [Split `alpha_out` among participants](https://taostats.io/docs/concepts/how-emission-works/split-alpha-out) — owner / miners / validators. > 4. [Parent / child hotkeys](https://taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys) — aggregate each validator's dividends. > 5. [Root vs alpha split](https://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://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://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://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://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://taostats.io/docs/concepts/staking/root-validator-baskets) and [Staking in dTao](https://taostats.io/docs/concepts/staking/staking-in-dtao). See also the parallel path, [Stakeholder emissions: alpha](https://taostats.io/docs/concepts/how-emission-works/stakeholder-emissions-alpha). --- # Stakeholder emissions: alpha Stakeholders may stake on a validator in a subnet. _Source: https://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://taostats.io/docs/concepts/tokenomics/alpha-tokens). This will cause there to the [Slippage](https://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://taostats.io/docs/concepts/how-emission-works)** > > How we got here: > > 1. [TAO emission](https://taostats.io/docs/concepts/how-emission-works/tao-emission) — TAO split across subnets. > 2. [Alpha emission](https://taostats.io/docs/concepts/how-emission-works/alpha-emission) — each subnet mints `alpha_in` + `alpha_out`. > 3. [Split `alpha_out` among participants](https://taostats.io/docs/concepts/how-emission-works/split-alpha-out) — owner / miners / validators. > 4. [Parent / child hotkeys](https://taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys) — aggregate each validator's dividends. > 5. [Root vs alpha split](https://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://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://taostats.io/docs/concepts/staking/staking-in-dtao) and [Price Impact and Slippage](https://taostats.io/docs/concepts/staking/slippage). See also the parallel path, [Stakeholder emissions: root](https://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://taostats.io/docs/concepts/wallets-accounts_ _Last reviewed: 2026-09-15_ - [Wallets, coldkeys, hotkeys](https://taostats.io/docs/concepts/wallets-accounts/wallets-coldkeys-hotkeys) - [Coldkeys](https://taostats.io/docs/concepts/wallets-accounts/coldkeys) - [Hotkeys](https://taostats.io/docs/concepts/wallets-accounts/hotkeys) - [Connecting your wallet](https://taostats.io/docs/concepts/wallets-accounts/connecting-your-wallet) - [Sign a message with your wallet key](https://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://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 staking page](https://taostats.io/staking). 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://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://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://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://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://taostats.io/docs/concepts/security/securing-a-wallet) — the threat model and when to use each approach. - [Multisig, explained: tutorial](https://taostats.io/docs/concepts/security/multisig-tutorial) — how multisignature wallets work, step by step. - [Multisig: worked examples](https://taostats.io/docs/concepts/security/multisig-examples) — real multisig flows decoded from the chain. For the chain-level detail, see [Multisig extrinsics](https://taostats.io/docs/understanding-taostats/extrinsics/multisig-extrinsics) and [Proxy extrinsics](https://taostats.io/docs/understanding-taostats/extrinsics/proxy-extrinsics). --- # Coldkeys The coldkey is your wallet on the chain. _Source: https://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://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://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 moves your coldkey's balance, stake and owned subnets to a new coldkey. It takes two steps with a 5-day wait between them, so a thief who gets your mnemonic can't move your funds instantly, and you can see the swap coming: 1. **Announce.** Call `announce_coldkey_swap` with the hash of the new coldkey. This costs **0.1 TAO**, charged only on the first announcement. 2. **Wait 5 days** (36,000 blocks). 3. **Swap.** Call `swap_coldkey_announced` with the new coldkey. Its hash must match the announcement. While a swap is announced, the coldkey can't do anything except the swap calls and MEV-shield encrypted submissions. Staking, transfers and all other calls are rejected with `ColdkeySwapAnnounced`. - **Dispute.** If you didn't make the announcement, call `dispute_coldkey_swap`. This freezes the coldkey completely, including the swap, until root resets it with `reset_coldkey_swap`. - **Change or cancel.** One day after the swap becomes executable, you can re-announce to a different coldkey (no second fee) or cancel with `clear_coldkey_swap_announcement`. A disputed swap can't be cleared this way. - **Locked stake.** The swap fails if the new coldkey already has active conviction locks. ## Hotkeys Hotkeys are connected to the cold key, and used for performaing transactions on chain. See [Hotkeys](https://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://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://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://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://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://taostats.io/images/docs/concepts/taostats-polkadot-connection-request-dialog.png) 5. Click connect and enter your password ## Troubleshooting wallet connectivity [Stake troubleshooting](https://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://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://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://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, MEV shield, Node registration, Miner collateral, EVM… _Source: https://taostats.io/docs/concepts/chain-runtime_ _Last reviewed: 2026-09-15_ - [Chain architecture](https://taostats.io/docs/concepts/chain-runtime/chain-architecture) - [Conviction](https://taostats.io/docs/concepts/chain-runtime/conviction-v2) - [Extrinsics and events](https://taostats.io/docs/concepts/chain-runtime/extrinsics-and-events) - [Yuma Consensus](https://taostats.io/docs/concepts/chain-runtime/consensus) - [Commit Reveal](https://taostats.io/docs/concepts/chain-runtime/commit-reveal-30) - [MEV shield](https://taostats.io/docs/concepts/chain-runtime/mev-shield) - [Node registration](https://taostats.io/docs/concepts/chain-runtime/node-registration) - [Miner collateral](https://taostats.io/docs/concepts/chain-runtime/miner-collateral) - [EVM contracts](https://taostats.io/docs/concepts/chain-runtime/evm-contracts) - [Run a local chain](https://taostats.io/docs/concepts/chain-runtime/deploy-a-dtao-chain) - [RPC connection to the chain](https://taostats.io/docs/concepts/chain-runtime/rpc-connection-to-the-chain) --- # Chain architecture How does the Bittensor Chain work? _Source: https://taostats.io/docs/concepts/chain-runtime/chain-architecture_ _Last reviewed: 2026-09-15_ How does the Bittensor Chain work? * [Yuma Consensus](https://taostats.io/docs/concepts/chain-runtime/consensus) * [Smart Contracts with EVM](https://taostats.io/docs/concepts/chain-runtime/evm-contracts) * [Commit Reveal](https://taostats.io/docs/concepts/chain-runtime/commit-reveal-30) * [Parent/Child Hotkeys](https://taostats.io/docs/concepts/how-emission-works/emission-parent-hotkeys) * [Extrinsics](https://taostats.io/docs/concepts/chain-runtime/extrinsics-and-events) * [List of all Extrinsics](https://taostats.io/docs/understanding-taostats/extrinsics/list-of-all-extrinsics) * [Multisig extrinsics](https://taostats.io/docs/understanding-taostats/extrinsics/multisig-extrinsics) * [Batch Extrinsics](https://taostats.io/docs/understanding-taostats/extrinsics/batch-extrinsics) * [Run a local chain](https://taostats.io/docs/concepts/chain-runtime/deploy-a-dtao-chain) * [Sign a message with your wallet key](https://taostats.io/docs/concepts/wallets-accounts/sign-a-message-with-your-wallet-key) --- # Conviction Conviction measures how long alpha has been locked to a hotkey. It decides who can take over a subnet after its first year. _Source: https://taostats.io/docs/concepts/chain-runtime/conviction-v2_ _Last reviewed: 2026-10-05_ ## 1. What is conviction? When you lock alpha to a hotkey on a subnet, the lock builds **conviction**: a score that grows the longer the alpha stays locked. Conviction is summed per hotkey, and the hotkey with the most conviction can take over ownership of a subnet that is more than a year old (see [Subnet king](#7-subnet-king-mechanism)). Conviction exists to: - Reward long-term alignment over short-term speculation - Enable subnet ownership transitions through the **subnet king** mechanism - Create skin-in-the-game for subnet owners and their backers ## 2. How locking works You lock alpha with the `lock_stake(hotkey, netuid, amount)` extrinsic: - **One lock per coldkey per subnet.** Each coldkey has a single lock on each subnet, pointing at one hotkey. - **Lock to a hotkey.** The locked alpha counts towards that hotkey's conviction. This is usually the subnet owner's hotkey, or the hotkey of someone building conviction to challenge for ownership. - **Top-ups must match.** Further locks on the same subnet must name the same hotkey, or they fail with `LockHotkeyMismatch`. Use `move_lock` to change hotkey. - **You lock stake you already hold.** Your total alpha on the subnet (across all hotkeys) must cover the lock, or it fails with `InsufficientStakeForLock`. - **Locks decay by default.** Locked alpha unlocks gradually unless you call `set_perpetual_lock(netuid, true)`. > [!NOTE] > **Conviction locking and staking are separate — you can do both with the same alpha** > > Conviction locking (via `lock_stake`) and regular [staking](https://taostats.io/docs/concepts/staking/staking-in-dtao) don't have to point at the same hotkey. You can **lock to the subnet owner's hotkey** to build conviction for the owner, while **staking the same alpha to a different, higher-performing hotkey** (for example, a Taostats validator). The lock limits how much alpha you can unstake on the subnet; it doesn't move your stake. ## 3. Two types of locks ### Decaying locks (default) A new lock decays unless you opt out: - `locked_mass` decays exponentially at `UnlockRate`. Half of it unlocks in about **90 days**. - `conviction` grows while the alpha is still locked, peaks after about **71 days**, then falls as the locked mass runs down. - As the lock decays, the unlocked part becomes unstakable again. Nothing has to be claimed. ### Perpetual locks Call `set_perpetual_lock(netuid, true)` to stop the decay: - `locked_mass` stays constant. - `conviction` grows towards `locked_mass`: 50% after about **30 days**, 87.5% after 90 days. - None of the locked alpha can be unstaked. Call `set_perpetual_lock(netuid, false)` to return to decay. ### Locks on the subnet owner hotkey A lock that points at the subnet owner hotkey gets **instant conviction**: its conviction always equals its `locked_mass`. It can be perpetual or decaying like any other lock. ## 4. The numbers ### System parameters Time constants are in blocks (7,200 blocks ≈ 1 day). | Parameter | Live value (blocks) | Time constant | Half-life | Meaning | |---|---:|---:|---:|---| | `UnlockRate` | 934,866 | ~130 days | ~90 days | How fast a decaying lock's `locked_mass` runs down | | `MaturityRate` | 311,622 | ~43 days | ~30 days | How fast conviction catches up with locked mass | `UnlockRate` is at its code default. `MaturityRate` is set on chain to 311,622; its code default is 934,866. ### Conviction growth (perpetual lock) | Days elapsed | Conviction (% of `locked_mass`) | |---:|---:| | 0 | 0.0% | | 7 | 14.9% | | 30 | 50.0% | | 60 | 75.0% | | 90 | 87.5% | | 120 | 93.8% | | 180 | 98.4% | ### Locked-mass decay (decaying lock) | Days elapsed | Locked mass remaining | |---:|---:| | 0 | 100.0% | | 30 | 79.4% | | 60 | 63.0% | | 90 | 50.0% | | 120 | 39.7% | | 180 | 25.0% | | 365 | 6.0% | ## 5. Worked example **Scenario:** a coldkey holding 10,000 alpha on a subnet locks all of it to a hotkey. ### Default (decaying) lock | Days | Locked mass | Conviction | Can unstake | |---:|---:|---:|---:| | 0 | 10,000 | 0 | 0 | | 30 | 7,937 | 4,406 | 2,063 | | 60 | 6,300 | 5,699 | 3,700 | | 90 | 5,000 | 5,625 | 5,000 | | 120 | 3,969 | 5,015 | 6,031 | | 180 | 2,500 | 3,516 | 7,500 | | 365 | 601 | 899 | 9,399 | Unstakable amount = total alpha on the subnet − current `locked_mass`. ### Perpetual lock, then back to decay With `set_perpetual_lock(netuid, true)`, locked mass stays at 10,000 and conviction reaches 9,998 after a year, with nothing unstakable. If the coldkey then calls `set_perpetual_lock(netuid, false)`: | Days after switching | Locked mass | Conviction | Can unstake | |---:|---:|---:|---:| | 0 | 10,000 | 9,998 | 0 | | 30 | 7,937 | 9,404 | 2,063 | | 90 | 5,000 | 6,875 | 5,000 | | 180 | 2,500 | 3,672 | 7,500 | | 365 | 601 | 901 | 9,399 | ## 6. Subnet-owner locks - **Instant conviction.** Any lock on the subnet owner hotkey has `conviction = locked_mass`, with no growth period. - **Owner-cut auto-lock is off by default.** The subnet owner or root can turn it on with `sudo_set_owner_cut_auto_lock_enabled(netuid, true)` (`OwnerCutAutoLockEnabled`). When it's on, the owner's emission cut is locked each time it is paid out, to the owner coldkey's existing lock hotkey, or to the owner hotkey if there is no lock yet. - **No initial alpha distribution.** Subnet registration gives the owner no alpha. Owner conviction comes from alpha the owner locks, or from the auto-locked owner cut when that is enabled. - **Aggregate tracking.** Locks on the owner hotkey are summed in `OwnerLock` (perpetual) and `DecayingOwnerLock` (decaying) for the subnet king calculation. ## 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. Other keys' locks (including the incumbent owner's) do not count towards 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 [subnet pools](https://taostats.io/docs/new/subnets/get-subnets-pools) endpoint exposes this exact quantity as the **`alpha_staked`** field (`GET /v1/subnets/pools?netuid=`). To check how close a subnet is to a takeover, compare a hotkey's rolled conviction against `0.18 × alpha_staked`. ### How it works 1. **Aggregate calculation:** For each hotkey, the system sums rolled conviction across all locks targeting it — `HotkeyLock + DecayingHotkeyLock`, plus `OwnerLock + DecayingOwnerLock` for the owner hotkey — 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 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 hotkey's owner aggregates → become non-owner aggregates - New owner hotkey's non-owner aggregates → become owner aggregates 4. **Instant conviction:** Locks on the new owner hotkey now get instant conviction. Coalitions work because backers lock directly to the challenger's hotkey, so their conviction lands in that hotkey's aggregate. ## 8. What you can and can't do ### ✅ Allowed - **Top up an existing lock** (same hotkey). - **Move a lock to another hotkey on the same subnet** with `move_lock(destination_hotkey, netuid)`. The lock is rolled forward first. Conviction is kept if both hotkeys belong to the same owning coldkey; otherwise it resets to zero. - **Switch between decaying and perpetual** at any time with `set_perpetual_lock`. - **Unstake alpha above the locked amount.** On a decaying lock, that headroom grows as the lock decays. - **Transfer locked stake to another coldkey**, if the recipient has opted in. Coldkeys reject locked alpha by default; the recipient calls `set_reject_locked_alpha(false)` to accept it. The lock moves with the stake, along with a proportional share of conviction (reset to zero if the hotkeys belong to different coldkeys). ### ❌ Not allowed - **Unstaking locked alpha.** Your alpha on the subnet must stay at or above `locked_mass` (`StakeUnavailable`). Miner registration collateral is held back on top of the lock. - **Moving a lock across subnets.** - **Locking to two hotkeys on one subnet** from one coldkey. - **Coldkey swap onto a coldkey with active locks.** The destination coldkey must have no active locks; the source coldkey's locks transfer to it. ## 9. Technical reference ### Storage | Storage | Key | Value | Purpose | |---|---|---|---| | `Lock` | (coldkey, netuid, hotkey) | `LockState` | Each coldkey's lock on a subnet | | `LockingColdkeys` | (netuid, hotkey, coldkey) | `()` | Reverse index of coldkeys locking to a hotkey | | `HotkeyLock` | (netuid, hotkey) | `LockState` | Sum of perpetual non-owner locks on the hotkey | | `DecayingHotkeyLock` | (netuid, hotkey) | `LockState` | Sum of decaying non-owner locks on the hotkey | | `OwnerLock` | netuid | `LockState` | Sum of perpetual locks on the subnet owner hotkey | | `DecayingOwnerLock` | netuid | `LockState` | Sum of decaying locks on the subnet owner hotkey | | `DecayingLock` | (coldkey, netuid) | `bool` | Present and `false` = perpetual. Missing = decaying (the default) | | `OwnerCutAutoLockEnabled` | netuid | `bool` | Owner-cut auto-lock; default `false` | | `UnlockRate` / `MaturityRate` | — | `u64` | Time constants in blocks | ### `LockState` structure ```rust LockState { locked_mass: AlphaBalance, // Locked alpha (decays unless perpetual) conviction: U64F64, // Conviction score last_update: u64 // Block of last roll-forward } ``` ### Roll-forward formula On every read or write, a lock is rolled forward from `last_update` to the current block. With `dt` blocks elapsed, $\tau_x$ = `UnlockRate` and $\tau_z$ = `MaturityRate`: $$ d_x = e^{-dt/\tau_x} \qquad d_z = e^{-dt/\tau_z} $$ **Perpetual lock:** $$ locked\_mass_{new} = locked\_mass_{old} \qquad conviction_{new} = d_z \cdot conviction_{old} + locked\_mass_{old} \cdot (1 - d_z) $$ **Decaying lock:** $$ locked\_mass_{new} = locked\_mass_{old} \cdot d_x \qquad conviction_{new} = d_z \cdot conviction_{old} + \gamma \cdot locked\_mass_{old} $$ $$ \gamma = \tau_x \cdot \dfrac{d_x - d_z}{\tau_x - \tau_z} \quad (\tau_x \ne \tau_z), \qquad \gamma = \dfrac{dt}{\tau_z}\, d_z \quad (\tau_x = \tau_z) $$ **Owner hotkey lock:** after rolling, `conviction = locked_mass`. ### Extrinsics - `lock_stake(hotkey, netuid, amount)` — Lock alpha to a hotkey on a subnet. New locks decay by default. - `move_lock(destination_hotkey, netuid)` — Move your lock to another hotkey on the same subnet. - `set_perpetual_lock(netuid, enabled)` — `true` stops decay; `false` returns to decay. - `set_reject_locked_alpha(enabled)` — `false` lets your coldkey receive locked alpha from transfers and coldkey swaps. - `AdminUtils::sudo_set_owner_cut_auto_lock_enabled(netuid, enabled)` — Subnet owner or root; turns owner-cut auto-locking on or off. **Previously.** Before spec 447, ownership transferred once the subnet-wide total conviction (all hotkeys combined, including the owner) reached 10% of eligible alpha. It is now an 18% bar on a single hotkey's own conviction. --- # Extrinsics and events Extrinsics are how commands are written to the chain. _Source: https://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://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 Designed to stop weight copying: validators commit timelock-encrypted weights, and the chain reveals them a set number of tempos later. _Source: https://taostats.io/docs/concepts/chain-runtime/commit-reveal-30_ _Last reviewed: 2026-10-05_ Designed to stop weight copying: validators commit timelock-encrypted weights, and the chain reveals them a set number of tempos later. ## What is Commit Reveal? Commit Reveal is designed to stop weight-copying validators. See [Weight Copying](https://taostats.io/docs/concepts/validators/weight-copying). On a subnet with Commit Reveal on, every validator's weights stay encrypted for a set number of tempos. Yuma Consensus only uses them after they are decrypted. A validator that copies weights can only see stale data, which lowers its score and makes weight copying much less profitable. ## Subnet settings Commit Reveal is **on by default** for every subnet. Three hyperparameters control it: | Hyperparameter | Default | Who can set it | Meaning | |---|---|---|---| | `commit_reveal_weights_enabled` | `true` | subnet owner or root | Turns Commit Reveal on or off for the subnet | | `commit_reveal_period` | `1` | subnet owner or root | Number of tempos between a commit and its reveal (set with `sudo_set_commit_reveal_weights_interval`) | | `commit_reveal_version` | `4` | root only | Network-wide format version; commits with any other version are rejected with `IncorrectCommitRevealVersion` | The subnet owner's changes are subject to the usual hyperparameter rate limits. ## Setting weights When Commit Reveal is on, the chain rejects plain `set_weights` and `set_mechanism_weights` calls with `CommitRevealEnabled`. Instead, validators: 1. **Encrypt locally.** The validator's client encrypts the weights with drand timelock encryption, bound to a future drand round. The Bittensor SDK and btcli do this automatically. 2. **Commit.** The validator submits the ciphertext with `commit_timelocked_weights` (or `commit_timelocked_mechanism_weights` for a specific mechanism). The chain stores it against the current epoch. 3. **Reveal.** `commit_reveal_period` tempos later, the chain decrypts the commit with the drand pulse for that round and applies the weights. There is no separate reveal transaction and no hash-compare step. When Commit Reveal is off, `commit_timelocked_weights` is rejected with `CommitRevealDisabled`, and validators use `set_weights`. ## Miner ramifications If you make changes to your miner, the resulting scores show up several tempos later: ### New miner Tempo 1: Start a miner. Validators evaluate it. Tempo 2: Validators commit their initial weights for you. Tempo 2 + `commit_reveal_period`: your initial weight appears. ### Miner crashes Tempo x: Miner crashes and stops responding to validator requests. Tempo x+1: Validators begin lowering your score. (Intervening tempos: scores continue to drop.) Tempo x+1+`commit_reveal_period`: you start seeing the dropped scores. Miners should not use validator scores to check whether their miners are up. With Commit Reveal, by the time the drop shows up, deregistration is almost certain. --- # MEV shield why do we need mev shield, and how does it work? _Source: https://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://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://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 If 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://taostats.io/images/docs/concepts/taostats-mev-transaction-log-table.png) ## MEVShield A tight limit price should be enough to stop MEV bots. MEV shield goes further: it hides your transaction until it is in a block, so there is nothing to front-run. How it works: 1. Each block producer publishes a fresh **ML-KEM-768** public key every block. The chain exposes the key to use as `NextKey`: the key of the producer two blocks ahead. 2. Your wallet signs your real transaction (for example, a stake), then encrypts the whole signed transaction to `NextKey` with ML-KEM-768 and **XChaCha20-Poly1305**. 3. The wallet submits the ciphertext in a wrapper call, `submit_encrypted`. Anyone watching the transaction pool sees only the wrapper, not what's inside. 4. The block producer who holds the matching private key decrypts your transaction and includes it in the block it produces. ### 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 MEV shield must be signed twice: * Sign the transaction * Sign the encryption wrapper. Taostats (and other providers) can sign the encryption wrapper for you, so you only enter your password once. ![Transaction confirmation panel with two checkboxes for enabling MEV shield protection and delegating submission, plus a Confirm button](https://taostats.io/images/docs/concepts/taostats-mev-shield-confirm-dialog.png) ### 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://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://taostats.io/images/docs/concepts/de952272-Screenshot_2024-09-03_at_17.40.57.jpg) All new miners & validators are placed into [immunity](https://taostats.io/docs/start-here/glossary#immunity) for a preset amount of time. The immunity period can be adjusted per subnet. Immune neurons are skipped when the chain picks a neuron to de-register, unless too few non-immune neurons are left. > [!NOTE] > **Immunity period** > > To retrieve the immunity period (in blocks), you can use the [Bittensor CLI](https://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 swapped into alpha through the subnet pool. The tao stays in the pool, and the alpha is [recycled](https://taostats.io/docs/concepts/tokenomics/recycling): it is subtracted from the subnet's alpha issuance. The registration cost 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 recycled. 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://taostats.io/docs/concepts/chain-runtime/miner-collateral) for the full mechanics. ## Neuron De-registration When a new miner/validator registers on a full subnet, the neuron with the lowest emission is de-registered. Ties go to the oldest registration, then the lowest UID. > [!NOTE] > **Immunity protects, but not absolutely.** > > - The subnet owner's hotkeys (up to `ImmuneOwnerUidsLimit`, default 1) are never de-registered. > - Immune neurons are protected only while the subnet has more than `MinNonImmuneUids` (default 10) non-immune neurons. Once it's down to that floor, the lowest-emission **immune** neuron is de-registered instead. 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://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 available on mainnet and is opt-in per subnet. > [!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 whole payment is swapped TAO → alpha through the subnet pool at the market price, in one fill-or-kill swap that fails if the price would go more than 5% above spot. The `p` share of the alpha bought is what's locked. Its TAO value floats afterward. (The moving-average price is used only to value a lock you already hold when you re-register.) - **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 (`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://taostats.io/docs/concepts/chain-runtime/conviction-v2) does: | | Conviction lock | Miner collateral | |---|---|---| | Purpose | Voluntary — builds conviction, which decides subnet ownership takeovers | Forced — registration bond | | Storage | `Lock` | `MinerCollateral` | | Unstake locked amount | blocked up to lock | blocked up to lock | | Transfer stake | follows the stake (recipient must opt in with `set_reject_locked_alpha(false)`) | 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 (`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 | — | `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://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://taostats.io/docs/concepts/chain-runtime/node-registration). --- # EVM contracts Bittensor runs an EVM: deploy and execute smart contracts, and use precompiles to transfer and stake from an EVM wallet. _Source: https://taostats.io/docs/concepts/chain-runtime/evm-contracts_ _Last reviewed: 2026-09-15_ Bittensor runs an EVM: deploy and execute smart contracts, and use precompiles to transfer and stake from an EVM wallet. ## 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://lite.chain.opentensor.ai Chain ID: 964 Currency symbol: TAO ``` ## EVM wallet/ Substrate wallet interactions With an EVM wallet such as MetaMask, you can execute smart contracts. You can also use Bittensor features directly through **precompiles**: built-in contracts at fixed addresses that call the chain's native functions. | Precompile | Address (decimal) | What it does | |---|---|---| | Balance transfer | 2048 | Send TAO from your EVM wallet to an ss58 (Substrate) address | | Staking | 2049, 2053 | Add, remove and move stake, including alpha stake on subnets | | Subnet | 2051 | Register a subnet; read and (as owner) set its hyperparameters | | Neuron | 2052 | Register a neuron, set or commit weights, serve an axon | | Proxy | 2059 | Manage proxies for your EVM-mapped account | | Metagraph, Alpha, UID lookup | 2050, 2056, 2054 | Read subnet and pool state | Other precompiles cover crowdloans, leasing, drand, ed25519/sr25519 signature checks and more. The full list is in the subtensor [precompiles](https://github.com/RaoFoundation/subtensor/tree/main/precompiles/src) source. Your Bittensor (Substrate) wallet cannot execute smart contracts directly. So how do these two types of wallets interact? ### EVM wallets on Bittensor Your EVM wallet (in MetaMask) has an alias address in Bittensor that can receive funds from "regular" Substrate wallets. The alias is derived from your EVM address (a hash of `"evm:"` plus the address), so it has no private key on the Bittensor side and can't sign Substrate transactions. Any funds 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://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://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://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 upstream subtensor docs have current guides on running smart contracts on Bittensor: [https://bittensor.com/docs/guides/evm](https://bittensor.com/docs/guides/evm) ## 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. --- # Run a local subtensor chain Run a local Bittensor subtensor chain for development, from Docker or from source. _Source: https://taostats.io/docs/concepts/chain-runtime/deploy-a-dtao-chain_ _Last reviewed: 2026-10-05_ Run a local Bittensor subtensor chain for development, from Docker or from source. The subtensor code is on GitHub: [https://github.com/RaoFoundation/subtensor](https://github.com/RaoFoundation/subtensor). The local chain runs the same runtime as mainnet, including dTAO subnets, on fast blocks. ## Option 1: Docker (quickest) ```shell docker run --rm --name local_chain \ -p 9944:9944 -p 9945:9945 \ ghcr.io/raofoundation/subtensor-localnet:devnet ``` Image tags: | Tag | Contents | |---|---| | `:devnet` | The commit deployed to devnet | | `:testnet` | The commit deployed to testnet | | `:main` (alias `:latest`) | The current main-branch candidate | | `:sha-` | A fixed commit, for reproducible CI | ## Option 2: Build from source ```shell git clone https://github.com/RaoFoundation/subtensor.git cd subtensor ./scripts/init.sh # installs the Rust toolchain and wasm target ./scripts/localnet.sh # builds the node and launches a fast-blocks localnet ``` The repository pins its Rust toolchain in `rust-toolchain.toml`, so `init.sh` installs the right version. You don't need nightly Rust. `localnet.sh` builds with the `pow-faucet` feature, so local wallets can request test TAO from the faucet. Pass `False` as the first argument (`./scripts/localnet.sh False`) to run at normal 12-second block times instead of fast blocks. ## Connect to your local chain The local node serves RPC on `ws://127.0.0.1:9944`. ```shell btcli --network local query is-fast-blocks ``` From Python: ```python import bittensor client = bittensor.Client("local") ``` Install the SDK from [https://github.com/RaoFoundation/bittensor](https://github.com/RaoFoundation/bittensor) (`pip install bittensor`). For building from source, the Alice dev account, and faucet behaviour, see the upstream [local development guide](https://bittensor.com/docs/guides/local-development). --- # RPC connection to the chain How do you extract knowledge from the Bittensor chain? _Source: https://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://taostats.io/docs/new) 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://taostats.io/docs/new/rpc) 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://taostats.io/docs/new) 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://taostats.io/docs/concepts/security_ _Last reviewed: 2026-09-15_ - [Securing a wallet: ledgers, multisig & proxies](https://taostats.io/docs/concepts/security/securing-a-wallet) - [Multisig, explained: tutorial](https://taostats.io/docs/concepts/security/multisig-tutorial) - [Multisig: worked examples](https://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://taostats.io/docs/concepts/security/securing-a-wallet_ _Last reviewed: 2026-09-15_ [Securing a wallet — ledgers, multisig & proxies (canonical document by Rufus)](https://taostats.io/docs-embeds/concepts/security/canonical/securing-a-wallet.html) --- # Multisig, explained: tutorial Multisig, explained — tutorial (canonical document by Rufus) _Source: https://taostats.io/docs/concepts/security/multisig-tutorial_ _Last reviewed: 2026-09-15_ [Multisig, explained — tutorial (canonical document by Rufus)](https://taostats.io/docs-embeds/concepts/security/canonical/multisig-tutorial.html) --- # Multisig: worked examples Multisig — worked examples (canonical document by Rufus) _Source: https://taostats.io/docs/concepts/security/multisig-examples_ _Last reviewed: 2026-09-15_ [Multisig — worked examples (canonical document by Rufus)](https://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://taostats.io/docs/concepts/legacy-deprecated_ _Last reviewed: 2026-09-15_ - [TAO flow (deprecated)](https://taostats.io/docs/concepts/legacy-deprecated/tao-flow) - [TAO emission does not add to 100](https://taostats.io/docs/concepts/legacy-deprecated/tao-emission-does-not-add-to-100) - [Best practices for installing software](https://taostats.io/docs/concepts/legacy-deprecated/a-best-practices-guide-for-safely-installing-software) - [Crypto safety: the basics](https://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://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://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](#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://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://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://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://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://taostats.io/docs/concepts/how-emission-works/tao-emission) is calculated from EMA flow. [Alpha Emission](https://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 alpha it buys is held as protocol alpha (`SubnetProtocolAlpha`). 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://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://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://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://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://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://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 (btcli) ships in the bittensor Python package, built from the subtensor repository. _Source: https://taostats.io/docs/concepts/command-line-tool_ _Last reviewed: 2026-10-05_ The Bittensor command line interface (`btcli`) lets you use the Bittensor chain from a terminal: create wallets, stake, register, set weights and send any transaction. `btcli` is part of the `bittensor` Python package. One install gives you both the Python SDK (`import bittensor`) and the `btcli` command. The SDK and CLI live in the [subtensor repository](https://github.com/RaoFoundation/subtensor/tree/main/sdk/python), alongside the chain code. Both are generated from the chain's metadata, so their commands match the live runtime. ## Installation Requires Python 3.10–3.14. ### From pip ```bash pip install bittensor ``` This installs the `btcli` command and the `bittensor` Python package together. ### From source ```bash git clone https://github.com/RaoFoundation/subtensor.git cd subtensor/sdk/python uv venv && source .venv/bin/activate uv pip install -e . ``` ## Using the CLI `btcli --help` lists the command groups, and `--help` works on every command. * `btcli query ` reads any value from the chain. `btcli query --help` lists them by topic. * `btcli tx ` sends any transaction. `btcli tx --help` lists them by pallet. Every `tx` command accepts `--dry-run`, `--yes` and `--proxy-for`. * Workflow groups wrap common tasks: `wallet`, `stake`, `subnets`, `weights`, `axon`, `proxy`, `multisig`, `crowd`, `lock`, `timelock` and `config`. * `btcli evm` covers EVM keys, funding, precompiles and contracts. If you leave out a required option, `btcli` asks for it, shows what it is about to do and waits for you to confirm. Add `--dry-run` to preview a transaction without sending it. The short aliases from older versions still work, for example `w`, `st` and `s`. ## Configuring the CLI Set your network and wallet once: ```bash btcli config set network finney btcli config set wallet my_coldkey btcli config get ``` A flag on the command overrides an environment variable, which overrides the config file. | Option | Environment variable | Meaning | | --- | --- | --- | | `--network`, `-n` | `BT_NETWORK` | `finney`, `test`, `local`, or a `ws://` endpoint | | `--wallet`, `-w` | `BT_WALLET` | Coldkey wallet name | | `--wallet-hotkey`, `-H` | `BT_WALLET_HOTKEY` | Hotkey name inside the wallet | | `--wallet-path` | `BT_WALLET_PATH` | Wallet directory | | `--json` | | Machine-readable output | | `--yes`, `-y` | | Skip confirmation prompts | The full CLI reference is at [bittensor.com/docs/cli](https://bittensor.com/docs/cli). > [!NOTE] > Previously `btcli` was a separate package (`bittensor-cli`) in its own repository. That package is superseded by `bittensor`.