Subtensor Constants
Subtensor constants are named runtime values exposed by Bittensor’s Subtensor runtime. They are grouped by runtime area and help readers identify values such as defaults, bounds, limits, timing parameters, and feature-status flags (Subtensor Constants).
The term is about named values built into the runtime. It should be read separately from storage entries, events, and submitted runtime actions.
What Constants Show
Each constant entry gives readers a runtime area, entry name, type, lookup shape, and summary for a named value (Subtensor Constants).
That structure keeps constants from being read as isolated numbers. The name identifies the value, the type describes the value shape, and the runtime area explains where the value belongs.
Constants are useful when a reader needs to know what the runtime calls a value or where that value is grouped. They do not by themselves explain every feature that uses the value.
Lookup Shape
The Subtensor constants page identifies each entry through the api.consts.<Pallet>.<constant_name>
shape (Subtensor Constants). That shape
keeps the runtime area and constant name attached in one lookup label.
This matters for readers because the same short word can be ambiguous without the pallet context. For example, a balance-related constant belongs under the balances area, while a Bittensor-specific constant can belong under the Subtensor module area.
The constants page also states that the values are read from the connected node. Chain-inspection documentation places constants on the read-only side of Bittensor tooling, so constants stay tied to the runtime and network context that exposed them (Inspecting the Chain with Polkadot.js).
Runtime Areas
Constants are grouped by runtime area. Some areas describe general chain behavior, while the Subtensor area contains Bittensor-specific values connected to subnet, rate-limit, weight, and feature-status vocabulary (Subtensor Constants).
The runtime area is part of the meaning of the entry. Similar-looking values can have different roles when they belong to different areas, so the area should stay attached when the value is discussed.
For readers, the area answers where the constant belongs before the entry name and type narrow what the value means.
Constant Examples
The constants listing includes general runtime areas and Bittensor-specific areas. Examples include
aura, balances, safeMode, subtensorModule, system, and transactionPayment
(Subtensor Constants).
Some constants are general chain reference values. The constants page lists
api.consts.balances.existentialDeposit under the balances area, which keeps the value tied to
balance-accounting context rather than to Subtensor-specific subnet behavior.
Other constants sit in the Subtensor module area. The constants page includes Subtensor-module
constants such as alphaHigh, alphaLow, and hotkeySwapOnSubnetInterval, with each entry keeping
the lookup label, type, and summary together
(Subtensor Constants).
These examples make the reading pattern concrete: first identify the runtime area, then the constant name, then the type and summary. The value is easier to interpret when those parts stay together.
Constants and Features
A constant can name a value used by a feature, but it usually does not replace the feature explanation. For example, a rate-limit-related value can help name a bound or default, while the rate-limit documentation explains the block-based cooldown model (Rate Limits).
This distinction is useful for Bittensor-specific topics. A constant may identify a default, limit, or feature flag; the related concept page explains how that value fits into protocol behavior.
When an article discusses a rate limit, the constant can help identify the runtime value, while the rate-limit page explains the reader-facing behavior (Subtensor Constants, Rate Limits).
Constants, Storage, and Events
Constants, storage entries, and events answer different questions. Constants expose runtime-defined values, storage entries expose state surfaces, and events name runtime records emitted during processing (Subtensor Storage, Subtensor Events).
A feature can involve all three surfaces without making them interchangeable. A constant can name a value used by a feature, a storage entry can locate chain state, and an event can show that runtime activity happened.
The distinction keeps readers from treating a constant as mutable state or as a record of an action. A constant can name a value, storage can show a state surface, and an event can show runtime activity (Subtensor Constants, Subtensor Storage, Subtensor Events).
Inspection and Network Context
Chain-inspection documentation includes constants among the chain data readers can inspect (Inspecting the Chain with Polkadot.js). This places constants on the read-only side of Bittensor tooling: they can be inspected without submitting a state-changing runtime action (Inspecting the Chain with Polkadot.js, Subtensor Constants).
Subtensor constants also belong to a runtime and network context. Mainnet, testnet, and localnet are separate environments, so examples should keep the environment label attached when behavior across networks matters (Bittensor Networks, Subtensor Constants).
Initial Constants Seed Defaults
The Subtensor constants listing includes many Subtensor-module entries whose names begin with
initial, such as initialTempo, initialMaxAllowedUids, and initialImmunityPeriod
(Subtensor Constants). Those names mark
compile-time startup defaults the runtime uses when a new subnet or network parameter is first set,
not a guarantee that every live subnet still matches the same number today.
A subnet’s current timing and participation limits are tracked as subnet hyperparameters scoped to that subnet’s netuid. The Glossary: Tempo entry describes tempo as a subnet setting measured in blocks, which readers usually read from hyperparameter context rather than from a one-time initial constant alone.
That split keeps constant lookup from being mistaken for live subnet state. An initial constant
can name the default baked into the runtime, while hyperparameter reading shows what that subnet
uses after creation and after any permitted updates
(Subtensor Constants,
Subnet Hyperparameters).
References: Subtensor Constants, Subnet Hyperparameters
Crowdloan Constants Bound Campaigns
Beyond subnet examples, the constants page lists a crowdloan runtime area with deposit, duration,
and refund-batch limits for collective funding campaigns
(Subtensor Constants). Those values name
rules such as the creator deposit required to open a campaign, the minimum and maximum block
duration a campaign may span, and how many contributors can be refunded in one refund pass.
Official crowdloan guidance ties those bounds to real campaign design. Campaign duration must stay within the minimum and maximum window on production-style networks, where the documented range maps to about seven days at the low end and about sixty days at the high end (Crowdloans, Create a Subnet with a Crowdloan).
Readers therefore meet crowdloan limits in two related places. Constants expose the runtime reference values, while crowdloan documentation explains how contributors fund an action such as subnet registration and how failed campaigns return deposits (Crowdloans).
References: Subtensor Constants, Crowdloans
Slot Duration Anchors Block Time
Many Bittensor limits are expressed in blocks rather than in seconds. The constants page lists
api.consts.aura.slotDuration with a twelve-thousand-millisecond summary for how long an Aura slot
should run (Subtensor Constants). That
entry sits in the general aura area rather than in the Subtensor-module bucket, because block
timing is shared chain infrastructure.
Rate-limit documentation describes cooldowns as block-based waits after a successful operation (Rate Limits). When a reader wants wall- clock intuition, the slot-duration constant provides the millisecond-per-slot anchor that sits under those block counts.
The connection is interpretive, not interchangeable. A rate-limit page explains the behavior and error pattern, while the Aura constant names the slot timing reference that helps turn a block count into an approximate time estimate (Subtensor Constants, Rate Limits).
References: Subtensor Constants, Rate Limits
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Subtensor Constants, that sequence changes how an example should be read, because the surrounding network state differs at each stage.
In localnet, subtensor Constants can be exercised in an isolated development environment, where the surrounding chain state reflects local configuration rather than production history.
On testnet, subtensor Constants can be observed in a shared, non-production network whose state is kept separate from mainnet.
On mainnet, subtensor Constants applies on the live, production Bittensor network, where the surrounding state is real and persistent.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A subtensor Constants example from one environment should not be read as representing another environment.
Relationship to Yuma Consensus
Subtensor Constants 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 constants 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 constants are useful for naming defaults, bounds, limits, timing values, and feature-status values, but they are not a complete guide to the feature that uses them (Subtensor Constants).
When a concrete question depends on behavior, the constant should be read beside the relevant concept page and any related storage or event context.
Network and Block Context
Subtensor constants belong to a runtime and network context. Mainnet, testnet, and localnet are separate environments, so examples should keep the environment label attached (Bittensor Networks).