Serving Rate Limit
Serving rate limit is a per-subnet hyperparameter, listed in the documentation as
ServingRateLimit, that rate-limits how often a miner can call the serve_axon and
serve_prometheus extrinsics to register or update its network endpoint information on a subnet
(Subnet Hyperparameters).
What It Controls
The hyperparameter paces miner-side endpoint registration, not validator weight submission. It does not define what work a subnet miner produces or how validators score that work. It only limits how frequently a miner can publish or refresh its on-chain serving metadata through the documented serving extrinsics.
Miners commonly expose an axon server so validators can reach them over the subnet communication path. Serving rate limit governs how often the on-chain endpoint record for that axon may be rewritten, not whether the miner is registered or whether the live server is reachable at query time (Understanding Neurons).
The limit is counted in blocks rather than clock time, so its practical pacing depends on how quickly the chain produces blocks in the relevant network context. The same serving rate limit can describe a different real-world interval on localnet, testnet, and mainnet (Subnet Hyperparameters, Bittensor Networks).
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 miner can refresh its serving metadata every epoch. When the minimum wait is shorter than the tempo, a miner can call the serving extrinsics within each cycle; when the wait is longer than the tempo, some epochs pass without a fresh serving update and validators rely on the most recently stored endpoint record for those epochs rather than newer on-chain writes (Subnet Hyperparameters, Glossary: Tempo, Understanding Neurons).
The cap also applies to on-chain endpoint writes, not to live query volume. It bounds how often the serving metadata record can be rewritten through the documented serving extrinsics, while the rate of validator queries to a running axon is a separate networking concern (Understanding Neurons).
A consequence is that a miner cannot republish endpoint changes faster than this cap allows. If a miner moves its axon to a new address or port and has already updated within the limit, the new endpoint record cannot be written until the required gap elapses, so validators reading the on-chain record may keep reaching the previously recorded endpoint until the next permitted update. The cap therefore bounds how quickly the recorded endpoint can catch up to a miner’s actual axon, separate from whether the live server is reachable (Subnet Hyperparameters, Glossary: Axon, Understanding Neurons).
Documented Type, Default, and Setter
The Subnet Hyperparameters
reference lists ServingRateLimit as a u64 with a default of 50 and the description “Rate limit
for calling serve_axon and serve_prometheus extrinsics used by miners.” It is changed through
the sudo_set_serving_rate_limit extrinsic, exposed in tooling as
btcli sudo set --param serving_rate_limit, and the reference marks the permission required to set
it as subnet owner
(Subnet Hyperparameters).
The constants reference exposes the startup default as
api.consts.subtensorModule.initialServingRateLimit, also listed as 50. That constant names the
initial per-subnet block gap for serving updates, while each subnet’s live ServingRateLimit
hyperparameter can later be changed by its owner
(Subtensor Constants: initialServingRateLimit,
Subnet Hyperparameters).
Because each subnet carries its own hyperparameters, the pacing rule on netuid 1 can differ from another subnet’s serving cadence (Subnet Hyperparameters).
Distinction from Weights Rate Limit
The hyperparameters reference also lists WeightsRateLimit, which sets how long, in blocks, a validator must wait between weight commits. That setting paces validator weight setting, not miner endpoint registration (Subnet Hyperparameters).
- Serving rate limit — how often a miner can update axon/prometheus serving metadata.
- Weights rate limit — how long a validator must wait between weight commits.
Distinction from Tempo
Both serving rate limit and tempo are counted in blocks, but they govern different things. Tempo is the length of a subnet’s consensus cycle, while serving rate limit only paces how often a miner may refresh its serving metadata (Subnet Hyperparameters, Yuma Consensus).
- Serving rate limit — the minimum block gap between a miner’s endpoint updates.
- Tempo — the block length of the subnet’s consensus cycle.
Distinction from Activity Cutoff
Serving rate limit paces how often a miner may update its axon and prometheus serving metadata, while activity cutoff vocabulary names how long a validator may remain without an on-chain update before its stake is masked inactive for consensus—not how often a miner may refresh endpoint metadata (Subnet Hyperparameters, 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).
- Serving rate limit — the minimum block gap between a miner’s endpoint updates.
- Activity cutoff — inactivity span before a stale validator is masked out of consensus.
Distinction from Immunity Period
Serving rate limit paces how often a miner may refresh its serving metadata, while immunity period is the window after registration during which a newly registered neuron is shielded from deregistration (Subnet Hyperparameters, Glossary: Immunity Period).
- Serving rate limit — how often a miner may update its serving metadata.
- Immunity period — the post-registration window shielding a new neuron from deregistration.
Distinction from Axon
An axon is the miner-side communication endpoint validators use to reach a subnet miner. Serving rate limit paces how often the on-chain axon and prometheus serving records may be updated, not whether the miner runs a reachable axon server (Glossary: Axon, Subnet Hyperparameters).
- Axon — the miner communication endpoint validators query.
- Serving rate limit — how often serving metadata may be rewritten on chain.
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
Serving rate limit is per-subnet chain state. The block gap between miner axon and prometheus updates on one netuid applies only within that subnet’s serving path and can differ from the reference default of fifty blocks (Subnet Hyperparameters, Glossary: Axon).
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 pacing value (Bittensor Networks).
Serving rate limit schedules miner serving-metadata writes; Yuma Consensus still aggregates validator weights into emission shares each epoch on the active subnet (Yuma Consensus).
- Serving rate limit — block gap between miner endpoint metadata updates on a subnet.
- Per-subnet boundary — live pacing is chain state on one netuid.
Distinction from Yuma Consensus
Serving rate limit is a per-subnet hyperparameter that paces how often miners can register or update axon and prometheus endpoint information. Yuma Consensus is the separate tempo process that converts validator weight submissions into emission shares each epoch (Glossary: Serving Rate Limit, Subnet Hyperparameters, Yuma Consensus, Emission).
-
Serving rate limit — pacing for miner endpoint registration updates.
-
Yuma Consensus — on-chain settlement that turns validator weights into emission shares. Serving rate limit names endpoint update pacing; Yuma processes validator weights into rewards (Yuma Consensus: Validator emissions).
-
Endpoint vs settlement — serving rate limit paces miner metadata writes; Yuma settles validator weights into emission shares (Yuma Consensus: Validator emissions).
-
Not reachability — a tighter serving rate limit does not prove axon reachability or weight quality (Glossary: Axon).
Reader Boundary
Serving rate limit should not be read as a validator weight rule, a reachability test, or proof that
a miner’s axon is online. It names only the subnet hyperparameter that paces serve_axon and
serve_prometheus updates on the selected netuid
(Subnet Hyperparameters).