Subtensor Error Codes
Subtensor error codes are diagnostic signals from the blockchain layer beneath Bittensor. They help identify why a chain action failed, but they do not provide the full surrounding context by themselves (Subtensor Error Codes, Subtensor Standard Errors, Subtensor API Errors).
The term is useful as rejection vocabulary. An error code points toward a rule family, while the relevant action, subnet context, network context, and mechanism documentation explain how that family should be interpreted.
Diagnostic Scope
The Subtensor error overview groups failures into standard Subtensor errors, custom errors, and errors inherited from the underlying Substrate framework (Subtensor Error Codes).
That grouping makes error codes classification signals. A short label can tell a reader where to start, but it should not be treated as a complete reconstruction of every condition that led to the rejection.
The public error overview also describes returned failures with separate code, message, and
data fields (Subtensor Error Codes). Those fields keep
two layers of meaning apart. The numeric or named error identifies the broad failure signal, while
the surrounding message and data describe how that signal was exposed by the chain interface.
The generated Subtensor API errors reference adds another layer: runtime error variants are grouped
by pallet and exposed through paths shaped like api.errors.<Pallet>.<ErrorName>
(Subtensor API Errors). That format keeps
the runtime area and error name together, which helps readers avoid treating a short error name as
complete without its owning pallet.
The generated page also pairs each api.errors path with a short summary. For example, an error
entry can identify the pallet, exact API label, and short description attached to that runtime error
variant (Subtensor API Errors).
That distinction matters for interpretation. A reader can use the returned format to identify the error family, then use the standard-error or custom-error references to understand what kind of Subtensor rule was involved (Subtensor Standard Errors, Subtensor Custom Errors).
Standard and Custom Families
Standard errors describe named failure categories from the Subtensor layer, while custom errors list numeric conditions with short descriptions (Subtensor Standard Errors, Subtensor Custom Errors).
Both families are lookup vocabulary. A standard error can name a broad Subtensor condition, and a custom error can identify a more specific chain condition. Neither family, by itself, proves the entire cause without the surrounding chain context.
The generated API reference complements those lists by showing error variants in their runtime area. A balances error, a system error, and a subtensor-module error are all Subtensor-facing failure vocabulary, but the pallet grouping narrows which runtime area supplied the error variant (Subtensor API Errors).
Substrate errors form the third family in the upstream overview. They are inherited from the underlying framework on which Subtensor is built, so they are best read as chain-layer failures rather than as Bittensor-specific mechanism names (Subtensor Error Codes).
The family label also says something about where to look next. Standard and custom Subtensor errors point back to Bittensor chain rules, while inherited Substrate errors may reflect lower-level transaction, dispatch, or framework checks before a reader reaches a Bittensor mechanism-specific explanation.
That makes the family label a routing aid. It points the reader toward the relevant error table or runtime area, while the action that failed still supplies the rest of the interpretation context.
Family and Cause Boundary
An error family is not always the whole cause. A balance-related failure identifies a balance condition, while a subnet-related failure identifies a subnet condition, but the reason that condition appeared depends on the action and context being checked (Subtensor Standard Errors, Subtensor Custom Errors).
This keeps error-code prose different from a troubleshooting transcript. A reference article can name the failure vocabulary and explain how to read it across many possible cases without reproducing tool output or prescribing a recovery path.
The same label can also appear near different kinds of actions. For example, a balance, stake, subnet, authorization, or rate-limit label identifies the rejected condition, not the whole user intent that produced it (Subtensor Standard Errors, Subtensor Custom Errors).
That is why error codes are most useful as anchors for reading other chain references. They narrow the failure domain, but storage state, emitted events, rate-limit rules, and the submitted action still provide the context that turns a label into a full explanation.
Rate-Limit Context
Rate-limit failures are easy to misread because they involve timing. Bittensor rate-limit documentation explains that selected chain actions use block-based cooldowns (Rate Limits).
That timing model is narrower than a generic wait-and-try-again rule. Some errors point to rate limits, while other errors point to missing state, invalid parameters, balance conditions, authority conditions, or Subtensor checks.
Chain Signal Context
Error codes sit beside other chain-observation surfaces. Storage entries describe recorded state, events describe emitted runtime records, and errors describe rejection categories when an intended state change does not complete (Subtensor Storage, Subtensor Events, Subtensor Error Codes).
Those signals are strongest when read in their own lanes. Storage is not an error, an event is not a full diagnosis, and an error code is not a complete description of the underlying Bittensor mechanism.
The official overview notes that errors can surface through client, SDK, or extrinsic interfaces (Subtensor Error Codes). The conceptual meaning is therefore the chain signal, not the particular interface that displayed it.
The generated API path is also an interface label, not the whole failure story. It gives a stable way to name the runtime error variant, while storage reads, emitted events, and the submitted action describe the surrounding chain context (Subtensor API Errors, Subtensor Storage, Subtensor Events).
The submitted action is often an extrinsic, which is the transaction or call surface used to ask Subtensor to process a runtime action. Reading the error label beside the extrinsic keeps the failure vocabulary attached to what the chain was asked to do (Subtensor extrinsics, Subtensor Error Codes).
This keeps the concept portable. A reader comparing an error seen through a wallet, an application, or a chain transaction interface can still start from the same Subtensor error family, then add the interface-specific context only after the chain-layer signal is understood.
Reader Boundary
Subtensor error codes do not name a complete recovery guide, a full incident report, or a guarantee that the same label has the same practical meaning in every context (Subtensor Error Codes, Bittensor Networks).
Subtensor error codes identify rejection vocabulary, while rate limits, storage, events, subnet settings, and mechanism references describe neighboring parts of the system.
Custom and Standard Errors Need Surrounding Context
Custom errors may expose a number first, but the custom-error table supplies the Bittensor-specific description that gives that number meaning (Subtensor Custom Errors).
Standard errors name recognizable Subtensor conditions, but the short name still needs the action and network around it.
Network Boundary
A localnet or testnet failure can illustrate an error family, but it should not be treated as proof about another network environment (Bittensor Networks).