Netuid
A netuid is the identifier used to select a Bittensor subnet context. Official Bittensor documentation uses netuid values when describing subnet-specific state, including metagraph data for a selected subnet.
References: Glossary: Netuid, The Subnet Metagraph
Subnet Context
The useful meaning of a netuid is contextual: it tells readers which subnet is being discussed. A metagraph, validator weights, miner registrations, and many subnet-level values are interpreted inside that selected subnet context rather than across the whole Bittensor network at once.
Reference: The Subnet Metagraph
Why It Matters
Netuids help separate subnet-specific state. A reader may see the same kind of value, such as a UID slot or a validator weight, but its meaning depends on the subnet selected by the netuid. This keeps subnet discussions precise and avoids mixing state from different subnet markets or mechanisms.
References: Glossary: Netuid, Glossary: Metagraph
Netuid and UID
Netuid and UID are distinct identifiers. A netuid identifies a subnet, while a UID identifies a participant position within that subnet. The official Glossary: UID Slot describes a UID slot as a position within a subnet occupied by a miner or validator and identified by a unique UID. The Glossary: Netuid places netuid as the subnet-level identifier. Keeping the two separate matters because a participant’s UID is scoped to a specific subnet: the same UID number can appear in multiple subnets and may refer to entirely different participants in each.
References: Glossary: Netuid, Glossary: UID Slot
Metagraph Queries Use Netuid
Subnet metagraph data is always read for a selected netuid. The official Subnet Metagraph documentation describes the metagraph as a snapshot of subnet state, and Bittensor tooling selects which subnet market that snapshot represents through the netuid value passed to the query.
For readers, a metagraph row without an attached netuid is incomplete. The same field name can appear in more than one subnet, but its meaning belongs to the subnet identified by the netuid used in the query.
References: Subnet Metagraph, Glossary: Netuid
Subnet Hyperparameters Belong to a Netuid
Each subnet’s hyperparameter set is scoped to its netuid. The official Subnet Hyperparameters reference describes configurable subnet settings such as tempo, registration burn bounds, and weights rate limits as properties of one subnet market rather than as global constants for the whole network.
When readers encounter a hyperparameter name in subnet prose, they should ask which netuid’s subnet configuration is being discussed. A value that applies on one netuid does not automatically carry over to another.
References: Subnet Hyperparameters, Glossary: Netuid
Subnet Zero as a Netuid
Subnet Zero is itself a netuid with special rules. The Glossary: Root Subnet/Subnet Zero describes Root as a special subnet where miners cannot register and no validation work is performed, while validators can register and TAO holders can stake in a subnet-agnostic way.
That makes netuid selection especially important at zero. Root shares the netuid identifier pattern with other subnets, but its participant rules and staking role differ from an ordinary mining subnet market.
References: Glossary: Root Subnet/Subnet Zero, Understanding Subnets
Relationship to Multiple Mechanisms
A netuid selects one subnet context inside Bittensor. The Glossary notes that each subnet has one or more incentive mechanisms.
For readers, a netuid still identifies which subnet market is being discussed. Subnet-specific values such as weights or incentives should be read with that netuid in mind, including when the subnet runs more than one incentive mechanism.
References: Multiple Incentive Mechanisms Within Subnets, Glossary: Incentive Mechanism
Relationship to Register
A netuid and register are related but different parts of Bittensor subnet vocabulary. Register describes the subnet-entry process that grants a participant a UID slot, while a netuid selects which subnet that entry targets. The Glossary: Register describes subnet entry, and the Glossary: Netuid places netuid at the subnet-selection level.
For readers, register names how a participant enters a subnet, while a netuid names which subnet market that entry applies to. Registration language is incomplete without the netuid that selects the destination subnet context.
References: Glossary: Register, Glossary: Netuid
Relationship to Active UID
A netuid and an active UID are related but different identifiers inside Bittensor subnet vocabulary. A netuid selects which subnet is in scope, while an active UID identifies an active participant slot within that selected subnet. The Glossary: Netuid places netuid at the subnet level, and the Glossary: Active UID places active status at the participant-slot level inside one subnet.
For readers, netuid answers which subnet market is being discussed, while an active UID answers which slot inside that subnet currently counts as active. Active status should always be read together with the netuid that selects the subnet context.
References: Glossary: Netuid, Glossary: Active UID
Relationship to Subnet Hyperparameters
A netuid and subnet hyperparameters are related but different parts of subnet configuration vocabulary. A netuid selects one subnet context, while subnet hyperparameters describe configurable settings that apply within that subnet. The Subnet Hyperparameters reference lists values such as tempo, activity windows, and slot limits for a selected subnet.
For readers, netuid is the selector, while hyperparameters are the subnet-specific settings read
after that selection. Values such as max_allowed_uids or activity_cutoff belong to one netuid’s
subnet context rather than to the whole Bittensor network at once.
References: Glossary: Netuid, Subnet Hyperparameters
Relationship to Bittensor Networks
A netuid and Bittensor Networks address related but different parts of deployment context. The Bittensor Networks reference separates mainnet, testnet, and localnet, while a netuid identifies a subnet market inside whichever network environment is being used. Subnet identifiers are read against the active network context, not as network-agnostic labels.
For readers, Bittensor Networks names the deployment environment, while a netuid names a subnet inside that environment. Comparing subnet state across mainnet and testnet requires keeping both the network context and the netuid selection explicit.
References: Bittensor Networks, Glossary: Netuid
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from local testing to testchain and then mainchain. For a netuid, that sequence changes how readers should interpret evidence about a selected subnet context.
In local testing, a netuid can identify a subnet inside an isolated development environment. That is useful for checking whether subnet-specific state is being selected correctly, but it does not show public network identity or production subnet state.
On testchain, a netuid can identify a subnet in a shared testing network. This gives stronger evidence about how subnet-specific state behaves with other participants than a private local run, while still keeping the result separate from production mainchain activity.
On mainchain, a netuid identifies a live subnet context. The Subnet Metagraph documentation uses netuid to select a subnet snapshot, so production readings should keep both the network environment and the selected subnet identifier attached.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A netuid observed in one environment should not be read as identical evidence about a subnet with the same identifier in another environment.
This distinction is especially important because a netuid is a selector, not the whole subnet description. It tells readers which subnet context is in scope, while the network environment tells them what kind of evidence that selection represents.
For readers, this keeps netuid examples from sounding stronger than their environment supports. Local, testchain, and mainchain contexts can all use netuids, but they do not carry the same interpretive weight.
Relationship to Tempo
A netuid and tempo address related but different parts of subnet timing vocabulary. A netuid selects one subnet context on the network, while tempo names the block-based cadence that governs epoch transitions inside that selected subnet. The Glossary: Netuid places netuid at the subnet level, and the Glossary: Tempo describes tempo as the subnet-specific cadence for epochs.
For readers, a netuid answers which subnet is being discussed, while tempo names the periodic cadence configured inside that subnet’s context.
References: Glossary: Netuid, Glossary: Tempo
Relationship to Yuma Consensus
A netuid and Yuma Consensus address related but different parts of Bittensor subnet vocabulary. A netuid identifies a subnet market on the network, while Yuma Consensus describes how validator weight signals inside that subnet are aggregated into miner incentives and validator dividends. The Glossary: Netuid places netuid at the subnet level, and Yuma Consensus describes within-subnet clipping, bonding, and emission calculation.
For readers, a netuid selects the subnet context, while Yuma Consensus names the consensus process that runs inside that context.
References: Glossary: Netuid, Yuma Consensus
Relationship to Emission
A netuid and emission address related but different parts of Bittensor reward vocabulary. A netuid identifies a subnet market on the network, while emission names the full generation and allocation process that distributes currency to participants inside and across subnets. The Glossary: Netuid places netuid at the subnet level, and the Glossary: Emission describes the combined injection and distribution process.
For readers, a netuid answers which subnet is being discussed, while emission names the broader process through which that subnet receives and distributes rewards.
References: Glossary: Netuid, Glossary: Emission
Relationship to Flow-Based Emissions
A netuid and flow-based emissions address related but different parts of cross-subnet tokenomics vocabulary. A netuid identifies one subnet on the network, while flow-based emissions describe how subnets are compared for TAO injection share from net TAO flow across the network. The Glossary: Netuid places netuid at the subnet level, and the Emission: Distribution across subnets documentation describes cross-subnet allocation from net TAO flow.
For readers, a netuid names one subnet being discussed, while flow-based emissions name the cross-subnet comparison model used when deciding injection share among identified subnets.
References: Glossary: Netuid, Emission: Distribution across subnets
Relationship to Crowdloans
A netuid and crowdloans address related but different parts of Bittensor subnet vocabulary. A netuid identifies a specific subnet on the network, while subnet crowdloans are a collective funding mechanism through which community members contribute TAO to help cover a subnet’s registration or lease costs. The Crowdloans documentation describes crowdloans as enabling community-level participation in subnet funding, with contributor shares recorded on chain and subnet alpha emissions distributed pro-rata to contributors. The Glossary: Netuid places netuid at the subnet-selection level inside Bittensor.
Subnet crowdloans for registration or leasing are scoped to one specific subnet, which is identified by its netuid. The Crowdloans documentation notes that the subnet’s alpha emissions are swapped to TAO before distribution, so contributors receive TAO rather than alpha tokens.
References: Crowdloans, Glossary: Netuid
Reader Boundary
This page defines the term. It does not list current subnet names, live identities, registration state, or current subnet counts. Those values change with chain state and should be checked from current Bittensor sources when needed.
Relationship to Coinbase
A netuid and coinbase are related but different parts of how a subnet is identified and how its emissions are produced. A netuid is the unique identifier that selects which subnet context is in scope. Coinbase is the per-block protocol mechanism that drives TAO emission, injects TAO into emitting subnets’ pool reserves, accumulates pending emissions, and checks epoch boundaries to trigger Yuma Consensus rounds. The Glossary: Netuid defines the subnet identifier, and the Coinbase Implementation documentation describes the per-block emission operation.
A netuid is the selector coinbase uses to keep each subnet’s emission accounting separate. When coinbase runs, it accumulates pending emissions and applies epoch logic per subnet, and the netuid is what distinguishes one subnet’s reserves, pending emissions, and epoch boundary from another’s. The netuid performs no emission itself; it scopes which subnet a given coinbase operation acts on. One names which subnet is being discussed, while the other names the mechanism that produces and distributes that subnet’s emissions.
Staking and Pool State Are netuid-Local
The Staking and delegation overview describes staking as local to a subnet. A netuid therefore selects which subnet market holds delegated stake, alpha-denominated positions, and pool reserves rather than naming a global balance label detached from subnet context (Understanding Subnets).
Readers comparing stake on netuid 1 with stake on another subnet should keep the netuid attached. Subnet-local vocabulary applies to delegation, slippage, and alpha price reading on the selected subnet.
Metagraph Snapshots Read One netuid at a Time
Subnet Metagraph documentation describes the metagraph as a subnet snapshot keyed by netuid. Netuid vocabulary therefore marks which participant set, hyperparameter context, and subnet fields are in scope for a given read.
That scoping keeps metagraph evidence subnet-specific. A UID or validator field observed under one netuid does not by itself describe participant state on another subnet (Glossary: Metagraph).