Chain Reads
Chain reads describe looking at public Bittensor chain state without asking Subtensor to record a new action. Bittensor’s fee documentation treats reads as free inspection, while runtime actions can change state and involve fees (Transaction Fees in Bittensor, Subtensor extrinsics).
The term is about observation. It is separate from an extrinsic, transaction, or other action that asks the chain to process a change.
Read Scope
A chain read can show public state, metadata, blocks, storage values, or related records, but the read itself does not move TAO, change stake, register a role, or alter subnet settings (Subtensor Storage, Transaction Fees in Bittensor).
This distinction matters because inspection and action answer different questions. A read can show what is visible on chain, while an extrinsic asks the runtime to process a state-changing action (Subtensor extrinsics).
The useful reference point is the source of evidence. A chain read is evidence that a connected chain exposed a value or record; it is not evidence that a new chain action occurred.
That makes chain reads useful for checking public facts before describing them. The read can anchor the observation, but the claim should still name the surface that was read and avoid turning the observation into a broader mechanism claim (Inspecting the Chain with Polkadot.js, Subtensor Storage).
Inspection Surfaces
Different read targets answer different questions. Storage entries expose stored chain state, events record runtime activity, constants name runtime values, and blocks place observations in chain order (Subtensor Storage, Subtensor Events, Subtensor Constants, Glossary: Block).
The inspecting-the-chain guide places chain reads inside public chain inspection. A read can show what a selected surface contains, but it does not by itself explain every cause behind the displayed state (Inspecting the Chain with Polkadot.js).
The surface distinction keeps read evidence precise. Storage entries describe stored state, events describe emitted records, constants describe runtime reference values, and blocks describe ordering context. A chain read should preserve which surface supplied the evidence (Subtensor Storage, Subtensor Events, Subtensor Constants, Glossary: Block).
Constants and storage entries are both readable, but they do not answer the same question. Reading a constant is reference inspection; reading storage is state inspection. Both can be chain reads, but the source surface changes how the result should be described (Subtensor Constants, Subtensor Storage).
Runtime metadata belongs beside those read surfaces as structure evidence. It shows available runtime structure, while storage and events show recorded values and emitted records in context (Inspecting the Chain with Polkadot.js, Subtensor Storage, Subtensor Events).
Fee and Action Context
Read-only inspection is separate from state-changing actions, so fee language belongs with the action unless the point is specifically that a read is free (Transaction Fees in Bittensor, Subtensor extrinsics).
That boundary keeps chain-read vocabulary from being treated as transaction vocabulary. A read can inform a later decision, but the read itself is not the fee-bearing action.
The fee split also keeps article prose from overclaiming. A read may be part of understanding chain state before an action, but the action and its fee behavior belong to the transaction or extrinsic surface, not to the read itself (Transaction Fees in Bittensor, Subtensor extrinsics).
Evidence Context
Chain reads are evidence of visible public chain state from the selected read surface. They are strongest when paired with the surface type being used: storage state, an emitted event, a runtime constant, or a block-context observation (Subtensor Storage, Subtensor Events, Subtensor Constants, Glossary: Block).
That evidence still has limits. A storage read can show a recorded value, but surrounding mechanism documentation may be needed to explain why the value exists. An event can show that runtime activity was emitted, but the event name is not the same as the full action reference (Subtensor Events, Subtensor extrinsics).
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For chain reads, that sequence changes how readers should interpret storage, event, and block-height examples.
In localnet, chain reads can be tested against an isolated local blockchain. Localnet storage and event surfaces do not represent production chain history.
On testnet, read-only inspection can be exercised in a shared non-production network. Testnet block heights and storage entries are separate from mainnet state.
On mainnet, chain reads concern live production Subtensor state at selected block heights. Observed values depend on the network, surface, and block context where the read was taken (Inspecting the Chain with Polkadot.js).
The Bittensor Networks reference separates mainnet, testnet, and localnet. A chain-read example from one environment should not be read as representing production chain state in another environment.
Relationship to Yuma Consensus
Chain Reads 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, chain reads 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
Chain reads identify read-only observation. They do not prove intent, predict a later action, replace mechanism documentation, or show private state that is not on chain (Inspecting the Chain with Polkadot.js, Subtensor Storage).
Use the term when the article is about observing public chain state.
Runtime Calls Stay on the Read Path
The inspecting-the-chain guide places runtime calls on a read-only path that can return computed answers such as bundled subnet information or fee estimates without submitting a state-changing extrinsic (Inspecting the Chain with Polkadot.js, Runtime Calls).
That keeps runtime-call results inside chain-read vocabulary when the question is inspection rather than submission.
Block Context Narrows Historical Reads
A value read from one point in chain history should not automatically be treated as the value at every later point on the same network (Glossary: Block, Subtensor Storage).
Chain-read examples should keep block and network context attached when the observed value matters.
Network and Block Context
A chain read belongs to the network being inspected. Mainnet, testnet, and localnet are separate Bittensor network contexts, so an observation from one environment should not be treated as the chain history of another (Bittensor Networks, Inspecting the Chain with Polkadot.js).