Weights Version Key
Weights version key is a per-subnet hyperparameter that sets a minimum version a validator’s weight
submission must carry. Official documentation states that if the version key specified in a
set_weights call is lower than this system-wide setting, the transaction fails.
References: Subnet Hyperparameters
What It Controls
The hyperparameter gates weight submissions by version. When a validator submits weights, the call carries a version key, and that key must be at least the subnet’s weights version key for the transaction to succeed. It does not change the weights a validator chooses; it only decides whether a submission is accepted based on the version it declares.
Reference: Subnet Hyperparameters
Why Subnets Use It
Because a submission with a too-low version key fails, raising this setting effectively requires validators to move to a matching version before their weights are accepted again. That gives a subnet a way to roll forward expectations for validators in step, since stale submissions are rejected rather than silently accepted.
Reference: Subnet Hyperparameters
Default and Setting
The documentation lists a default of 0 and marks the parameter as owner-settable, so a subnet owner can raise it for their subnet. A default of 0 means no minimum is enforced. The value in force is per-subnet chain state and can differ from the default.
Reference: Subnet Hyperparameters
Subnet Context
Weights version key is one of the subnet hyperparameters, the on-chain state variables that configure a single subnet, for example netuid 1. Because each subnet carries its own hyperparameters, the required version is defined per subnet and applies only to weight submissions on that subnet.
Reference: Subnet Hyperparameters
Development Stage Context
The
Introduction to Bittensor
describes subnet development as moving from localnet to testnet and then mainnet. For the weights
version key, that sequence changes which subnet hyperparameter state a reader should assume when
judging whether a set_weights submission meets the minimum version.
In localnet, version-key checks can be tested through isolated subnet configuration. Localnet hyperparameter values do not represent production weight-submission rules on live subnets.
On testnet, the weights version key can be exercised on a shared non-production network. Testnet hyperparameter state is separate from mainnet subnet data (Subnet Hyperparameters).
On mainnet, the weights version key concerns live per-subnet settings on the selected netuid that gate accepted weight submissions.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A weights-version example from one environment should not be read as describing production hyperparameter state on another network.
Relationship to Yuma Consensus
Weights Version Key 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, weights version key 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
This page defines the concept at a high level. It does not report the weights version key set on any particular subnet or whether a given validator’s submission currently meets it. Those are live chain state and should be checked for the relevant netuid. The default of 0 is the documented value, and the parameter is owner-settable per subnet.
Reference: Subnet Hyperparameters
The Version Rides on the set_weights Extrinsic
Bittensor documents weight submission as a dispatchable extrinsic call that carries both the weight vector and a declared version key. The weights version key hyperparameter compares that declared value against the subnet minimum before the runtime accepts the submission (Subnet Hyperparameters).
That keeps version enforcement at the submission boundary. Validators still choose their own targets and scores, but the extrinsic must declare a version at or above the subnet floor for the call to succeed.
References: Subnet Hyperparameters, Subtensor extrinsics
Activity Cutoff Times Submissions Inside the Epoch
Subnet hyperparameters include an activity cutoff measured in blocks within each epoch. Official documentation states that a validator who does not submit validator weights within the first activity-cutoff blocks of the epoch cannot participate in the current epoch.
The weights version key and that timing rule therefore answer different questions. Version key vocabulary decides whether a submitted weight call is fresh enough in client version, while activity cutoff vocabulary decides whether the validator acted early enough inside the tempo-sized epoch on a subnet such as netuid 1.
References: Subnet Hyperparameters, Glossary: Epoch
Raising the Key Coordinates Validator Upgrades
Because a too-low version key causes the weight submission to fail, raising the subnet’s weights version key is a coordination lever for subnet owners. Official hyperparameter documentation marks the setting as owner-settable, so a subnet such as netuid 1 can require validators to move to a matching client version before their next accepted weight call.
That is a rollout tool rather than a scoring rule. It does not change how Yuma Consensus aggregates accepted weights, but it can reject stale submissions until validators update the version they declare.
References: Subnet Hyperparameters, Yuma Consensus