Weights Rate Limit
Weights rate limit is a per-subnet hyperparameter, listed in the documentation as WeightsRateLimit
and also referred to as CommitmentRateLimit, that sets how long, in blocks, a validator must wait
between weight setting commits
on a subnet
(Subnet Hyperparameters).
What It Controls
The hyperparameter paces how often a single validator can resubmit validator weights. It does not define what those weights mean, how Yuma Consensus aggregates them, or which miners a validator should score. It only sets the minimum block interval between one weight commit and the next from the same validator on the selected subnet.
That makes weights rate limit a submission-pacing rule. It limits how frequently a validator can change its on-chain weight signal, rather than deciding whether a particular submission counts in the current epoch.
Because the wait is counted in blocks while a subnet’s consensus cycle length is its tempo, the relationship between the two decides whether a validator can refresh its weights every epoch. When the minimum wait is shorter than the tempo, a validator can commit new weights within each cycle; when the wait is longer than the tempo, some epochs pass without a fresh commit and Yuma Consensus reads the validator’s most recent stored weights for those epochs rather than newer ones (Subnet Hyperparameters, Glossary: Tempo, Yuma Consensus).
How the Limit Is Checked
On chain, a weight submission passes the pacing check when the blocks elapsed since the validator’s last weight update are at least the rate limit. Reaching the limit exactly is enough, since the comparison is inclusive, and a submission that arrives sooner is rejected as setting weights too fast (Rate Limits, Glossary: Weight Setting).
A validator’s first weight submission is exempt. While the stored last-update value is still its default of zero, the check passes regardless of the rate limit, so the interval only applies between an existing commit and the next one (Rate Limits, Subnet Metagraph).
Documented Type, Default, and Setter
The Subnet Hyperparameters
reference lists WeightsRateLimit / CommitmentRateLimit as a u64 with a default of 100 and
the description “How long, in blocks, a validator must wait between weight commits on a subnet.” It
is changed through the sudo_set_weights_set_rate_limit extrinsic, exposed in tooling as
btcli sudo set --param weights_rate_limit, and the reference marks the permission required to set
it as root rather than subnet owner
(Subnet Hyperparameters).
Because each subnet carries its own hyperparameters, the commit pacing on netuid 1 can differ from another subnet’s limit (Subnet Hyperparameters).
Distinction from Activity Cutoff
Weights rate limit sets how many blocks a validator must wait between weight commits on a subnet. Activity cutoff vocabulary names how long a validator may remain without an on-chain update before its stake is masked inactive for consensus—not an early-epoch submission deadline (Subnet Hyperparameters: Weights Rate Limit, Subnet Hyperparameters: Activity Cutoff, Subnet Hyperparameters: Activity Cutoff Factor, Yuma Consensus).
On dynamic-tempo subnets the fixed block hyperparameter is deprecated; the live inactivity span comes from activity cutoff factor and tempo instead (Subnet Hyperparameters).
Pacing vocabulary and inactivity-mask vocabulary answer different submission questions on the same weight path. A validator can satisfy the block wait between commits yet still be masked inactive when last update exceeds the effective span, and a fresh last update does not shorten the minimum wait before the next commit (Subnet Metagraph, Implementation of the Yuma Consensus Epoch: Network State Collection).
- Weights rate limit — minimum block wait between weight commits from the same validator.
- Activity cutoff — inactivity span before a stale validator is masked out of consensus.
Distinction from Commit Reveal
Commit Reveal changes when committed weights become visible, while weights rate limit changes how frequently a validator can submit new commits. Reveal delays when weights become visible; the rate limit slows how often they can change, so together they reduce the value of reacting to freshly observed signals rather than evaluating independently (Commit Reveal, Subnet Hyperparameters).
- Commit reveal — hides committed weights until a later reveal.
- Weights rate limit — blocks a validator must wait between weight commits.
Distinction from Serving Rate Limit
ServingRateLimit
rate-limits miner calls to serve_axon and serve_prometheus. That setting paces miner endpoint
registration, not validator weight commits
(Subnet Hyperparameters).
- Serving rate limit — how often a miner may update axon/prometheus serving metadata.
- Weights rate limit — how long a validator must wait between weight commits.
Distinction from Tempo
Weights rate limit sets how many blocks a validator must wait between weight commits, while tempo is the block interval over which rewards accumulate before Yuma Consensus distributes them at the boundary (Subnet Hyperparameters, Yuma Consensus).
- Weights rate limit — the blocks a validator must wait between commits.
- Tempo — the block interval that bounds reward accumulation and distribution.
Distinction from Min Allowed Weights
Min allowed weights sets the minimum number of weights a validator must include in a submission, while weights rate limit sets how many blocks a validator must wait between weight commits (Subnet Hyperparameters).
- Min allowed weights — the fewest weights a submission must include.
- Weights rate limit — the blocks a validator must wait before the next commit.
Distinction from Weights Version Key
The weights version key sets the minimum version a set_weights call must carry to be accepted,
while weights rate limit sets how many blocks a validator must wait between weight commits
(Subnet Hyperparameters).
- Weights version key — the minimum version a weight submission must carry.
- Weights rate limit — the blocks a validator must wait before the next commit.
Chain Reads for netuid 1
Readers can verify live hyperparameter values for the documented example netuid with
btcli subnet hyperparameters --netuid 1 --network finney
(Subnet Hyperparameters: View hyperparameters).
That read path keeps live hyperparameter claims tied to a parseable netuid.
Per-Subnet Live Value Boundary
Weights rate limit is per-subnet chain state. The block gap configured on one netuid paces how long a validator must wait between weight commits on that subnet, but the live limit can differ from reference defaults and from limits on other netuids (Subnet Hyperparameters, Glossary: Weight Vector).
This article’s infobox uses netuid 1 as an example label when reading one subnet’s hyperparameter table on Finney mainnet. That example helps readers verify one row; it is not proof that every subnet exposes the same live commit pacing (Bittensor Networks).
Weights rate limit paces validator weight submissions; Yuma Consensus still aggregates eligible weights into emission shares at epoch boundaries on the active subnet (Yuma Consensus).
- Weights rate limit — block gap between validator weight commits on a subnet.
- Per-subnet boundary — live limit is chain state on one netuid.
Distinction from Yuma Consensus
Weights rate limit is the per-subnet hyperparameter that sets the minimum block wait between validator weight commits. It names submission cadence, not the mechanism that credits emission shares at the epoch boundary (Subnet Hyperparameters, Glossary: Weights Rate Limit).
Yuma Consensus is the on-chain mechanism that reads the eligible weight matrix, applies clipping and bonding, and then credits miner incentives and validator dividends on the selected netuid (Yuma Consensus, Glossary: Weight Matrix, Emission: Distribution).
The weight-setting section above covers what validators record on chain. Weights-rate-limit vocabulary names how often those updates may arrive; Yuma vocabulary names settlement once eligible weights are assembled (Glossary: Weight Setting).
Readers should not read the rate limit as a payout quote or scoring rule. It paces submissions upstream of the matrix Yuma processes on the relevant netuid (Emission).
- Weights rate limit — minimum block wait between weight commits.
- Yuma Consensus — on-chain mechanism that uses validator weights to determine emission shares (Yuma Consensus: Validator emissions).
Reader Boundary
Weights rate limit should not be read as activity cutoff, commit reveal, or a weight-quality rule. Activity cutoff names validator inactivity tolerance measured from last update—not an early-epoch submission window—while this hyperparameter paces how often the same validator may commit weights on the selected netuid (Subnet Hyperparameters: Activity Cutoff, Subnet Hyperparameters: Weights Rate Limit, Subnet Hyperparameters).