Articles

424 articles across 41 topics

Wallets

View topic
  • Address Poisoning Scams How lookalike wallet addresses can mislead Bittensor users during routine wallet transactions.
  • Bittensor Wallet How a Bittensor wallet names the identity and ownership container for coldkeys, hotkeys, and stake in Bittensor operations.
  • Bittensor Wallets What a Bittensor wallet is, what it stores, and how it is used to prove identity and sign transactions on the network.
  • Coldkey and Hotkey Workstation Security How Bittensor separates permissionless devices, hotkey servers, proxy coldkeys, and primary coldkey custody when thinking about workstation risk.
  • Coldkey Swap How a coldkey swap migrates a Bittensor wallet's entire on-chain identity to a new coldkey through a staged, disputable on-chain process.
  • Coldkey Swap Announcement Delay How the coldkey swap announcement delay sets the mandatory waiting window in blocks between announcing a coldkey swap and when that swap can finalize.
  • Coldkeys (Bittensor) The security-critical key that controls TAO and stake; used for financial transactions like stake, unstake, and transfers.
  • EdDSA Cryptographic Keypairs How EdDSA cryptographic keypairs fit Bittensor wallet-key terminology.
  • Encrypting the Hotkey How encrypting a Bittensor hotkey protects local hotkey material while preserving the hotkey's operational role.
  • External Wallet How an external wallet refers to wallet software or custody outside the local Bittensor wallet path.
  • H160 Address How H160 addresses identify Ethereum-style wallets in Bittensor EVM, and why they should not be confused with SS58 coldkey or hotkey addresses.
  • Hotkey Swap How a hotkey swap moves Bittensor subnet participation from one hotkey to another hotkey owned by the same coldkey.
  • Hotkeys (Bittensor) The operational key used by miners, validators, and subnet actors to register, submit weights, and perform day-to-day on-chain actions.
  • Invalid Recovered Public Key How the InvalidRecoveredPublicKey error signals that an EVM key association recovered a valid public key, but that key did not match the claimed EVM address.
  • Ledger Hardware Wallet How a Ledger hardware wallet fits into Bittensor coldkey custody, wallet-app signing, staking, transfers, proxy setup, and address verification.
  • Local Wallet How a local wallet refers to Bittensor wallet files kept on a user's machine.
  • Mnemonic How a mnemonic represents a wallet recovery phrase in Bittensor key management.
  • Moving Stake How moving stake changes the hotkey and/or subnet that holds a staked position in a single atomic operation, used when a participant rearranges an existing staked position without withdrawing to a coldkey.
  • Multisig Wallets How a Bittensor multisig wallet distributes control of a coldkey across several signatories, requiring a threshold of approvals before an action can go ahead.
  • NaCl Format How NaCl Format fits Bittensor wallet-file security terminology.
  • Phishing How phishing tricks a Bittensor user into revealing a wallet's seed phrase, and why that recovery phrase is the prize.
  • Polkadot Vault How Polkadot Vault fits into Bittensor coldkey custody, air-gapped signing, QR transaction transport, Subtensor extrinsic support, and proxy-oriented key operations.
  • Private Key How private key names the protected side of a Bittensor cryptographic key pair used for authorization.
  • Proxy Wallets Proxy wallets let one Bittensor account perform limited actions for another, helping reduce how often a high-value wallet must be used directly.
  • Public Key How a public key fits Bittensor wallet-key terminology as the shareable side of a cryptographic keypair.
  • Pure Proxies Pure proxies are keyless Bittensor accounts used as stable stand-ins, especially in multisig designs where the people behind a shared wallet may change.
  • Regenerating a Key How regenerating a key relates to recovering Bittensor wallet key material.
  • Seed Phrase How a seed phrase names the human-readable recovery words that can restore Bittensor wallet key access.
  • Seed Phrase Security How Bittensor wallet recovery phrases relate to wallet access, loss risk, and disclosure risk.
  • Signatory How a signatory is one participant in a multisig wallet who can propose or approve actions under the wallet's threshold rule.
  • SS58 Encoded How SS58 encoded values represent public-key-derived wallet addresses in Bittensor.
  • Token Bridging How token bridging connects TAO between Substrate (SS58) and EVM (H160) account contexts on the Bittensor chain, and how vTAO represents staked TAO inside the EVM layer.
  • Transfer How transfers describe sending TAO between wallet addresses in Bittensor.
  • Transferring Stake How transferring stake changes the coldkey that owns a staked position, used when a participant reassigns staked tokens to a different coldkey.
  • Unable To Recover Public Key How the UnableToRecoverPublicKey error signals that associating an EVM address with a hotkey failed because the chain could not recover a valid public key from the submitted signature.
  • Wallet Address How wallet addresses identify public-key-derived TAO destinations in Bittensor.
  • Wallet Applications How wallet applications provide the software layer for viewing Bittensor wallet state, preparing transactions, and connecting custody devices without being the wallet identity itself.
  • Wallet Location How wallet location describes where Bittensor wallet files are stored on a user's machine.
  • Wallets, Coldkeys, and Hotkeys Understanding Bittensor wallets and the roles of coldkeys and hotkeys for security, identity, and operations.

Subnets

View topic
  • Active UID How an active UID identifies a usable participant slot within a Bittensor subnet.
  • Activity Cutoff How activity cutoff names validator inactivity tolerance before stake is masked out of Yuma Consensus, including the legacy fixed-block hyperparameter and the live activity cutoff factor setting under dynamic tempos.
  • Activity Cutoff Factor How the activity cutoff factor subnet hyperparameter expresses validator inactivity tolerance in per-mille epochs so the effective window scales with tempo.
  • Adjustment Interval How the adjustment interval subnet hyperparameter sets the block window used to recalibrate the dynamic registration burn cost against the subnet's target registration rate.
  • Admin Freeze Window How the admin freeze window blocks subnet owner operations during the final blocks of each epoch so hyperparameters cannot change just before validators submit weights.
  • Alpha Distribution Ratio How Alpha Distribution Ratio frames distributed subnet alpha against pool-injected alpha in Dynamic TAO.
  • Alpha Halving How alpha halving reduces a subnet's alpha-token emission rate at subnet-specific supply milestones.
  • Alpha High How alpha high sets the upper bound of the liquid alpha range that varies how quickly validator-miner bonds smooth based on consensus alignment.
  • Alpha Low How alpha low sets the lower bound of the liquid alpha range that varies how quickly validator-miner bonds smooth based on consensus alignment.
  • Alpha Outstanding How alpha outstanding describes subnet alpha held outside the reserve pool in Bittensor tokenomics.
  • Alpha Price How alpha price is derived from a subnet's TAO reserve and alpha reserve in Dynamic TAO.
  • Alpha Reserve How alpha reserve tracks subnet alpha held inside a subnet liquidity pool rather than outside the pool.
  • Alpha Sigmoid Steepness How the alpha sigmoid steepness subnet hyperparameter shapes how sharply liquid alpha responds to validator consensus alignment when smoothing validator-miner bonds in Yuma Consensus.
  • Alpha Tokens How Bittensor uses subnet-specific alpha tokens in emissions, staking, and subnet liquidity pools.
  • Arbitrage How arbitrageurs profit from alpha price differences across Bittensor subnet pools or between on-chain and outside markets, and how that trading keeps pool prices aligned.
  • Axon How axon names the server-side endpoint in Bittensor subnet request and response communication.
  • Bittensor Emissions How Bittensor emissions connect newly created TAO and subnet alpha tokens to subnet incentives, validators, miners, and stakers.
  • Bittensor Platform Components A concise map of Bittensor's major platform pieces: subnets, blockchain, TAO, roles, tools, and network environments.
  • Blockchain Validator vs Subnet Validator How Bittensor distinguishes network-level blockchain validators from subnet-level validators.
  • Bonds Moving Average How the bonds moving average subnet hyperparameter configures the moving-average smoothing applied to validator-miner bonds in Yuma Consensus.
  • Bonds Penalty How the bonds penalty subnet hyperparameter sets the magnitude of the consensus penalty applied when validator weights exceed the subnet consensus benchmark in Yuma Consensus.
  • Bonds Reset Enabled How the bonds reset enabled subnet hyperparameter decides whether validator-miner bonds for a hotkey can be cleared, with resets triggered through metadata commitment.
  • Burn Cost How burn cost names the dynamic recycled-TAO amount required to create a Bittensor subnet.
  • Burn Half Life How the burn half life subnet hyperparameter sets the decay horizon, in blocks, over which a subnet's dynamic registration burn cost falls back toward its floor between registrations.
  • Burn Increase Mult How the burn increase mult subnet hyperparameter raises a subnet's dynamic registration burn cost each time a registration succeeds, making registration more expensive as demand rises.
  • Coinbase How the Bittensor coinbase mechanism injects liquidity, accumulates pending emissions, and triggers Yuma Consensus every block.
  • Commit Reveal Period How the commit reveal period subnet hyperparameter sets how many tempos must elapse before committed validator weights are revealed under the commit-reveal weight scheme.
  • Commit Reveal Weights Enabled How the commit reveal weights enabled subnet hyperparameter turns on the commit-reveal weight scheme that conceals validator weights before reveal.
  • Crowdloans How a Bittensor crowdloan lets contributors collectively fund an extrinsic execution or transfer, commonly for subnet creation.
  • Dendrite How dendrite names the client-side request component used with axons in Bittensor subnet communication.
  • Deregistration How deregistration removes a low-performing Bittensor subnet entrant when subnet capacity and replacement rules apply.
  • Digital Commodities How Bittensor subnets define useful digital work for miners to produce and validators to evaluate.
  • EMA How an exponential moving average smooths values over time by weighting recent observations more heavily, the technique Bittensor uses to update validator-miner bonds across epochs.
  • EMA Price Halving Period How the EMA price halving period hyperparameter sets the halving term in a subnet's moving-price EMA, controlling how quickly that price adapts to the spot price.
  • Emission Split How a subnet's alpha emission is divided each tempo, with documented shares of 41% to miners, 41% to validators and their stakers, and 18% to the subnet owner.
  • Epoch How an epoch marks a Bittensor subnet's consensus period.
  • Hotkey Swap On Subnet Interval How the hotkey swap on subnet interval sets the per-subnet cooldown a hotkey swap must respect, the longer of the two rate limits that gate swapping a hotkey.
  • Immune Owner Uids Limit How the immune owner uids limit subnet hyperparameter caps how many neurons on a subnet may be marked as owner-immune.
  • Immunity Period How an immunity period gives a new Bittensor subnet entrant temporary protection from deregistration.
  • Incentive Mechanism How an incentive mechanism connects subnet work, validator evaluation, and emission outcomes in Bittensor.
  • Kappa How the kappa subnet hyperparameter sets the stake-weighted majority ratio Yuma Consensus uses to derive the consensus clipping threshold for miner weights.
  • Last Update How the last update value records the block of a neuron's most recent update, and how it combines with activity cutoff to decide whether the neuron is active.
  • Liquid Alpha Enabled How the liquid alpha enabled toggle decides whether a subnet uses a single fixed bond-smoothing alpha or a consensus-driven alpha that varies between the alpha low and alpha high bounds.
  • Liquidity Positions How liquidity positions supply range-based subnet liquidity around TAO and subnet alpha pools.
  • Liquidity Provider Rewards How a Bittensor liquidity provider earns trading fees from staking activity in its price range, and why it cannot earn from its own trades.
  • Lock Reduction Interval How the lock reduction interval parameter sets the block span over which the dynamic subnet creation cost halves as it decays toward the minimum lock cost.
  • Max Allowed UIDs How the max allowed UIDs subnet hyperparameter sets the ceiling on how many neurons a Bittensor subnet can hold.
  • Max Burn How the max burn subnet hyperparameter caps the dynamic TAO burn required to register a neuron on a subnet.
  • Max Registrations Per Block How the max registrations per block subnet hyperparameter named a per-block cap on neuron registrations under older registration models.
  • Max UIDs Trimming Rate Limit How the UID trimming rate limit caps how often a subnet owner can trim UIDs, locking the subnet's UID count for roughly 30 days after each trim.
  • Max Validators How the max validators subnet hyperparameter caps how many validators a subnet allows, which bounds how many validator permits it issues.
  • Mechanism Count How the mechanism count subnet hyperparameter sets how many incentive mechanisms a Bittensor subnet runs.
  • Mechanism Emission Split How the mechanism emission split subnet hyperparameter allocates emission shares across multiple mechanisms on one subnet.
  • Metagraph How the Bittensor metagraph describes subnet neuron state at a particular block height.
  • Min Allowed UIDs How the min allowed UIDs subnet hyperparameter sets the minimum UID count for a subnet and acts as the floor that owner UID trimming cannot reduce a subnet below.
  • Min Allowed Weights How the min allowed weights subnet hyperparameter sets the fewest weights a validator must assign when it submits weights on a subnet.
  • Min Burn How the min burn subnet hyperparameter sets the floor on the dynamic TAO burn required to register a neuron on a subnet.
  • Min Non Immune Uids How the min non immune uids subnet hyperparameter sets the minimum number of non-immune UIDs that must remain on a subnet.
  • Miner Deregistration How miner deregistration removes a low-performing Bittensor subnet miner from a UID slot when a subnet needs room for a new registration.
  • Miner Registration How miner registration names the process that gives a Bittensor subnet miner a UID slot so the miner can participate in subnet work and emissions.
  • Multiple Incentive Mechanisms How multiple incentive mechanisms distinguish separate evaluation systems within one Bittensor subnet.
  • Netuid How a netuid identifies a subnet context inside Bittensor.
  • Network Min Lock Cost How the network min lock cost global setting sets the floor on the TAO lock cost required to register a new subnet, separate from the dynamic cost that rises with demand.
  • Network Pow Registration Allowed Why the network pow registration allowed subnet hyperparameter is not used for neuron registration, since registration on Bittensor subnets is burn-based and always open.
  • Network Rate Limit How the network rate limit global setting paces how often a new subnet can be registered on Bittensor, expressed as the minimum block interval between successful subnet creations.
  • Network Registration Allowed How the network registration allowed global setting determines whether new neurons can register on a subnet, gating subnet admission at the network layer separate from subnet owner controls.
  • Network Tx Rate Limit Exceeded How the NetworkTxRateLimitExceeded error signals that subnet creation was attempted before the network-wide subnet-registration cooldown had elapsed.
  • Neuron How a neuron represents a registered participant inside a Bittensor subnet.
  • Off-Chain Validation Systems How off-chain validation systems describe subnet-specific miner evaluation before Bittensor consensus uses validator weight signals.
  • Owner Cut Auto Lock Enabled How the owner cut auto lock enabled subnet hyperparameter decides whether a subnet owner's distributed emission cut is auto-locked as conviction stake or received as free stake.
  • Owner Cut Enabled How the owner cut enabled subnet hyperparameter switches whether a subnet owner receives their cut of emissions at all, separate from how large that cut is.
  • Owner Hyperparam Rate Limit How the owner hyperparam rate limit sets the cooldown a subnet owner must wait between hyperparameter changes, measured as a multiple of the subnet's tempo.
  • Price Discovery How a Bittensor subnet's alpha price is discovered through trading in its pool, emerging from buying and selling rather than being assigned.
  • Protocol Alpha How protocol alpha names subnet alpha accumulated by the Bittensor protocol itself during reserve injection, settled pro-rata when a subnet dissolves.
  • Pruning Score How the pruning score expresses the principle that a place in a subnet is held by earning, with the least-rewarded participant the first to make way.
  • Rank How rank summarizes consensus-adjusted miner evaluation in Bittensor subnets.
  • Recycle Or Burn How the recycle or burn subnet hyperparameter decides whether miner emission routed to burn UIDs is recycled through issuance accounting or burned as missing supply.
  • Register How register names the subnet-entry process that gives a Bittensor participant a UID slot after a dynamic registration burn.
  • Registration Allowed How the registration allowed subnet hyperparameter controls whether new neurons can register on a subnet.
  • Reserve Ratio How a subnet reserve ratio relates TAO reserves and alpha reserves in Bittensor's subnet pools.
  • Root Staker How a root staker names a TAO holder who stakes on the Root Subnet through validators.
  • Root Subnet How the Root Subnet, also called Subnet Zero, provides a subnet-agnostic staking path.
  • Root Validator How a root validator names the validator role on the Root Subnet, where TAO stake is not tied to one mining subnet.
  • Serving Rate Limit How the serving rate limit subnet hyperparameter paces how often miners can register or update axon and prometheus endpoint information on a Bittensor subnet.
  • Stake Threshold How the global stake threshold root parameter sets the minimum stake weight a neuron needs before it can be considered for a validator permit during the epoch.
  • Start Call How a start call activates a newly created Bittensor subnet so it begins its first emission period.
  • Subnet How a Bittensor subnet organizes a specialized market for digital work, miner production, and validator evaluation.
  • Subnet 1: Apex Apex is Bittensor's first subnet, operated by Macrocosmos, running open competitions where miners submit Python algorithms that validators continuously benchmark for rewards.
  • Subnet 2: DSperse DSperse is Bittensor Subnet 2. Its on-chain identity describes it as verifiable and distributed inference, and its repository presents the subnet as a Proof-of-Inference network.
  • Subnet 3: Deprecated Subnet 3 is a Bittensor subnet slot whose on-chain identity is registered as deprecated, with placeholder values for its GitHub and URL fields and no active public codebase.
  • Subnet 4: Targon Targon is Bittensor Subnet 4, a confidential-compute subnet for protected AI infrastructure.
  • Subnet 5: Hone Hone is Bittensor Subnet 5, an ARC-AGI-2 reasoning subnet that evaluates solver repositories in a secure GPU sandbox.
  • Subnet 6: Numinous Numinous is a Bittensor forecasting protocol that pits miners' Python agents against real-world prediction events, scoring them by Brier Score inside isolated Docker sandboxes.
  • Subnet 7: Allways Allways is a Bittensor subnet enabling trustless native asset swaps across independent blockchains, using a collateral-and-slashing smart contract to coordinate miners as market makers and validators as independent verifiers.
  • Subnet 8: Vanta Vanta is a Bittensor subnet that runs a decentralized trading competition, scoring miners on the verified risk-adjusted performance of their directional signals across forex, crypto, and equities markets.
  • Subnet 9: iota iota is a Bittensor subnet that incentivizes permissionless, pipeline-parallel pretraining of large language models by rewarding miners for the volume of valid activation work they contribute to a shared training run.
  • Subnet 10: Swap Swap is a Bittensor subnet that rewards liquidity providers on TaoFi's TAO/USDC concentrated liquidity pool in proportion to the trading fees their positions earn each epoch.
  • Subnet 11: TrajectoryRL TrajectoryRL is Bittensor Subnet 11. Its on-chain identity describes the subnet as agentic RL as a service, and its official repository presents it as a continuous competition for producing installable AI agent skills.
  • Subnet 12: Compute Horde Compute Horde is a Bittensor subnet that decentralizes GPU compute resources, enabling validators across the network to run AI workloads on miner-provided hardware verified through synthetic and organic job scoring.
  • Subnet 13: Data Universe Data Universe is a Bittensor subnet operated by Macrocosmos that incentivizes miners to scrape and store real-time social media data, building a distributed open dataset that validators score on volume, freshness, and diversity.
  • Subnet 14: Cacheon Cacheon is a Bittensor subnet that runs a live competition where miners submit optimized inference servers for open-source LLMs, scored against a baseline on speed and correctness.
  • Subnet 15: ORO ORO is a Bittensor subnet that benchmarks autonomous AI shopping agents on real-world e-commerce tasks, scoring miners on product search accuracy, recommendation quality, and format correctness using a standardized evaluation dataset.
  • Subnet 16: BitAds BitAds is a Bittensor subnet that runs a decentralized proof-of-sale marketing network, rewarding miners for verified sales they drive for merchandiser campaigns and scoring them on revenue, order volume, and low refund rates.
  • Subnet 17: 404-GEN 404-GEN is a Bittensor subnet running a decentralized 3D content generation competition where miners submit AI-generated models from text prompts and validators score them via pairwise vision-language model duels.
  • Subnet 18: Zeus Zeus is a Bittensor subnet operated by Orpheus-AI that rewards miners for producing accurate global weather and climate forecasts, evaluated by validators against ERA5 reanalysis ground truth on both short-term and 15-day horizons.
  • Subnet 19: blockmachine Blockmachine is a decentralized marketplace for verifiable blockchain RPC infrastructure, where miners earn Bittensor emissions by serving authenticated requests rated for correctness by independent validators.
  • Subnet 20: GroundLayer GroundLayer is a Bittensor subnet that provides structured, on-chain OTC deals for subnet alpha tokens, connecting subnet operators, fund managers, and institutional investors.
  • Subnet 21: AdTAO AdTAO is a Bittensor subnet that runs a verifiable prediction market for Google Ads campaign outcomes, rewarding miners for calibrated probabilistic forecasts of advertising intervention effects anchored on chain.
  • Subnet 22: Desearch Desearch is Bittensor Subnet 22, a search-focused subnet for live web, X/Twitter, and multi-source data retrieval.
  • Subnet 23: Trishool Trishool is Bittensor Subnet 23, an AI alignment protocol; its on-chain identity registers the project name as Trishool.
  • Subnet 24: Quasar Quasar is Bittensor Subnet 24, focused on long-context model training and evaluation through public model commitments.
  • Subnet 25: Mainframe Mainframe is Bittensor Subnet 25, a decentralized science subnet focused on scientific compute for life-sciences workloads.
  • Subnet 26: Perturb Perturb is Bittensor Subnet 26, an adversarial-robustness subnet where miners return bounded image perturbations for validator-created challenges.
  • Subnet 27: Team TBC Team TBC is Bittensor Subnet 27. The on-chain identity lists the subnet name as Team TBC; all other identity fields are currently blank.
  • Subnet 28: gm gm is Bittensor Subnet 28, a subnet slot whose live Finney identity registers contact, website, and the description 'say gm to AI.'
  • Subnet 29: Coldint Coldint is Bittensor Subnet 29, a collaborative distributed-training subnet focused on model training research and incremental model improvements.
  • Subnet 30: Endure Network Endure Network is Bittensor Subnet 30, a risk intelligence network with public project materials at endure.network and docs.endure.network.
  • Subnet 31: rec4ll rec4ll is Bittensor Subnet 31, a decentralized retrieval-augmented generation network where miners serve embeddings, vector search, and inference, and validators score retrieval and answer quality.
  • Subnet 32: ItsAI ItsAI is Bittensor Subnet 32, an AI text-detection subnet; its on-chain identity registers the project name as ItsAI.
  • Subnet 33: ReadyAI ReadyAI is Bittensor Subnet 33, a subnet that rewards miners for turning raw conversation data into structured, semantically tagged data.
  • Subnet 34: BitMind BitMind is Bittensor Subnet 34, the Generative Adversarial Subnet where detection miners and generation miners compete around synthetic media.
  • Subnet 35: OxMarkets OxMarkets is Bittensor Subnet 35, a liquidity-focused subnet where validators score miner positions and publish weights for the network.
  • Subnet 36: Eirel Eirel is Bittensor Subnet 36, an execution layer for multimodal AI workflows that connects miner agents with validator evaluation.
  • Subnet 37: Aurelius Aurelius is Bittensor Subnet 37, a subnet that rewards miners for moral-reasoning scenarios that are simulated and turned into alignment training data.
  • Subnet 38: ChronoLLM ChronoLLM is Bittensor Subnet 38; its on-chain identity registers the subnet for competitive training of chronologically consistent large language models.
  • Subnet 39: Deprecated Subnet 39 is a Bittensor subnet slot whose live Finney identity is registered as deprecated, with placeholder project metadata rather than an active public protocol description.
  • Subnet 40: ? Subnet 40 is a Bittensor subnet whose live Finney identity now shows a placeholder '?' name; all other identity fields — description, GitHub, URL, and Discord — are blank.
  • Subnet 41: Almanac Almanac is Bittensor Subnet 41, an incentivized market-intelligence subnet where miners submit prediction signals and validators score trading performance.
  • Subnet 42: Unknown Subnet 42 is a Bittensor subnet slot whose live Finney identity is registered as Unknown, with no public GitHub repository, website, contact, Discord, description, logo, or additional metadata.
  • Subnet 43: Graphite Graphite is Bittensor Subnet 43, a subnet that rewards miners for solving graph optimization problems such as the Traveling Salesman Problem.
  • Subnet 44: Score Score is Bittensor Subnet 44, a subnet that rewards miners for models that turn live video and imagery into structured, decision-ready data.
  • Subnet 45: Talisman AI Talisman AI is Bittensor Subnet 45, a perception subnet that rewards miners for analyzing social media posts into structured, verified market signals.
  • Subnet 46: Zipcode Zipcode is Bittensor Subnet 46, a real-estate intelligence subnet where miners submit residential property price-prediction models and validators score them against sales data.
  • Subnet 47: EvolAI EvolAI is Bittensor Subnet 47, a subnet that runs a continuous competition to train small language models, scoring them against a reference model each round.
  • Subnet 48: Quantum Compute Quantum Compute is Bittensor Subnet 48, a quantum-computing subnet where miners provide access to gate-model quantum computers and validators coordinate circuit execution jobs.
  • Subnet 49: Nepher Robotics Nepher Robotics is Bittensor Subnet 49, a robotics tournament where miners submit trained control policies that validators evaluate in simulation.
  • Subnet 50: Synth Synth is Bittensor Subnet 50, a predictive-intelligence subnet where miners submit probabilistic price-path forecasts and validators score them against realized market movements.
  • Subnet 51: lium.io lium.io is Bittensor Subnet 51, a decentralized GPU rental marketplace where miners contribute GPU machines that renters pay to use.
  • Subnet 52: Dojo Dojo is Bittensor Subnet 52, a Tensorplex Labs subnet that runs a competitive, decentralized GAN where miners both produce and judge work.
  • Subnet 53: EfficientFrontier EfficientFrontier is Bittensor Subnet 53, a financial-trading subnet focused on risk-weighted crypto trading strategies and live trading data.
  • Subnet 54: Yanez MIID Yanez MIID is Bittensor Subnet 54, a subnet that rewards miners for generating identity-variation data used to test fraud-detection and KYC screening systems.
  • Subnet 55: NIOME NIOME is Bittensor Subnet 55, a subnet that rewards miners for generating privacy-preserving synthetic genomic data for biomedical research.
  • Subnet 56: Gradients Gradients is Bittensor Subnet 56, an AutoML tournament subnet where miners submit open-source training methods and validators execute them on standardized infrastructure.
  • Subnet 57: Unknown Subnet 57 is a live Bittensor subnet whose SubnetIdentitiesV3 record is null on Finney; no project name, repository, website, or description is registered on-chain.
  • Subnet 58: Pending Subnet 58 is a Bittensor subnet whose live Finney identity is registered with the placeholder name Pending; all other identity fields are currently blank.
  • Subnet 59: Babelbit Babelbit is Bittensor Subnet 59, a subnet that runs competitions to build a real-time speech-to-speech interpreter that reads well under low latency.
  • Subnet 60: Bitsec.ai Bitsec.ai is Bittensor Subnet 60, a security subnet where miners submit autonomous agents that analyze code for vulnerabilities and validators score them in a sandbox.
  • Subnet 61: RedTeam RedTeam is Bittensor Subnet 61, a subnet that rewards miners for original code solutions to competitive cybersecurity challenges.
  • Subnet 62: Ridges Ridges is Bittensor Subnet 62, a subnet where miners submit autonomous software-engineering agents that fix code, evaluated in a sandbox.
  • Subnet 63: Enigma Enigma is Bittensor Subnet 63, a decentralized challenge platform that funds prize pools for breaking cryptographic systems and other deep-tech targets.
  • Subnet 64: Chutes Chutes is Bittensor Subnet 64, a serverless AI compute platform where miners provide GPUs that run developers' applications, such as model inference, on demand.
  • Subnet 65: TAO Private Network TAO Private Network is Bittensor Subnet 65, a decentralized VPN where operators provide geographically diverse connections in exchange for emissions.
  • Subnet 66: ninja ninja is Bittensor Subnet 66, a software-agent distillation subnet where miners submit coding agents and validators compare challengers against the current leading agent.
  • Subnet 67: Harnyx Harnyx is Bittensor Subnet 67, a deep-research subnet where miners build agents that answer research questions and are rewarded for the best-researched answers.
  • Subnet 68: NOVA NOVA is Bittensor Subnet 68, a drug-discovery subnet that rewards miners for proposing molecules and protein sequences predicted to bind strongly to target proteins.
  • Subnet 69: ? Subnet 69 is a Bittensor subnet with a registered on-chain identity whose name field is set to the placeholder '?'; all other identity fields — description, GitHub, URL, and Discord — are filled with placeholder values.
  • Subnet 70: NexisGen NexisGen is Bittensor Subnet 70, a data subnet where miners build captioned video-clip datasets and validators verify that the data is genuine and well-formed before rewarding the miners.
  • Subnet 71: Leadpoet Leadpoet is Bittensor Subnet 71, a decentralized AI sales-agent subnet for lead generation, where miners surface companies and enriched leads matching a buyer's profile and validators score them on fit, accuracy, and intent evidence.
  • Subnet 72: StreetVision by NATIX StreetVision by NATIX is Bittensor Subnet 72, a street-imagery computer-vision subnet where miners build models that detect features such as roadwork and validators score them on accuracy.
  • Subnet 73: Parked Subnet 73 is a Bittensor subnet slot whose live Finney identity is registered as Parked, with no public repository, website, contact, or description currently listed.
  • Subnet 74: Gittensor Gittensor is Bittensor Subnet 74, an open-source contribution subnet that rewards meaningful merged pull requests to recognized repositories.
  • Subnet 75: Hippius Hippius is Bittensor Subnet 75, a blockchain-backed cloud subnet for decentralized storage, virtual machines, and applications.
  • Subnet 76: Byzantium Subnet 76 is a Bittensor subnet whose live Finney identity is registered as Byzantium, with a public website, repository, Discord, and the description 'Leverage marketing with AI Swarm.'
  • Subnet 77: Liquidity Liquidity is Bittensor Subnet 77, a subnet where token-holder votes steer liquidity incentives and miners compete by supplying liquidity to selected decentralized-exchange pools.
  • Subnet 78: Vocence Vocence is Bittensor Subnet 78, a voice-AI subnet where miners build models that turn written prompts into speech and validators score the audio on accuracy, quality, and voice match.
  • Subnet 79: MVTRX MVTRX is Bittensor Subnet 79, a market-simulation subnet where miners run trading-strategy agents in a simulated market and are rewarded for risk-adjusted performance, producing market research data.
  • Subnet 80: DogeLayer DogeLayer is Bittensor Subnet 80, a Scrypt mining subnet where miners contribute LTC/DOGE hashrate and validators weight miner contributions.
  • Subnet 81: Deprecated Subnet 81 is a Bittensor subnet slot whose live Finney identity is registered as deprecated, with placeholder project metadata rather than an active public protocol description.
  • Subnet 82: Compelle Compelle is Bittensor Subnet 82, an adversarial-persuasion subnet where miners submit debate strategies and validators score debate performance.
  • Subnet 83: CliqueAI CliqueAI is Bittensor Subnet 83, where miners solve maximum clique graph problems and validators score submitted cliques for validity, size, and solution diversity.
  • Subnet 84: ? Subnet 84 is a Bittensor subnet whose live Finney identity now shows a placeholder '?' name; all other identity fields — description, GitHub, URL, and Discord — are blank.
  • Subnet 85: Vidaio Vidaio is Bittensor Subnet 85, an AI video-processing subnet where miners upscale and compress video and validators score the results on objective quality before rewarding the best output.
  • Subnet 86: ⚒ ⚒ is Bittensor Subnet 86. The on-chain identity lists the subnet name as ⚒; the GitHub, URL, and Discord fields are blank.
  • Subnet 87: unknown Subnet 87 is a Bittensor subnet whose live Finney identity lists the name as 'unknown'; the description, GitHub, URL, and Discord fields are all blank.
  • Subnet 88: Investing Investing is Bittensor Subnet 88, a decentralized asset-management subnet where participants submit and compete on portfolio strategies across supported asset classes.
  • Subnet 89: InfiniteQuant InfiniteQuant is Bittensor Subnet 89, a trading-signals subnet where miners commit encrypted directional trade calls and validators grade them on real market data.
  • Subnet 90: ? Subnet 90 is a Bittensor subnet with a registered on-chain identity whose name field is set to the placeholder '?'; all other identity fields — description, GitHub, URL, and Discord — are filled with placeholder values.
  • Subnet 91: Bitstarter #1 Subnet 91 is a Bittensor subnet slot whose live Finney identity is registered as Bitstarter #1, with launch-oriented metadata and no public repository currently listed.
  • Subnet 92: wgmi wgmi is Bittensor Subnet 92, a subnet registered on-chain under the name wgmi with all other public identity fields — URL, GitHub, Discord, and description — blank.
  • Subnet 93: Bitcast Bitcast is Bittensor Subnet 93, a creator-economy subnet where miners publish YouTube videos that fulfill brand briefs and validators verify real audience engagement before rewards are paid.
  • Subnet 94: BitSota BitSota is Bittensor Subnet 94, a decentralized research network where miners automatically evolve machine-learning algorithms to beat a benchmark and validators independently re-evaluate the results.
  • Subnet 95: Actual Actual is Bittensor Subnet 95, operated by Actual Computer Inc. The on-chain description registers the subnet as a heterogeneous inference network.
  • Subnet 96: Verathos Verathos is Bittensor Subnet 96, a decentralized compute network where miners run AI inference and attach cryptographic proofs that the computation was correct, which validators verify cheaply before rewarding honest work.
  • Subnet 97: Albedo Albedo is Bittensor Subnet 97, a king-of-the-hill competition where miners submit challenger language models that are judged head-to-head against a reigning champion, with full match transcripts published for research.
  • Subnet 98: ForeverMoney ForeverMoney is Bittensor Subnet 98, an automated liquidity-management subnet where miners propose pool-rebalancing strategies and validators score them through forward simulations, executing the winners on-chain.
  • Subnet 99: Leoma Leoma is Bittensor Subnet 99, an AI video subnet where miners run text-image-to-video models and validators score the generated clips, setting winner-take-all weights on-chain each round.
  • Subnet 100: Plaτform Plaτform is Bittensor Subnet 100, an auto-research subnet where miners compete against a synthetic benchmark; its on-chain identity registers the name as Plaτform.
  • Subnet 101: Tag101 Tag101 is Bittensor Subnet 101, a decentralized social post tagging subnet where miners submit labels for X posts and validators evaluate them, turning content labeling into a rewarded network service.
  • Subnet 102: ConnitoAI ConnitoAI is Bittensor Subnet 102, a subnet for collaborative AI training where many contributors each train a specialized expert and the experts are combined into one larger model.
  • Subnet 103: Djinn Djinn is Bittensor Subnet 103, a marketplace for analysis where the predictions you buy stay private and each seller's accuracy is provable from a tamper-proof record.
  • Subnet 104: For Sale Subnet 104 is a Bittensor subnet slot whose live Finney identity marks it as for sale, with no registered public repository, website, contact, or Discord.
  • Subnet 105: Beam Beam is Bittensor Subnet 105, a decentralized bandwidth subnet for coordinating machine-to-machine data transfers across distributed participants.
  • Subnet 106: Nodexo Nodexo is Bittensor Subnet 106, registered on Finney with the description 'tokenized ai compute' and no publicly accessible project site or GitHub repository at the time of writing.
  • Subnet 107: Minos Minos is Bittensor Subnet 107, a genomics subnet where miners tune variant-calling pipelines to find hidden mutations in synthetic genomes and validators run their configs to score the accuracy.
  • Subnet 108: TalkHead TalkHead is Bittensor Subnet 108, a talking-head video subnet where miners submit face-animation models and validators score them on a shared benchmark in a secure GPU environment.
  • Subnet 109: Academia Academia is Bittensor Subnet 109, an incubator that develops new subnet ideas inside a single subnet and graduates the strongest ones into their own dedicated subnets.
  • Subnet 110: Green Compute Green Compute is Bittensor Subnet 110, a decentralized GPU-compute subnet focused on inference hardware powered by verified green energy.
  • Subnet 111: Claims Claims is Bittensor Subnet 111; its on-chain identity registers the subnet for turning scientific literature into a structured claim-evidence graph.
  • Subnet 112: Minotaur Minotaur is Bittensor Subnet 112, a swap intent-solving and DEX aggregation subnet where miners compete to fill token-swap requests on the best terms and validators simulate and score the result.
  • Subnet 113: TensorUSD TensorUSD is Bittensor Subnet 113, which runs the liquidation auctions and price oracle behind a reserve-backed stablecoin designed for 1:1 US dollar redeemability within Bittensor.
  • Subnet 114: SOMA SOMA is Bittensor Subnet 114, which rewards miners for building Model Context Protocol (MCP) servers that let AI agents securely use external tools, data, and execution environments.
  • Subnet 115: HashiChain HashiChain is Bittensor Subnet 115, a subnet whose public materials describe an agent-oriented Layer 1 design for probabilistic coordination between autonomous AI agents.
  • Subnet 116: Unknown Subnet 116 is a Bittensor subnet with no registered on-chain identity. All identity fields — name, description, GitHub repository, URL, and Discord — are absent from the Finney chain.
  • Subnet 117: Unknown Subnet 117 is registered on Finney with the subnet name Unknown and a GitHub field for helionlink/Chi; the description, URL, and Discord fields are set to placeholder tilde values.
  • Subnet 118: Ditto Ditto is Bittensor Subnet 118, an open-source assistant-memory subnet whose public materials focus on persistent memory and agent integrations for Claude-style cowork.
  • Subnet 119: Satori Satori is Bittensor Subnet 119, an identity-backed subnet whose live Finney description presents it as a Japan-focused digital residency and AI companionship project.
  • Subnet 120: Affine Affine is Bittensor Subnet 120, a reasoning-mining subnet where miners submit model revisions and challengers compete against the current champion across evaluation environments.
  • Subnet 121: sundae_bar sundae_bar is Bittensor Subnet 121, a subnet for creating and benchmarking a generalist AI agent that can execute real business workflows.
  • Subnet 122: CookingTAO CookingTAO is Bittensor Subnet 122, whose on-chain identity registers the project name with the description 'Democratizing Bittensor Mining.'
  • Subnet 123: MANTIS MANTIS is Bittensor Subnet 123, a forecasting subnet where miners submit encrypted market-signal embeddings and validators score their salience across financial prediction challenges.
  • Subnet 124: Swarm Swarm is Bittensor Subnet 124, a benchmark that rewards miners for neural networks that fly simulated drones through unseen 3D environments.
  • Subnet 125: 8 Ball 8 Ball is Bittensor Subnet 125, a prediction-market subnet where market-maker liquidity is mapped to Bittensor miner incentives through validator scoring.
  • Subnet 126: Poker44 Poker44 is Bittensor Subnet 126, a subnet that rewards miners for detecting bots in online poker from hand-behavior data.
  • Subnet 127: Astrid Astrid is Bittensor Subnet 127, a validator-coordinated subnet where weights combine vault targets with arena competition results from trading agents.
  • Subnet 128: ByteLeap ByteLeap is Bittensor Subnet 128, a distributed-compute subnet where miners aggregate worker resources for compute leases and validator challenges.
  • Subnet Creation and Incentive Mechanisms How subnet creation turns a useful-work idea into an incentive mechanism that miners and validators can repeat on Bittensor.
  • Subnet Creator How a subnet creator defines the work and evaluation context for a Bittensor subnet.
  • Subnet Deregistration How Bittensor removes an eligible subnet when the subnet cap is full and a new subnet needs a slot.
  • Subnet Emission Enabled How the subnet emission enabled hyperparameter toggles a subnet's pool-side emission injection, which flows stop when it is off, and which emissions continue regardless.
  • Subnet Hyperparameters How Bittensor subnet hyperparameters shape subnet timing, weight flow, consensus behavior, and emission handling without defining the subnet task itself.
  • Subnet Is Active How the subnet is active flag indicates whether a subnet's emissions have started, separating a registered subnet slot from one that is live and emitting.
  • Subnet Lease How a subnet lease names the split-profit-ownership arrangement that gives a leased subnet a designated beneficiary and a set of contributor shareholders.
  • Subnet Liquidity Pools How Bittensor subnet pools connect paired TAO and alpha reserves to staking, unstaking, slippage, and emissions.
  • Subnet Markets How Bittensor subnets create markets for specialized digital work, evaluation, staking, and emissions.
  • Subnet Miner How a subnet miner performs the work a Bittensor subnet asks validators to evaluate.
  • Subnet Owner Cut How the subnet owner cut parameter sets the fixed 18% of a subnet's alpha emissions taken for the owner before the remainder is split between validators and miners.
  • Subnet Owner Take How a fixed share of each Bittensor subnet's alpha emissions, documented at 18 percent, goes to the subnet owner as stake.
  • Subnet Protocol How a subnet protocol defines the interaction rules between miners and validators.
  • Subnet Registration How subnet registration creates a new Bittensor subnet by paying a registration burn, assigning a unique netuid, and opening a new incentive market.
  • Subnet Scoring Model How a subnet scoring model defines validator evaluation of miner responses inside a Bittensor subnet.
  • Subnet Symbol How Bittensor denotes TAO and each subnet's alpha token with symbols, so a quantity can be tied to the subnet it belongs to.
  • Subnet Task How a subnet task defines the work miners produce and validators evaluate in Bittensor.
  • Subnet Validator How a subnet validator evaluates miner work inside a Bittensor subnet.
  • Subnet Weights How subnet weights describe each subnet's relative share of Bittensor emissions under the flow-based emission model.
  • Symbol Already In Use How the SymbolAlreadyInUse error signals that a submitted subnet symbol is valid, but another subnet is already using it.
  • Symbol Does Not Exist How the SymbolDoesNotExist error signals that a submitted subnet symbol is not one of the allowed symbols recognized by the chain.
  • Synapse How synapse names the structured message object exchanged through Bittensor subnet communication.
  • TAO Reserve How a TAO reserve describes the TAO held inside a subnet liquidity pool in Bittensor.
  • Target Registrations Per Interval How the target registrations per interval subnet hyperparameter once named a desired registration count per adjustment interval, and why documentation now marks it unused for neuron registration.
  • Tempo How Bittensor subnets use tempos as block-based intervals for reward distribution, weight processing, and subnet timing.
  • Toggle Transfer How the toggle transfer subnet hyperparameter allows or disallows transferring staked alpha between coldkeys on a subnet.
  • Tx Rate Limit How the tx rate limit chain parameter sets the general transaction rate limit in blocks, the cooldown that currently governs hotkey swaps and raises TxRateLimitExceeded when breached.
  • UID How UID names the unique identifier assigned to each participant in a Bittensor subnet.
  • UID Slot How a UID slot identifies a participant position inside a Bittensor subnet.
  • UID Trimming How a Bittensor subnet owner can trim low-emitting UIDs to shrink a subnet's participant set and compact the survivors into consecutive indices.
  • Validator Deregistration How validator deregistration removes a low-performing Bittensor subnet validator from a UID slot when subnet capacity and registration rules require replacement.
  • Validator Registration How validator registration names the process that gives a Bittensor subnet validator a UID slot after registering a hotkey with that subnet.
  • Validator-Miner Bonds How validator-miner bonds connect validator evaluation to smoothed subnet consensus outcomes.
  • Weight Setting How weight setting names the validator process of scoring miners in Bittensor subnets.
  • Weights Rate Limit How the weights rate limit subnet hyperparameter sets the minimum block wait between validator weight commits on a Bittensor subnet.
  • Weights Version Key How the weights version key subnet hyperparameter requires a validator's set_weights call to meet a minimum version before it is accepted.
  • Yuma Version How the yuma version subnet hyperparameter selects whether a subnet runs Yuma Consensus v2 or v3 when processing validator weights.
  • Yuma3 Enabled How the yuma3 enabled toggle, documented as YumaVersion, lets a subnet switch its consensus mechanism between Yuma Consensus v2 and v3.

Mining

View topic
  • Autostaking How autostaking automatically routes Bittensor miner emissions into validator staking.
  • Axon How axon names the server-side endpoint in Bittensor subnet request and response communication.
  • Dendrite How dendrite names the client-side request component used with axons in Bittensor subnet communication.
  • Digital Commodities How Bittensor subnets define useful digital work for miners to produce and validators to evaluate.
  • Incentive Compatibility How Bittensor aims to make honest, high-quality contribution the most profitable strategy for miners and validators, so self-interest serves the subnet.
  • Incentives How incentives name the miner-facing reward portion of Bittensor emissions inside a subnet.
  • Miner Deregistration How miner deregistration removes a low-performing Bittensor subnet miner from a UID slot when a subnet needs room for a new registration.
  • Miner Incentive How miner incentive names the emission share Bittensor miners receive for their work in a subnet.
  • Miner Registration How miner registration names the process that gives a Bittensor subnet miner a UID slot so the miner can participate in subnet work and emissions.
  • Mining and Validating in Bittensor A factual overview of how miners produce subnet work, validators evaluate that work, and consensus turns validator signals into subnet emissions.
  • Neuron How a neuron represents a registered participant inside a Bittensor subnet.
  • Pruning Score How the pruning score expresses the principle that a place in a subnet is held by earning, with the least-rewarded participant the first to make way.
  • Serving Rate Limit How the serving rate limit subnet hyperparameter paces how often miners can register or update axon and prometheus endpoint information on a Bittensor subnet.
  • Subnet How a Bittensor subnet organizes a specialized market for digital work, miner production, and validator evaluation.
  • Subnet 1: Apex Apex is Bittensor's first subnet, operated by Macrocosmos, running open competitions where miners submit Python algorithms that validators continuously benchmark for rewards.
  • Subnet Creator How a subnet creator defines the work and evaluation context for a Bittensor subnet.
  • Subnet Miner How a subnet miner performs the work a Bittensor subnet asks validators to evaluate.
  • Subnet Protocol How a subnet protocol defines the interaction rules between miners and validators.
  • Subnet Scoring Model How a subnet scoring model defines validator evaluation of miner responses inside a Bittensor subnet.
  • Subnet Task How a subnet task defines the work miners produce and validators evaluate in Bittensor.
  • Subnet Validator How a subnet validator evaluates miner work inside a Bittensor subnet.
  • Synapse How synapse names the structured message object exchanged through Bittensor subnet communication.

Staking

View topic
  • Alpha Staker How an alpha staker names a staker who holds subnet alpha through staking in a specific Bittensor subnet.
  • Autostaking How autostaking automatically routes Bittensor miner emissions into validator staking.
  • Child Hotkey How a child hotkey lets a parent hotkey re-delegate stake so the child validates on the parent's behalf on a subnet, without transferring ownership.
  • Child Hotkeys How a Bittensor delegate validator authorizes child hotkeys to validate on its behalf in a selected subnet, and how child take works.
  • Childkey Take How childkey take describes the subnet-specific share of dividends a child hotkey keeps when it validates on behalf of a parent hotkey.
  • Conviction and Locked Stake How locked stake builds conviction as a public commitment signal in Bittensor staking.
  • Delegate How a delegate functions as a subnet validator that receives staked TAO from delegators.
  • Delegate Stake How delegate stake refers to the TAO a Bittensor delegate stakes themselves.
  • Delegate Tx Rate Limit Exceeded How the DelegateTxRateLimitExceeded error signals that a validator tried to raise delegate take again before the delegate-take cooldown had expired.
  • Delegation How delegation names staking TAO to a validator to support validator stake and subnet consensus context.
  • Delegation Rewards How a delegator earns a share of a validator's rewards in proportion to the stake it adds, after the validator's take.
  • Duplicate Child How the DuplicateChild error blocks a schedule_children call that lists the same child hotkey more than once for a parent on a subnet.
  • Effective Stake How effective stake describes the total staked TAO associated with a delegate.
  • Emission How emission names Bittensor's process for creating and allocating TAO and subnet-specific alpha tokens.
  • Hotkey-Coldkey Pair How a hotkey-coldkey pair names the authentication pairing that links operational hotkeys to ownership coldkeys for delegates, nominators, and Senate participation.
  • Ledger Hardware Wallet How a Ledger hardware wallet fits into Bittensor coldkey custody, wallet-app signing, staking, transfers, proxy setup, and address verification.
  • Moving Stake How moving stake changes the hotkey and/or subnet that holds a staked position in a single atomic operation, used when a participant rearranges an existing staked position without withdrawing to a coldkey.
  • Nominate How nominate describes staking TAO with validators in Bittensor delegation terminology.
  • Nominator How a nominator names the TAO-holder role that stakes with validators through Bittensor delegation vocabulary.
  • Non Associated Cold Key How the NonAssociatedColdKey error signals that a stake, unstake, or subscribe request was signed by a coldkey that does not own the targeted hotkey account.
  • Price Protection How Bittensor price protection limits adverse price movement handling during staking and unstaking.
  • Relative Stake Weight How relative stake weight describes a validator's proportional stake-based influence inside a Bittensor subnet.
  • Root Claim Type How root claim type names the Keep or Swap setting for handling Root Subnet alpha dividends.
  • Root Claims How Bittensor root claims handle alpha dividends earned through Root Subnet staking.
  • Root Proportion How root proportion describes the portion of a subnet's dividend context attributed to TAO staked through the root subnet.
  • Root Staker How a root staker names a TAO holder who stakes on the Root Subnet through validators.
  • Root Subnet How the Root Subnet, also called Subnet Zero, provides a subnet-agnostic staking path.
  • Root Validator How a root validator names the validator role on the Root Subnet, where TAO stake is not tied to one mining subnet.
  • Same Netuid How the SameNetuid error blocks a move_stake, transfer_stake, or swap_stake call that would leave a staked position pointed at the same hotkey, coldkey, and subnet it already has.
  • Slippage How slippage affects Bittensor staking and unstaking when subnet pools convert between TAO and alpha tokens.
  • Stake How stake names the token amount associated with a validator position inside a Bittensor subnet.
  • Stake Too Low For Root How the StakeTooLowForRoot error signals that a root_register call failed to displace the lowest-staked root validator because the registering hotkey's root stake was not higher.
  • Stake Weight How stake weight describes validator influence inside Bittensor subnet consensus.
  • Staking How staking names the process of attaching TAO support to a validator in Bittensor's subnet consensus context.
  • Staking and Delegation (TAO) How TAO holders stake and delegate to validators using Bittensor tooling, including concepts, minimums, and operational cautions.
  • Staking Operation Rate Limit Exceeded How the StakingOperationRateLimitExceeded error signals that a second staking operation was attempted on a subnet before the one-per-block staking cooldown had cleared.
  • Staking Precompile How the staking precompile lets Ethereum-style smart contracts reach native Subtensor staking actions such as adding and removing stake on the Bittensor EVM.
  • Staking Proxy Attacks How delegated staking authority can become a Bittensor wallet-safety risk even without direct transfer authority over the protected wallet.
  • Staking vs Liquidity Provision How staking to a validator and providing liquidity to a subnet's pool are two different ways to deploy TAO, earning from emissions versus trading fees.
  • Subnet Stake Burn How subnet stake burn adds TAO to a subnet reserve while permanently removing alpha from circulation.
  • TAO The network token used in Bittensor incentive, staking, subnet reserve, and emissions context.
  • TAO Weight How TAO weight sets the relative role of TAO stake when Bittensor derives validator stake weight inside a subnet.
  • Toggle Transfer How the toggle transfer subnet hyperparameter allows or disallows transferring staked alpha between coldkeys on a subnet.
  • Too Many Children How the TooManyChildren error blocks a parent hotkey from having more than five child hotkeys on a subnet at once.
  • Transferring Stake How transferring stake changes the coldkey that owns a staked position, used when a participant reassigns staked tokens to a different coldkey.
  • Tx Delegate Take Rate Limit How the tx delegate take rate limit sets the block-counted cooldown that paces how often a delegate's take can be increased on chain.
  • Unstaking How unstaking describes removing staked TAO from a staking position in Bittensor.
  • Validator Dividend How validator dividend names the emission share Bittensor validators receive for their consensus role.
  • Validator Permit How a validator permit marks validation rights inside a Bittensor subnet.
  • Validator Take How validator take describes the share a validator keeps from delegated-stake emissions before the remaining emissions flow to stakers.

Consensus

View topic
  • Activity Cutoff How activity cutoff names validator inactivity tolerance before stake is masked out of Yuma Consensus, including the legacy fixed-block hyperparameter and the live activity cutoff factor setting under dynamic tempos.
  • Activity Cutoff Factor How the activity cutoff factor subnet hyperparameter expresses validator inactivity tolerance in per-mille epochs so the effective window scales with tempo.
  • Alpha High How alpha high sets the upper bound of the liquid alpha range that varies how quickly validator-miner bonds smooth based on consensus alignment.
  • Alpha Low How alpha low sets the lower bound of the liquid alpha range that varies how quickly validator-miner bonds smooth based on consensus alignment.
  • Alpha Sigmoid Steepness How the alpha sigmoid steepness subnet hyperparameter shapes how sharply liquid alpha responds to validator consensus alignment when smoothing validator-miner bonds in Yuma Consensus.
  • Bonds Moving Average How the bonds moving average subnet hyperparameter configures the moving-average smoothing applied to validator-miner bonds in Yuma Consensus.
  • Bonds Penalty How the bonds penalty subnet hyperparameter sets the magnitude of the consensus penalty applied when validator weights exceed the subnet consensus benchmark in Yuma Consensus.
  • Collusion How colluding validators could try to skew Bittensor consensus toward favored miners, and why consensus clipping and stake weighting resist it.
  • Commit Reveal How Commit Reveal delays visibility of validator weight signals so recently produced weights are less useful for copying.
  • Commit Reveal Period How the commit reveal period subnet hyperparameter sets how many tempos must elapse before committed validator weights are revealed under the commit-reveal weight scheme.
  • Commit Reveal Weights Enabled How the commit reveal weights enabled subnet hyperparameter turns on the commit-reveal weight scheme that conceals validator weights before reveal.
  • Committing Weights Too Fast How the CommittingWeightsTooFast error signals that a validator retried a weight commit before the required commit-reveal pacing interval had elapsed.
  • Consensus Score How Yuma Consensus uses a consensus score to filter outlier validator weights before final rank results.
  • Consensus-Based Weights How liquid alpha adjusts Bittensor validator-miner bond smoothing according to consensus alignment.
  • Delegation How delegation names staking TAO to a validator to support validator stake and subnet consensus context.
  • Dividends How dividends describe the validator-side emission result produced from bonds and miner incentives in Bittensor.
  • Drand Time-Lock Encryption How Drand time-lock encryption supports delayed validator-weight visibility in Bittensor Commit Reveal.
  • EMA How an exponential moving average smooths values over time by weighting recent observations more heavily, the technique Bittensor uses to update validator-miner bonds across epochs.
  • Epoch How an epoch marks a Bittensor subnet's consensus period.
  • Exponential Moving Averages How exponential moving averages smooth Bittensor flow, bond, and reward signals across repeated updates.
  • Incentive Compatibility How Bittensor aims to make honest, high-quality contribution the most profitable strategy for miners and validators, so self-interest serves the subnet.
  • Incorrect Weight Version Key How the IncorrectWeightVersionKey error signals that a validator submitted weights with a version lower than the subnet's required weights version key.
  • Kappa How the kappa subnet hyperparameter sets the stake-weighted majority ratio Yuma Consensus uses to derive the consensus clipping threshold for miner weights.
  • Last Update How the last update value records the block of a neuron's most recent update, and how it combines with activity cutoff to decide whether the neuron is active.
  • Liquid Alpha How liquid alpha varies validator-miner bond EMA smoothing by pair within consensus-based weights.
  • Liquid Alpha Enabled How the liquid alpha enabled toggle decides whether a subnet uses a single fixed bond-smoothing alpha or a consensus-driven alpha that varies between the alpha low and alpha high bounds.
  • Mechanism Count How the mechanism count subnet hyperparameter sets how many incentive mechanisms a Bittensor subnet runs.
  • Min Allowed Weights How the min allowed weights subnet hyperparameter sets the fewest weights a validator must assign when it submits weights on a subnet.
  • Miner Incentive How miner incentive names the emission share Bittensor miners receive for their work in a subnet.
  • Owner Hyperparam Rate Limit How the owner hyperparam rate limit sets the cooldown a subnet owner must wait between hyperparameter changes, measured as a multiple of the subnet's tempo.
  • Rank How rank summarizes consensus-adjusted miner evaluation in Bittensor subnets.
  • Relative Stake Weight How relative stake weight describes a validator's proportional stake-based influence inside a Bittensor subnet.
  • Self-Weighting How a lone validator inflating weights for its own miners is blunted by Bittensor's stake-weighted consensus, which clips weights that depart from the broader agreement.
  • Setting Weights Too Fast How the SettingWeightsTooFast error signals that a validator retried weight submission before the subnet's required weights-rate-limit interval had elapsed.
  • Stake How stake names the token amount associated with a validator position inside a Bittensor subnet.
  • Stake Weight How stake weight describes validator influence inside Bittensor subnet consensus.
  • Staking How staking names the process of attaching TAO support to a validator in Bittensor's subnet consensus context.
  • Subjective Evaluation How Bittensor scores work that has no single objective answer by treating stake-weighted validator consensus as the accepted standard of quality.
  • Subnet Hyperparameters How Bittensor subnet hyperparameters shape subnet timing, weight flow, consensus behavior, and emission handling without defining the subnet task itself.
  • TAO Weight How TAO weight sets the relative role of TAO stake when Bittensor derives validator stake weight inside a subnet.
  • Tempo How Bittensor subnets use tempos as block-based intervals for reward distribution, weight processing, and subnet timing.
  • Time-Lock Encryption How time-lock encryption lets Bittensor validators commit weights that cannot be decrypted until a future point, underpinning the commit-reveal weight scheme.
  • Trust How Bittensor uses trust to describe miner-side support after consensus clipping.
  • UID How UID names the unique identifier assigned to each participant in a Bittensor subnet.
  • Validator Dividend How validator dividend names the emission share Bittensor validators receive for their consensus role.
  • Validator Trust How Bittensor uses validator trust to describe validator influence after consensus clipping.
  • Validator Weights How validator weights express subnet miner evaluations before Yuma Consensus filters and aggregates them.
  • Validator-Miner Bonds How validator-miner bonds connect validator evaluation to smoothed subnet consensus outcomes.
  • Weight Copying How copied validator weight information weakens independent miner evaluation in Bittensor consensus.
  • Weight Matrix How Bittensor groups validator weight vectors as structured input for Yuma Consensus.
  • Weight Setting How weight setting names the validator process of scoring miners in Bittensor subnets.
  • Weight Vector How a weight vector represents one validator's miner evaluations before subnet consensus.
  • Weights Rate Limit How the weights rate limit subnet hyperparameter sets the minimum block wait between validator weight commits on a Bittensor subnet.
  • Weights Version Key How the weights version key subnet hyperparameter requires a validator's set_weights call to meet a minimum version before it is accepted.
  • Yuma Consensus An explanation of Yuma Consensus, the Bittensor mechanism that aggregates validator weights into miner incentives and validator dividends.
  • Yuma Consensus 3 How Yuma Consensus 3 refines Bittensor validator-miner bonding so earlier, independent evaluations can be reflected more fairly.
  • Yuma Version How the yuma version subnet hyperparameter selects whether a subnet runs Yuma Consensus v2 or v3 when processing validator weights.
  • Yuma3 Enabled How the yuma3 enabled toggle, documented as YumaVersion, lets a subnet switch its consensus mechanism between Yuma Consensus v2 and v3.

Tokenomics

View topic
  • Alpha Distribution Ratio How Alpha Distribution Ratio frames distributed subnet alpha against pool-injected alpha in Dynamic TAO.
  • Alpha Halving How alpha halving reduces a subnet's alpha-token emission rate at subnet-specific supply milestones.
  • Alpha Outstanding How alpha outstanding describes subnet alpha held outside the reserve pool in Bittensor tokenomics.
  • Alpha Price How alpha price is derived from a subnet's TAO reserve and alpha reserve in Dynamic TAO.
  • Alpha Reserve How alpha reserve tracks subnet alpha held inside a subnet liquidity pool rather than outside the pool.
  • Alpha Staker How an alpha staker names a staker who holds subnet alpha through staking in a specific Bittensor subnet.
  • Alpha Tokens How Bittensor uses subnet-specific alpha tokens in emissions, staking, and subnet liquidity pools.
  • Arbitrage How arbitrageurs profit from alpha price differences across Bittensor subnet pools or between on-chain and outside markets, and how that trading keeps pool prices aligned.
  • Back-Running How back-running orders a transaction immediately after a pending swap in Bittensor's subnet pools, and how it differs from front-running and the sandwich attack.
  • Bittensor Emissions How Bittensor emissions connect newly created TAO and subnet alpha tokens to subnet incentives, validators, miners, and stakers.
  • Block Reward How much TAO Bittensor creates each block for the whole network, and how supply-based halvings cut that per-block reward over time.
  • Burn Cost How burn cost names the dynamic recycled-TAO amount required to create a Bittensor subnet.
  • Burning How burning removes tokens from spendable circulation in Bittensor tokenomics.
  • Coinbase How the Bittensor coinbase mechanism injects liquidity, accumulates pending emissions, and triggers Yuma Consensus every block.
  • Conviction and Locked Stake How locked stake builds conviction as a public commitment signal in Bittensor staking.
  • Crowdloans How a Bittensor crowdloan lets contributors collectively fund an extrinsic execution or transfer, commonly for subnet creation.
  • Delegation Rewards How a delegator earns a share of a validator's rewards in proportion to the stake it adds, after the validator's take.
  • Dividends How dividends describe the validator-side emission result produced from bonds and miner incentives in Bittensor.
  • Dynamic TAO (dTAO) How Dynamic TAO connects network TAO, subnet alpha tokens, liquidity pools, emissions, and validator stake weight.
  • Emission How emission names Bittensor's process for creating and allocating TAO and subnet-specific alpha tokens.
  • Emission Split How a subnet's alpha emission is divided each tempo, with documented shares of 41% to miners, 41% to validators and their stakers, and 18% to the subnet owner.
  • Exponential Moving Averages How exponential moving averages smooth Bittensor flow, bond, and reward signals across repeated updates.
  • Fees How fees name the TAO cost of network operations in Bittensor.
  • Flow-Based Emissions How Bittensor previously used net TAO flow to compare subnet-level reserve injection, a model deprecated in June 2026 in favor of price-based allocation.
  • Front-Running How front-running observes a pending swap in Bittensor's subnet pools and orders ahead of it, and how price protection and the MEV shield blunt it.
  • Halving How halving describes a scheduled reduction in token emission rate.
  • Halving Mechanisms How Bittensor uses supply-based TAO and subnet alpha halvings to reduce emission rates.
  • Impermanent Loss How providing liquidity to a Bittensor subnet's TAO and alpha pool exposes a provider to loss when the alpha price moves, compared with simply holding.
  • Incentives How incentives name the miner-facing reward portion of Bittensor emissions inside a subnet.
  • Issuance How Bittensor issuance tracks circulating TAO in tokenomics.
  • Liquidity Positions How liquidity positions supply range-based subnet liquidity around TAO and subnet alpha pools.
  • Liquidity Provider Rewards How a Bittensor liquidity provider earns trading fees from staking activity in its price range, and why it cannot earn from its own trades.
  • Maximum Supply How Bittensor caps TAO at 21 million, and why supply-threshold halvings and recycling shape how issuance approaches that ceiling.
  • MEV (Maximal Extractable Value) How MEV names the value extractable by manipulating transaction ordering in Bittensor's mempool context.
  • Miner Incentive How miner incentive names the emission share Bittensor miners receive for their work in a subnet.
  • Network Min Lock Cost How the network min lock cost global setting sets the floor on the TAO lock cost required to register a new subnet, separate from the dynamic cost that rises with demand.
  • Price Discovery How a Bittensor subnet's alpha price is discovered through trading in its pool, emerging from buying and selling rather than being assigned.
  • Protocol Alpha How protocol alpha names subnet alpha accumulated by the Bittensor protocol itself during reserve injection, settled pro-rata when a subnet dissolves.
  • RAO How RAO serves as the small-denomination unit for TAO amounts in Bittensor.
  • Recycling How recycling describes protocol reuse or re-emission of tokens in Bittensor supply accounting.
  • Recycling and Burning How Bittensor distinguishes re-emittable recycled tokens from tokens permanently removed from effective circulation.
  • Reserve Ratio How a subnet reserve ratio relates TAO reserves and alpha reserves in Bittensor's subnet pools.
  • Root Proportion How root proportion describes the portion of a subnet's dividend context attributed to TAO staked through the root subnet.
  • Sandwich Attack How a sandwich attack names a transaction ordering exploit that wraps a target transaction between two adversarial ones in Bittensor.
  • Slippage How slippage affects Bittensor staking and unstaking when subnet pools convert between TAO and alpha tokens.
  • Staking vs Liquidity Provision How staking to a validator and providing liquidity to a subnet's pool are two different ways to deploy TAO, earning from emissions versus trading fees.
  • Start Call How a start call activates a newly created Bittensor subnet so it begins its first emission period.
  • Subnet Deregistration How Bittensor removes an eligible subnet when the subnet cap is full and a new subnet needs a slot.
  • Subnet Lease How a subnet lease names the split-profit-ownership arrangement that gives a leased subnet a designated beneficiary and a set of contributor shareholders.
  • Subnet Liquidity Pools How Bittensor subnet pools connect paired TAO and alpha reserves to staking, unstaking, slippage, and emissions.
  • Subnet Markets How Bittensor subnets create markets for specialized digital work, evaluation, staking, and emissions.
  • Subnet Owner Take How a fixed share of each Bittensor subnet's alpha emissions, documented at 18 percent, goes to the subnet owner as stake.
  • Subnet Registration How subnet registration creates a new Bittensor subnet by paying a registration burn, assigning a unique netuid, and opening a new incentive market.
  • Subnet Symbol How Bittensor denotes TAO and each subnet's alpha token with symbols, so a quantity can be tied to the subnet it belongs to.
  • Subnet Weights How subnet weights describe each subnet's relative share of Bittensor emissions under the flow-based emission model.
  • Sybil Attack How a Sybil attack uses many fake identities to seek disproportionate influence, and why Bittensor's registration cost and stake weighting blunt it.
  • TAO The network token used in Bittensor incentive, staking, subnet reserve, and emissions context.
  • TAO Reserve How a TAO reserve describes the TAO held inside a subnet liquidity pool in Bittensor.
  • Tx Delegate Take Rate Limit How the tx delegate take rate limit sets the block-counted cooldown that paces how often a delegate's take can be increased on chain.
  • Validator Dividend How validator dividend names the emission share Bittensor validators receive for their consensus role.
  • Validator Take How validator take describes the share a validator keeps from delegated-stake emissions before the remaining emissions flow to stakers.
  • Wash Trading How wash trading uses self-dealing to fake market activity, and why Bittensor's automated market maker makes it a costly, self-defeating exercise.

Other topics

  • Batch Transactions How batch transactions group multiple Bittensor chain actions while preserving signer, fee, and failure boundaries.
  • Bicameral Legislature How Bittensor governance separates proposal creation and proposal approval between the Triumvirate and the Senate.
  • Bittensor CLI: Permissions Guide How BTCLI permissions map Bittensor command-line actions to permissionless reads, hotkey authority, coldkey authority, balances, validator permits, and Senate roles.
  • Bittensor EVM Smart Contracts How Bittensor supports Ethereum Virtual Machine-compatible smart contracts on Subtensor.
  • Bittensor Governance How Bittensor governance separates Triumvirate proposal creation from Senate review and approval.
  • Bittensor Logging Levels How Bittensor log levels help readers interpret message severity without treating logs as complete chain-state proof.
  • Bittensor Networks How Bittensor separates mainnet, testnet, and localnet contexts for primary use, shared testing, and local development.
  • Bittensor Tools How Bittensor tooling gives readers software surfaces for SDK, terminal, wallet, and network interaction.
  • Block How a block groups Bittensor transactions into an ordered blockchain record.
  • Chain Reads How chain reads describe looking at public Bittensor chain state without asking Subtensor to record a new action.
  • Duplicate Uids How the DuplicateUids error signals that a set_weights call repeated the same UID more than once in its uid list.
  • EVM Chain ID How the EVM chain ID identifies the Bittensor EVM network to Ethereum-style wallets and tools, with distinct values for mainnet and testnet.
  • Existential Deposit How existential deposit names the minimum TAO balance threshold for retaining a Bittensor account.
  • Extrinsics Extrinsics are Bittensor chain actions that ask the Subtensor runtime to process a state-changing operation.
  • Fast Blocks How fast blocks describe accelerated local block timing in Bittensor local development.
  • Inspecting the Chain with Polkadot.js How Polkadot.js helps readers inspect Bittensor chain state, metadata, blocks, and events while keeping observations tied to network and block context.
  • Invalid IP Type How the InvalidIpType error signals that a serve_axon or serve_prometheus call used an IP version other than IPv4 or IPv6.
  • Invalid Port How the InvalidPort error signals that a serve_axon or serve_prometheus call submitted a port value the runtime rejects as not a usable network port.
  • Invalid Reveal Commit Hash Not Match How the InvalidRevealCommitHashNotMatch error signals that a reveal_weights call submitted a hash the runtime could not pair with any non-expired committed hash for the caller.
  • Local Blockchain How a local blockchain provides an isolated Bittensor chain for development and testing.
  • Mainchain How Mainchain refers to the primary production Bittensor blockchain network.
  • Mempool How the Bittensor mempool holds pending transactions before block inclusion.
  • Mempool Visibility How pending transaction visibility creates MEV risk in Bittensor before block inclusion.
  • MEV Shield How Bittensor's MEV Shield hides sensitive transaction details before block inclusion to reduce mempool-based MEV risk.
  • Non-fast Blocks How non-fast blocks name ordinary local block timing in Bittensor development context.
  • Proposal How Bittensor governance uses proposals as Triumvirate-originated items for Senate review.
  • Proposal Hash How a proposal hash identifies a governance proposal during Bittensor Senate review and voting.
  • Public Subtensor How public Subtensor refers to publicly reachable Bittensor chain access.
  • Rate Limits How Bittensor rate limits use block-based cooldowns to pace repeated chain actions.
  • Replay Attack How a replay attack reuses a valid signed message, and how Bittensor's increasing, freshness-checked nonces keep a reused message from being accepted again.
  • Senate How the Senate functions as the proposal-review body in Bittensor governance.
  • Senator How a senator names the delegate role that votes on Triumvirate proposals inside Bittensor governance.
  • Subtensor How Subtensor names Bittensor's blockchain layer and system of record for transactions, rankings, and incentive flow.
  • Subtensor Constants How Subtensor runtime constants expose named reference values grouped by runtime area.
  • Subtensor Error Codes How Subtensor error-code families help Bittensor readers interpret failed chain actions.
  • Subtensor Events How Subtensor runtime events provide named records of Bittensor chain activity.
  • Subtensor Storage How Subtensor runtime storage entries organize Bittensor chain state by runtime area.
  • Sudo How Sudo refers to the privileged administrative authority that Bittensor governance is designed to replace.
  • Taopedia Taopedia is a wiki-style knowledge base organized as Markdown/MDX pages with rich frontmatter, internal links, categories, search, and an infobox layout.
  • Transaction Fees How Bittensor distinguishes base chain transaction fees from swap fees tied to stake-related actions.
  • Triumvirate How the Triumvirate functions as the proposal-origin body in Bittensor governance before Senate review.
  • UID Vec Contain Invalid One How the UidVecContainInvalidOne error signals that a set_weights submission named at least one UID that does not exist on the target subnet.
  • VPermit How VPermit represents the subnets where a delegate is authorized to validate.
  • Weight Vec Not Equal Size How the WeightVecNotEqualSize error signals that a set_weights call's uid list and value list did not have matching lengths.