Subnet
A subnet is a specialized market inside Bittensor for a particular kind of digital work (Glossary: Subnet, Understanding Subnets).
The term names the context where miners produce work, validators evaluate that work, and incentive mechanisms turn evaluation into emission outcomes.
Market Scope
A subnet narrows Bittensor’s work into a particular market rather than treating all useful work as one undifferentiated task. Subnet documentation describes each subnet as having its own goal and standards (Understanding Subnets, Introduction to Bittensor).
This makes subnet a root concept for reading Bittensor. A subnet names where a specific kind of work is requested and evaluated.
Miner and Validator Roles
Miners and validators give a subnet its work-and-evaluation structure. Miners produce the requested digital commodity, and validators measure whether that work meets the subnet’s standards (Glossary: Subnet, Understanding Subnets).
For readers, a subnet is not only a topic label. It is the setting where work is produced, evaluated, and interpreted through Bittensor incentives.
Incentive Mechanism Context
A subnet runs one or more incentive mechanisms that define the task, protocol, and evaluation path for its market. Incentive-mechanism documentation places those parts together inside subnet design (Glossary: Incentive Mechanism, Understanding Incentive Mechanisms).
Readers comparing subnets should therefore ask what work the subnet requests and how that subnet evaluates responses.
Relationship to the Network
Subnets are part of Bittensor, not separate blockchains. The introduction places subnets alongside the blockchain, TAO, and open-source tools as parts of the platform (Introduction to Bittensor, Glossary: Subnet).
That distinction keeps subnet from being used as a synonym for the whole Bittensor network. A subnet is one work market context inside the network.
Multiple-Mechanism Context
A subnet is often discussed through one mechanism at a time, but Bittensor also supports more than one incentive mechanism inside the same subnet (Multiple Incentive Mechanisms Within Subnets, Glossary: Incentive Mechanism).
When that happens, rules and standards for one mechanism should not automatically be treated as the whole subnet’s only evaluation path.
Relationship to Yuma Consensus
Subnet and Yuma Consensus describe different parts of Bittensor vocabulary. A subnet names the specialized work market where miners and validators operate, while Yuma Consensus aggregates validator weight signals into emission outcomes (Understanding Subnets, Yuma Consensus).
For readers, a subnet names where evaluation happens. Yuma Consensus names the process that resolves validator signals from that context.
Reader Boundary
Subnet should be read as the general concept for a Bittensor work market. It is not a status report, quality guarantee, launch guide, or complete description of a subnet’s rules (Glossary: Subnet, Understanding Subnets).
The stable article-level point is that a subnet organizes specialized digital work, miner production, validator evaluation, and incentive context inside Bittensor.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. The subnet concept applies across the Bittensor lifecycle: subnets can be developed in localnet for isolated testing, exercised on testnet for shared non-production evaluation, and deployed on mainnet for live operation with real emissions.
The Bittensor Networks reference separates mainnet, testnet, and localnet. Subnet examples or incentive outcomes from one environment should not be read as representing production subnet performance in another environment.
Each Subnet Is Selected by netuid
The Glossary: Netuid defines netuid as the subnet identifier used when reading subnet-specific state. Subnet vocabulary names the work market concept; netuid names which instance of that market is in scope, such as netuid 1 on mainnet (Understanding Subnets).
Readers comparing subnets should attach the netuid whenever they cite participant sets, hyperparameters, or staking pools. The same subnet concept can exist on different networks with separate netuid registries (Bittensor Networks).
Subnet Markets Use Local Pool and Emission Context
Understanding Subnets places each subnet inside Bittensor’s Dynamic TAO design with local staking pools and emission routing. A subnet therefore names a specialized market with its own participant evaluation path, not a generic label detached from pool or incentive context (Emission).
Subnet reading should stay tied to that local market frame. Yuma Consensus and validator weights describe how evaluation inside one subnet becomes emission outcomes for that subnet’s participants (Yuma Consensus).