Block
A block is a unit of data in the Bittensor blockchain. It contains transactions and has a unique identifier called a block hash (Glossary: Block, Glossary: Subtensor).
The term matters because it separates accepted chain history from pending transaction context. A transaction waiting in the mempool is not yet the same as a transaction included in a block.
After inclusion, the block gives readers the chain-history location for the transaction. Events and storage can then supply runtime-record and state context around that included activity (Subtensor Events, Subtensor Storage).
Chain Unit Context
Blocks give chain activity an ordered record. In Bittensor, the block concept belongs to Subtensor, the layer 1 blockchain and system of record for transactions and rankings (Glossary: Block, Glossary: Subtensor).
A block is not a role, reward rule, or subnet mechanism. It is a blockchain data unit that records included transactions.
The block hash is part of that reference value. It gives the block a specific identifier, while the transactions inside the block remain separate runtime actions with their own meanings (Glossary: Block, Subtensor extrinsics).
Block Hash Boundary
A block hash identifies the block as an ordered chain-history unit; it is not the same thing as the runtime action inside that block. The block glossary places the hash on the block itself, while extrinsic documentation describes the submitted calls that can be included within block history.
For readers, that means a block hash is useful for locating the chain context around activity. The meaning of the included transaction or call still comes from the relevant extrinsic, event, storage, or mechanism reference.
References: Glossary: Block, Subtensor extrinsics
Timing Context
Bittensor documentation presents ordinary public-network block processing around a twelve-second cadence, while local development context can use different local timing modes (Glossary: Block, Bittensor Networks, Glossary: Fast blocks).
That timing context should be read with the network environment attached. Mainnet, testnet, and localnet examples are not interchangeable just because they all use block vocabulary.
Mempool Boundary
The mempool is the pending-transaction holding area before block inclusion. A block is the ordered unit that includes accepted transactions (Glossary: Mempool, Glossary: Block).
This distinction is the most useful way to read the pair: mempool means waiting before inclusion; block means recorded after inclusion.
That is why mempool visibility and block evidence support different safety questions. Mempool visibility concerns exposed pending details; a block confirms that accepted transactions were included in chain history (MEV Shield, Glossary: Block).
Extrinsic Boundary
Extrinsics are runtime actions. Blocks are the chain data units that can include and order accepted extrinsics (Subtensor extrinsics, Glossary: Block).
Extrinsic names the action surface, while block names the ordered record that can contain accepted actions.
Fee Boundary
Transaction fees belong to state-changing actions that the chain processes. Blocks are where accepted transaction records are ordered, so fee-bearing actions and block inclusion are adjacent concepts rather than synonyms (Transaction Fees in Bittensor, Glossary: Block).
The block itself names the chain unit. Fee rules describe cost accounting for state-changing actions.
Storage and Event Boundary
Storage entries and events are related chain-observation surfaces, but they do not mean the same thing as a block. Storage describes recorded state, while events describe emitted runtime records (Subtensor Storage, Subtensor Events).
A block can provide the ordered context in which chain activity is recorded. Storage and events help interpret what the chain contains or emitted around that context.
For a concrete included transaction, the surrounding references each add a different kind of detail. The extrinsic reference names the runtime action, fee documentation explains cost components for state-changing actions, events name runtime records, and storage exposes readable state surfaces (Subtensor extrinsics, Transaction Fees in Bittensor, Subtensor Events, Subtensor Storage).
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. Block examples need that context because chain history, inclusion records, and metagraph snapshots belong to the network where they were observed (Bittensor Networks).
Localnet block examples are isolated development examples. Testnet examples add shared non-production chain history. Mainnet block interpretation concerns production Subtensor records on the active network.
A block example from one environment should not be treated as proof about another environment. They use the same block concept, but not the same chain history.
Relationship to Yuma Consensus
Block 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, block 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
Block should be read as chain-history vocabulary. It names a Bittensor blockchain data unit that contains transactions and has a block hash (Glossary: Block, Glossary: Subtensor).
Mempool, extrinsic, fee, storage, event, and network references remain useful because they explain nearby questions that the block term alone does not answer.
Metagraph Snapshots Anchor to One Block Height
The Subnet Metagraph documentation describes
the metagraph as subnet state at a particular block height and lists a block field for the height
when the snapshot was retrieved. On a subnet such as netuid 1, that number ties incentive fields to
one point in chain history rather than to a timeless summary.
Block vocabulary therefore locates subnet snapshots in time. A metagraph reading should keep both the selected netuid and the block height attached when neuron fields are interpreted.
Registration Records Include Block Heights
The metagraph reference includes block_at_registration as registration blocks for each neuron,
used for immunity period
calculations. A block number therefore
marks when a participant entered a subnet, not only when a snapshot was taken.
That timing field connects block units to participant lifecycle vocabulary. Registration block heights belong to chain history, while pending mempool activity still waits before inclusion.
Tempo Counts Blocks Between Emission Steps
The Glossary: Tempo defines tempo as the subnet-specific block interval over which Yuma Consensus calculates emissions from the latest available ranking weight matrix. Metagraph metadata also exposes tempo and blocks-since-last-step fields tied to subnet update rhythm.
Block numbers therefore mark both inclusion history and subnet timing boundaries. A tempo interval is measured in blocks, while each included transaction still lands inside one ordered block record.