Subnet Hyperparameters

Subnet Hyperparameters
Scope	Subnet behavior
Examples	Tempo, weights, limits
Affects	Signal processing
Related	Incentive mechanisms

Subnet hyperparameters are protocol state variables that shape how a Bittensor subnet behaves. They cover timing, validator-weight flow, consensus behavior, emission handling, and lifecycle limits for a selected subnet (Subnet Hyperparameters).

They are not the same as the subnet task. An incentive mechanism explains what work miners produce and how validators evaluate that work; hyperparameters set the protocol envelope around that incentive system (Understanding Incentive Mechanisms, Subnet Hyperparameters).

That envelope matters for interpretation. A hyperparameter can change when signals are accepted, how often epochs are evaluated, or how a subnet’s protocol limits are read without changing the underlying work target.

Parameter Layer

Hyperparameters belong to the settings layer of a subnet. They can affect cadence, weight submission timing, consensus processing, and emission handling, but they do not by themselves define the useful digital work of the subnet (Subnet Hyperparameters, Understanding Incentive Mechanisms).

That distinction helps readers separate protocol envelope from mechanism design. A hyperparameter can change when or how signals are processed without changing the subnet’s task, scoring model, or domain-specific evaluation goal.

The safe reading is therefore contextual. Hyperparameters explain conditions around a subnet’s operation; the mechanism explains what the subnet is trying to measure.

Timing and Weight Flow

Tempo is the clearest timing example because it gives a block-based cadence for subnet epochs. The hyperparameter reference places tempo alongside other subnet settings that shape validator signal flow and epoch behavior (Subnet Hyperparameters, Yuma Consensus).

Weight-related settings answer a different timing question: how validator signals are paced or revealed. Commit Reveal, for example, is a weight-submission mechanism whose timing is interpreted through subnet settings and tempo-based delays (Commit Reveal, Subnet Hyperparameters).

Timing vocabulary should stay attached to the selected setting. A tempo claim concerns epoch cadence, while a commit-reveal claim concerns the handling of validator weight submission and reveal timing.

Lifecycle and Limits

The hyperparameter reference also includes settings that shape lifecycle or limit behavior around a subnet. Those values belong to the same protocol-envelope category as timing and weight-flow settings because they describe constraints around a selected subnet (Subnet Hyperparameters, Bittensor Networks).

That does not make every lifecycle statement a hyperparameter statement. A reader should keep the specific setting, subnet, and network context attached when a claim depends on a value or limit.

Development Stage Context

The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For subnet hyperparameters on a subnet such as netuid 1, that sequence changes how readers should interpret configuration values and activity-window settings.

In localnet, subnet hyperparameters can be tested in an isolated environment. Local parameter values reflect local chain configuration rather than production subnet rules.

On testnet, subnet hyperparameters can be observed in a shared, non-production network. Testnet parameter tables on a selected netuid are separate from mainnet subnet state (Subnet Hyperparameters).

On mainnet, subnet hyperparameters are the live configuration fields that govern subnet behavior on the production Bittensor network.

The Bittensor Networks reference separates mainnet, testnet, and localnet. A hyperparameter example from one environment should not be read as representing production subnet configuration on another network.

Activity Cutoff and Activity Cutoff Factor

Subnet hyperparameters include activity cutoff vocabulary for validator inactivity tolerance and the live activity cutoff factor setting under dynamic tempos. When too many blocks have passed since a validator’s last update relative to the effective inactivity span, that validator is treated as inactive for the epoch pass and its stake is masked out before stake-weighted consensus runs (Implementation of the Yuma Consensus Epoch: Network State Collection, Subnet Hyperparameters: Activity Cutoff).

The legacy fixed-block activity cutoff hyperparameter is deprecated on dynamic-tempo subnets. Live inactivity tolerance is derived from activity cutoff factor and tempo instead, so readers comparing staleness to the allowed span need those subnet settings rather than a single fixed block count alone (Subnet Hyperparameters, Yuma Consensus).

That setting shapes validator participation in consensus, not an early-epoch submission deadline. It is one example of how hyperparameters constrain which stake still counts without defining what miners produce (Subnet Hyperparameters).

Min and Max Burn Bound Neuron Registration Cost

The hyperparameter reference lists MinBurn and MaxBurn as the lower and upper bounds on the dynamic TAO burn required to register a neuron. The live registration price moves inside that band rather than staying fixed at either bound (Register, Subnet Hyperparameters).

Burn hyperparameters therefore belong to the registration envelope. They limit how low or high entry cost can fall without replacing the registration process itself.

Tempo Counts Blocks in Each Epoch

The tempo hyperparameter sets the block-based cadence for subnet epochs. The Glossary: Tempo defines tempo as the interval over which Yuma Consensus calculates emissions from the latest ranking weight matrix.

Tempo is a timing hyperparameter, not a scoring rule. It tells readers how many blocks group epoch processing on a subnet such as netuid 1; the incentive mechanism still defines the subnet task inside that cadence.

Kappa Sets the Stake Threshold for Clipping

The kappa hyperparameter sets how much of a subnet’s validator stake must support a weight level before that level becomes the clipping ceiling for a miner during Yuma Consensus. With the default kappa of 0.5, at least half of stake-weighted validator support must agree that a miner deserves weight above a given level before more generous weights are left unclipped (Yuma Consensus: Clipping, Subnet Hyperparameters).

Readers should not treat kappa as a miner-quality score. It governs how aggressively outlier weights are trimmed relative to stake-backed consensus, not how useful a miner’s subnet work was in isolation (Glossary: Consensus Score).

Bonds Penalty and Reset Shape Bond History

The hyperparameter reference lists BondsPenalty as the magnitude subtracted from weights for exceeding consensus, and BondsResetEnabled as the setting that determines whether bonds are periodically reset (Subnet Hyperparameters, Glossary: Validator-Miner Bonds).

Both settings shape how the bonds mechanism behaves on a subnet without replacing bonds vocabulary itself: bonds penalty adjusts an existing weight calculation, and bonds reset controls whether accumulated bond history is periodically cleared.

Commit Reveal Period Counts Tempos Before Reveal

The hyperparameter reference lists CommitRevealPeriod as the number of tempos that must elapse before validator weights submitted under Commit Reveal become readable (Subnet Hyperparameters, Commit Reveal).

This is a tempo-counted delay. Activity cutoff factor, by contrast, derives an effective inactivity span in blocks from tempo under dynamic tempos rather than counting concealed tempos before reveal (Subnet Hyperparameters: Activity Cutoff Factor).

Weights Rate Limit Spaces Out Weight Commits

The hyperparameter reference lists WeightsRateLimit as the number of blocks a validator must wait between weight commits (Subnet Hyperparameters).

That setting bounds how often a single validator can resubmit weights, separate from activity cutoff vocabulary, which names validator inactivity tolerance measured from last update rather than submission pacing (Subnet Hyperparameters: Activity Cutoff, Yuma Consensus).

Serving Rate Limit Paces Miner Endpoint Registration

The hyperparameter reference lists ServingRateLimit as the rate limit on how often a miner can register or update its network endpoint information on the subnet (Subnet Hyperparameters).

This setting paces endpoint-registration activity specifically. It is separate from weight-submission pacing, which weights rate limit governs, and from activity cutoff vocabulary, which names validator inactivity tolerance before stake is masked for consensus (Subnet Hyperparameters: Weights Rate Limit, Subnet Hyperparameters: Activity Cutoff).

Max Allowed UIDs Caps Total Registered Neurons

The hyperparameter reference lists MaxAllowedUids as the maximum number of neurons a subnet can hold, distinct from MaxAllowedValidators, which caps how many of those neurons may act as validators at once (Subnet Hyperparameters).

That split separates the overall registration ceiling from the validator-specific ceiling already covered by max validators. A subnet’s total neuron slots and its validator slots are two different configured limits.

Subnet Is Active Marks Whether Emissions Have Started

The hyperparameter reference lists SubnetIsActive as a flag indicating whether a subnet’s emissions have started (Subnet Hyperparameters).

This flag is a lifecycle marker rather than a performance or ranking value. A subnet can exist and hold registered neurons before this flag reflects that emissions are flowing.

Subnet Emission Enabled Halts Pool-Side Injection

The hyperparameter reference lists SubnetEmissionEnabled as the root-only boolean that controls whether a subnet receives pool-side emission injection each epoch. When false, the subnet receives no alpha-in, tao-in, or chain-buy injections, and its emission share is redistributed to enabled subnets, while alpha-out, owner cut, root proportion, and validator and server emissions continue (Subnet Hyperparameters, Emission).

That toggle is distinct from SubnetIsActive. A subnet can be active while injection is disabled, so the active flag marks emission startup while subnet emission enabled governs whether the pool-side injection stage runs on an already-live netuid (Subnet Hyperparameters).

Toggle Transfer Controls Stake Movement Between Coldkeys

The hyperparameter reference lists ToggleTransfer as the setting that allows or disallows transferring stake between coldkeys on a subnet (Subnet Hyperparameters).

That setting governs a transfer pathway specifically. It does not change staking, unstaking, or delegation behavior, which are separate actions from moving already-staked balances between coldkeys.

Owner Hyperparameter Changes Are Rate-Limited

Owner-settable hyperparameters cannot be changed on every block. The rate-limit reference documents an owner hyperparameter rate limit of 2 tempos, stored on chain as OwnerHyperparamRateLimit, that paces how frequently a subnet owner can modify a hyperparameter. The limit is enforced independently per hyperparameter, so updating one parameter does not block updating a different parameter during the same window (Chain Rate Limits: Owner hyperparameter rate limit).

A separate administrative freeze window also applies at each epoch boundary. The reference documents a 10-block freeze (AdminFreezeWindow) at the end of each epoch during which subnet owner operations are disallowed, so a hyperparameter change attempted inside that window waits until the freeze clears (Chain Rate Limits: Administrative freeze window).

Readers should therefore treat hyperparameter values as adjustable but paced. A change on netuid 1 is subject to the per-parameter 2-tempo cooldown and the end-of-epoch freeze rather than taking effect on any block the owner chooses (Subnet Hyperparameters).

YumaVersion Selects Consensus v2 or v3

The hyperparameter reference lists YumaVersion as the setting that toggles which consensus mechanism a subnet uses, switching between Yuma Consensus v2 and v3 (Subnet Hyperparameters, Yuma Consensus).

This hyperparameter selects which consensus version processes a subnet’s weights, separate from timing hyperparameters such as tempo or activity cutoff. It does not change what miners are asked to produce.

Distinction from Activity Cutoff

Subnet hyperparameters name the owner-settable protocol envelope for a subnet. Activity cutoff vocabulary names validator inactivity tolerance measured from last update before stake is masked inactive for consensus—not an early-epoch submission deadline (Subnet Hyperparameters, Subnet Hyperparameters: Activity Cutoff, Subnet Hyperparameters: Activity Cutoff Factor, Yuma Consensus).

Configuration-envelope vocabulary and inactivity-mask vocabulary answer different reader questions. Tempo, weights rate limit, and commit reveal period pace or conceal submissions; activity cutoff governs whether a validator’s stake still counts once last update exceeds the effective inactivity span (Subnet Metagraph, Implementation of the Yuma Consensus Epoch: Network State Collection).

Subnet hyperparameters — owner-settable protocol envelope for a subnet.
Activity cutoff — inactivity span before a stale validator is masked out of consensus.

Distinction from Subtensor Constants

A subnet hyperparameter and a Subtensor constant name a live per-subnet value and a runtime default. A hyperparameter is the live setting a subnet uses after creation, such as its tempo or UID cap, while initial constants name the compile-time defaults the runtime starts from (Subnet Hyperparameters, Subtensor Constants).

Subnet hyperparameter — the live per-subnet value used after creation.
Subtensor constant — a compile-time runtime default or bound.

Distinction from Incentive Mechanism

A subnet hyperparameter and the incentive mechanism name the protocol envelope and the work it surrounds. Hyperparameters set timing, weight-flow, and limit conditions, while the incentive mechanism defines the task, protocol, and scoring that decide what miners produce and how validators evaluate it (Subnet Hyperparameters, Understanding Incentive Mechanisms).

Subnet hyperparameter — the protocol envelope of timing and limits.
Incentive mechanism — the task and scoring that define the subnet’s work.

Distinction from Yuma Consensus

Subnet hyperparameters name the per-subnet protocol settings that govern timing, limits, and registration behavior. They describe the owner-settable configuration envelope, not the recurring settlement step that converts validator weight submissions into emission shares at the epoch boundary (Subnet Hyperparameters, Understanding Subnets).

Yuma Consensus is the on-chain mechanism that runs at the epoch boundary on each subnet. It reads the weight matrix from eligible validators, applies clipping and bonding, and converts the result into miner incentives and validator dividend shares (Yuma Consensus, Emission).

Earlier sections separate subnet hyperparameters from subtensor constants and incentive mechanisms. Hyperparameters shape timing and limit rules; Yuma settles the consensus outcome from eligible weight submissions using those rules—not the hyperparameter definition itself (Glossary: Weight Matrix, Weight Copying).

Readers should treat subnet hyperparameters as configuration vocabulary, and Yuma as the epoch-boundary mechanism that allocates rewards from consensus while validators remain active.

Subnet hyperparameters — owner-settable protocol envelope for a subnet.
Yuma Consensus — epoch-boundary settlement from eligible validator weights to emission shares.

Reader Boundary

A hyperparameter claim should name the behavior being described and stay separate from the subnet task, incentive mechanism, or live value source. Tempo claims concern epoch cadence; Commit Reveal claims concern weight-submission timing; activity cutoff claims concern validator inactivity tolerance from last update—not how early weights must arrive. None of those replace the work target (Subnet Hyperparameters, Understanding Incentive Mechanisms, Subnet Hyperparameters: Activity Cutoff).

Subnet hyperparameters are best used as context around timing, weights, consensus, emissions, and limits. They are not an operator manual, deployment status label, or substitute for the subnet’s incentive design.