Subtensor
Subtensor is Bittensor’s layer 1 blockchain.
It is the system of record for transactions, rankings, Yuma Consensus, and incentive flow. It is the chain layer beneath subnet markets rather than a single subnet, role, token, or interface (Glossary: Subtensor, Introduction to Bittensor).
The term is useful because it separates the blockchain record from the subnet markets built on top of it. Subnets define work and evaluation contexts; Subtensor supplies the shared protocol layer where recorded activity, consensus results, and tokenomics flow are anchored (Understanding Subnets).
System of Record
Subtensor records the protocol-side history that Bittensor relies on for balances, transactions, rankings, staking context, and subnet-related outcomes. This system-of-record role is broader than any one subnet application, because many subnet markets use the same underlying chain layer (Glossary: Subtensor).
That boundary keeps the vocabulary precise. A subnet can define the task and evaluation design for a market, while Subtensor records the chain-side activity around that market. The article-level term Subtensor therefore points to the record layer, not to a particular market’s work product (Introduction to Bittensor).
Consensus and Incentive Context
Yuma Consensus runs within the Subtensor context. Validator rankings of miner performance are aggregated into miner incentives and validator dividends, and those outcomes belong to Bittensor’s recorded incentive flow (Yuma Consensus, Glossary: Subtensor).
This does not make Subtensor a synonym for Yuma Consensus. Subtensor names the chain layer and recording context; Yuma Consensus names a consensus process that uses validator evaluations to shape reward allocation. Keeping the terms separate helps distinguish the protocol layer from one of the processes that runs inside it (Glossary: Validator Weights).
Chain Vocabulary Context
Subtensor is built on Substrate within the Polkadot SDK stack. That foundation explains why related Bittensor references use vocabulary such as blocks, runtime storage, and extrinsics when discussing recorded activity on the chain (Glossary: Subtensor, Glossary: Block).
Those neighboring terms answer narrower questions. A block is an ordered unit of chain data, and an extrinsic is a signed action intended for chain inclusion. Subtensor is the broader blockchain layer where those units and actions fit (Glossary: Extrinsics).
This also explains why Subtensor reference pages discuss storage, events, and extrinsics as related surfaces. They describe different ways the chain layer exposes state, records activity, and accepts submitted actions (Subtensor Storage, Subtensor Events, Subtensor extrinsics).
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. Subtensor can be discussed across Bittensor network environments, but an example from one environment should not be treated as evidence for every other environment (Bittensor Networks).
Localnet examples can illustrate the Subtensor concept in isolation. Testnet examples add shared non-production chain history. Mainnet Subtensor interpretation concerns production chain records on the active network.
Subtensor examples should keep the environment label attached. The chain-layer concept stays stable, but the observed state belongs to the network where it was recorded (Glossary: Local Blockchain).
Emission Context
Subtensor is also the chain context for emission processing. Emission describes the broader creation and allocation flow for TAO and alpha, while Subtensor is the system of record around the chain-side incentive outcomes (Emissions, Glossary: Subtensor).
Emission and Subtensor therefore answer different questions. Emission explains the reward and allocation flow; Subtensor names the blockchain layer where recorded activity and incentive outcomes are anchored (Emissions, Glossary: Subtensor).
Relationship to Yuma Consensus
Subtensor and Yuma Consensus describe related parts of Bittensor’s incentive system. Yuma Consensus is the on-chain process that aggregates validator weight signals within a subnet into miner incentives and validator dividends, applying consensus clipping, bonding, and emission calculation (Yuma Consensus).
For readers, subtensor names a specific part of that incentive picture, while Yuma Consensus names the consensus process that turns validator weights into the resulting incentives and dividends.
Reader Boundary
Subtensor is a protocol reference term for Bittensor’s blockchain layer. It is not an infrastructure operations guide, a subnet ranking report, an endpoint availability report, or a catalog of interface calls. Claims about a particular network environment, node-access surface, or exact chain value need the relevant source for that context (Subtensor Nodes, Bittensor Networks).
The stable article-level point is that Subtensor names the chain layer and system of record. More specific references should be used when the reader needs storage entries, events, extrinsics, network access, or node-operation details (Subtensor Storage, Subtensor Events, Subtensor extrinsics, Subtensor Nodes).
Metagraph State Is Recorded on Subtensor
The Subnet Metagraph documentation describes the metagraph as implemented on the Bittensor blockchain (Subtensor) as a Rust data structure. On a subnet such as netuid 1, neuron fields therefore live in Subtensor’s recorded state rather than in a separate off-chain ledger.
That placement keeps Subtensor as the system-of-record layer beneath subnet markets. Subnets define evaluation context; Subtensor stores the structured participant snapshot readers query at a block height (Glossary: Metagraph).
Extrinsics Are the Signed Action Surface
Subtensor extrinsics documentation describes extrinsics as the runtime actions participants submit for chain inclusion. Registration, staking moves, weight commits, and governance calls therefore enter Subtensor history as signed extrinsics rather than as informal off-chain messages.
Subtensor names the chain layer that accepts those actions; each extrinsic still carries its own meaning from the relevant mechanism reference once included in a block.
Events and Storage Expose Post-Inclusion Records
After inclusion, Subtensor exposes activity through complementary surfaces. Subtensor Events name runtime records emitted during processing, while Subtensor Storage exposes readable state entries. Together they help interpret what the chain recorded once an extrinsic is accepted.
Those references answer post-inclusion questions. Pending mempool visibility concerns what can be seen before a block exists; events and storage concern recorded chain context afterward.