Subtensor Storage
Subtensor storage entries are named places where Bittensor’s Subtensor runtime exposes chain state for inspection (Subtensor Storage, Inspecting the Chain with Polkadot.js).
They help readers find which state surfaces exist, how those surfaces are named, and how an inspected value should stay tied to its chain context.
What Storage Shows
Storage entries name places where runtime state is exposed for inspection. A storage entry can identify the runtime area, entry name, type, lookup shape, and summary for a state surface (Subtensor Storage, Subtensor Constants).
This makes storage a map of readable runtime state rather than a full explanation of every mechanism that changes that state. A value read from a storage surface still belongs to the network and block context where the read happened.
Generated Reference Shape
The generated storage reference identifies entries through the api.query.<Pallet>.<storage_item>
shape (Subtensor Storage). That path keeps
the runtime area and storage item name attached in one lookup label.
The listing records generated-reference metadata for the connected Subtensor runtime, including the endpoint used to build the page (Subtensor Storage). That gives readers a source for the storage surface rather than leaving the entry name as an isolated label.
Each entry can include a type, modifier, interface path, and summary. The modifier helps show whether the storage item is required or optional in the generated reference, while the summary gives the short description attached to that state surface (Subtensor Storage).
Storage Entry Examples
The storage listing includes general runtime areas and Bittensor-specific areas. Examples include
balances, safeMode, subtensorModule, system, timestamp, and transactionPayment
(Subtensor Storage).
Some entries expose general chain state. The generated reference lists adminUtils.palletVersion as
a required u16 storage item summarized as returning the current pallet version from storage
(Subtensor Storage).
Other entries expose account or balance-related state. The same reference includes
balances.account as a storage surface for account-balance data
(Subtensor Storage).
Subtensor-module storage entries expose Bittensor-specific state surfaces. The generated listing includes entries for subnet activity, emission accounting, stake relationships, and feature settings, with each entry keeping its storage item name, type, and summary together (Subtensor Storage).
Where Entries Appear
Storage entries are grouped by runtime area. The owning area is part of the entry’s meaning because similarly named state surfaces can carry different context in different runtime areas (Subtensor Storage, Inspecting the Chain with Polkadot.js).
For readers, the runtime area is the first layer of interpretation. The area says which part of the runtime owns the entry before the entry name and type narrow the meaning.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Subtensor storage, that sequence changes which network and block context a reader should assume when interpreting a storage read.
In localnet, storage surfaces can be inspected against an isolated local blockchain. Localnet storage values do not represent production chain state.
On testnet, storage reads can be exercised in a shared non-production network. Testnet entries are separate from mainnet state (Inspecting the Chain with Polkadot.js).
On mainnet, Subtensor storage concerns live production chain state at the selected block height on the connected network (Subtensor Storage).
The Bittensor Networks reference separates mainnet, testnet, and localnet. A storage example from one environment should not be read as representing production chain state in another environment.
Reader Boundary
The storage listing tells readers where state is exposed. A chain read or inspection view can then show a value from a selected network and block context (Subtensor Storage, Bittensor Networks).
The entry name tells readers which surface was inspected; the returned value tells readers what that surface showed in the chain context where the read happened.
Storage, Events, and Extrinsics
Storage, events, and extrinsics describe different Subtensor surfaces. Storage exposes state, events name emitted runtime records, and extrinsics name submitted runtime actions (Subtensor Storage, Subtensor Events, Subtensor extrinsics).
A feature can involve all three surfaces without making them interchangeable. Storage answers what state surface can be read; events answer what runtime record was emitted; extrinsics answer what action was submitted.
For example, after a submitted action is processed, an event can show what the runtime recorded and a storage read can show a relevant state surface afterward. Those are related observations, but they are not the same artifact (Subtensor Events, Subtensor extrinsics).
Storage Maps Need Keys Before a Read
The Inspecting the Chain with Polkadot.js guide draws a practical line between two storage shapes in the chain-state view. Some storage items are single values that can be queried without extra input, while others are maps keyed by an account, a netuid, or another identifier.
Map-shaped entries need that key filled in before a read can return a value. A subnet-scoped surface such as immunity period therefore belongs to one netuid at a time, and an account-balance surface belongs to one account at a time. A global spacing value for subnet registration can be queried without that extra key field.
That key step sits between the storage listing and the returned value. The catalog shows the entry name and type shape, while the supplied key narrows which row of mutable chain state is being read (Subtensor Storage).
References: Inspecting the Chain with Polkadot.js, Subtensor Storage
The Storage Catalog Follows Runtime Spec
The Subtensor Storage reference is generated from the connected Subtensor runtime spec rather than maintained as a standalone prose list. Its grouped entries describe the storage surfaces the runtime exposes at generation time, including metadata about the endpoint used when the page was built.
Runtime upgrades can change that exposed surface by adding, renaming, or retiring storage items. Inspection guidance notes that runtime metadata must be refreshed after a Bittensor runtime upgrade so connected tools still describe the live chain accurately (Inspecting the Chain with Polkadot.js).
That generation link separates catalog vocabulary from observed chain history. A listed storage entry names a surface the runtime can expose, while a value returned from a particular network and block belongs to that moment in chain history on the connected Subtensor network.
References: Subtensor Storage, Inspecting the Chain with Polkadot.js
Runtime Calls Are Not Storage Reads
Direct storage queries read named state surfaces from chain storage. The same inspection guide places runtime calls on a neighboring read-only path that executes functions which may involve computation rather than returning one stored value alone (Inspecting the Chain with Polkadot.js).
Official examples include bundled subnet information that covers price, emission, and reserve- related fields, along with fee estimation for a proposed extrinsic length. Those answers can draw on storage internally, but they are returned as computed read-only results rather than as one labeled storage item from the catalog.
When a question needs a catalogued state surface, storage vocabulary is the natural starting point. When the question needs a derived or bundled answer, runtime-call vocabulary may fit better even though both paths stay on the inspection side of the chain.
References: Inspecting the Chain with Polkadot.js, Runtime Calls
Network and Block Context
Storage values are scoped by chain history. The same storage entry name can be meaningful across environments, while returned values belong to separate network and block contexts (Bittensor Networks, Inspecting the Chain with Polkadot.js).
Practical Limits
Subtensor storage can show what state was exposed at an inspected chain context, but it does not prove off-chain intent or fully explain why that state changed (Subtensor Storage, Subtensor Events).
When a concrete question depends on cause or result, the storage value should be read alongside the submitted action, emitted events, and the relevant concept page. That gives readers more context than the storage entry name alone.