Skip to main content
SUBMIT A PRSUBMIT AN ISSUElast edit: Sep 25, 2025

Bittensor Rate Limits

This page reviews all rate limits implemented in the Bittensor blockchain (Subtensor). Rate limits prevent spam, ensure network stability, and maintain fair access to network resources. Rate limits in Bittensor are implemented as block-based cooldown periods. When a rate-limited operation succeeds, subsequent attempts to perform the same operation must wait for a specified number of blocks to pass before they can be executed again. Unsuccessful operations may be re-tried.

info

To check/confirm confirm current rate limits and other chain state variables on the blockchain, use the Polkadot.js chain explorer.

To view the chain state for Bittensor main network ('finney'), visit https://polkadot.js.org/apps, choose Bittensor network, and click Chain State under the Developer tab, or visit:

https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fbittensor-finney.api.onfinality.io%2Fpublic-ws#/chainstate.

Most relevant attributes are under the subtensorModule.

Global rate limits​

This section discusses rate limits that apply globally across the entire network.

General transaction rate limit​

This is the default transaction rate limit in Bittensor, but it currently only applies to hotkey swaps (other rate limited transsactions are handled by custom rate limits).

Delegate take rate limit​

This rate limit prevents frequent changes to delegate take percentages.

Child key take rate limit​

This rate limit prevents the owner of a child hotkey from making frequent changes to the child key take percentages. This protects against rapid manipulation of child key relationships and ensures stability in the child key delegation system.

Hotkey set rate limit​

This rate limit prevents a user from swapping a hotkey too frequently.

UID trimming rate limit​

This rate limit controls how frequently subnet owners can trim UIDs on their subnets. This prevents disruptions in subnet stability and excessive network reorganization.

  • Rate Limit: 216,000 blocks (~30 days) on main net; 1 block in 'fastblocks' development mode.
  • Configuration: MaxUidsTrimmingRateLimit macros/errors.rs
  • Error message: TxRateLimitExceeded

Network registration rate rimit​

This rate limit prevents frequent creation of new subnets.

Subnet-specific rate limits​

This section discusses rate limits that apply within a specific subnet on the network. These limits are typically configurable at the subnet level.

Serving rate limits​

This rate limit controls how frequently neurons can update their serving information (axon and prometheus data) on the Bittensor network. This rate limit can be modified by changing the serving_rate_limit parameter in the subnet hyperparameters. For more information, see subnet hyperparameters.

Subnet owner hyperparameter update rate limit​

This rate limit controls how frequently a subnet owner can change subnet hyperparameters (e.g., kappa, rho, serving_rate_limit, etc.). The limit is enforced independently per hyperparameter, so updating one parameter does not block updating a different one during the same window.

  • Rate Limit: Tempo(netuid) × OwnerHyperparamRateLimit (default: 2 tempos; with default tempo 360, that is 720 blocks)
  • Configuration:
    • Global multiplier: OwnerHyperparamRateLimit (root) via sudo_set_owner_hparam_rate_limit
    • Tempo per subnet: Tempo (root) via sudo_set_tempo
  • Implementation: rate_limiting.rs
  • Error message: TxRateLimitExceeded

Note: All subnet owner operations are disallowed during the final blocks of each tempo as governed by AdminFreezeWindow. This restriction is in addition to the above rate limit.

Mechanism configuration rate limits​

These limits govern how often a subnet owner can change the number of incentive mechanisms and the emission split among them. For background on mechanisms, see Multiple Incentive Mechanisms Within Subnets.

Mechanism count update rate limit​

Mechanism emission split update rate limit​

Staking operations rate limits​

This rate limit controls how frequently a user can perform staking operations (add/remove stake, move stake) to a particular subnet (netuid).

Weights rate limits​

This section covers rate limits related to setting weights on a subnet. This rate limit can be modified by changing the weights_rate_limit parameter in the subnet hyperparameters. For more information, see subnet hyperparameters.

Weights setting rate limit​

This rate limit controls how frequently a subnet validator can set weights to the network.

Commit-reveal weights rate limit​

This rate limit controls how frequently a subnet validator can set commit on to the Bittensor chain. Changing the weights_rate_limit parameter in the subnet's hyperparameters also modifies this rate limit. For more information, see subnet hyperparameters.

Registration rate limits​

This section covers rate limits related to neuron registrations on a subnet.

Per-block registration limit​

This rate limit controls how frequently registrations can occur on a particular subnet. This rate limit can be modified by changing the max_regs_per_block parameter in the subnet hyperparameters. For more information, see subnet hyperparameters.

Per-interval registration limit​

This rate limit controls the frequency of neuron registrations within an interval. This limit occurs when registration attempts in the current interval exceed three times the target registrations per interval.

Subtensor Node Rate Limits​

When querying OTF-provided lite nodes, then the following rate limits apply. We strongly encourage you to run your own local lite node.

  • Any OTF-provided lite node will rate limit the requests to one request per second, per IP address. Note that this rate limit may change dynamically based on the network or application requirements.
  • A request can be either WS/WSS or HTTP/HTTPS.
  • If you exceed the rate limit, you will receive the error code 429. You will then have to wait until the rate limit window has expired.
  • You can avoid OTF-lite node rate limits by running your own local lite node. You can run a lite node either Using Docker or Using Source.