Tx Rate Limit
Tx rate limit is a chain parameter, listed in the documentation as TxRateLimit, that sets the
network’s general transaction rate limit. The dedicated rate-limits reference describes it as the
default transaction rate limit, expressed in blocks, with the chain state variable named
TxRateLimit (Rate Limits).
What It Controls
The parameter is a cooldown measured in blocks between rate-limited transactions from an account. Although it is the network’s general transaction rate limit, the documentation notes it currently applies only to hotkey swaps, while other rate-limited transactions are handled by their own custom limits (Rate Limits).
The rate-limits reference lists the current general transaction rate limit as 1 block, about 12 seconds at the documented block cadence. That makes it the short account-level gate in the hotkey swap path, not the multi-day per-subnet cooldown (Rate Limits, Bittensor Networks).
When a transaction would breach the limit, the chain rejects it with the TxRateLimitExceeded
error. That error is the signal that the cooldown window for the general transaction rate limit has
not yet elapsed (Rate Limits,
Subtensor Standard Errors).
Because the value is counted in blocks, the real-time cooldown depends on block time. The one-block spacing it enforces is short relative to longer per-subnet windows (Rate Limits).
Hotkey Swaps Carry a Second Limit
For hotkey swaps specifically, the general transaction rate limit is not the only gate. The documentation describes hotkey swaps as subject to two separate rate limits that must both be satisfied: the general transaction rate limit and a much longer per-subnet interval. The tx rate limit is the short, network-wide half of that pair (Rate Limits).
Per-Subnet Half for netuid 1
While the general transaction rate limit is network-wide, the second hotkey-swap limit is per subnet, so it is observed against a specific netuid. For the documented example netuid 1 on Finney mainnet, a hotkey swap must satisfy both the network-wide tx rate limit and netuid 1’s own per-subnet swap interval before it is accepted on that subnet (Rate Limits). The infobox uses netuid 1 only as an example label for that per-subnet half; the tx rate limit itself applies across the chain rather than belonging to one subnet (Bittensor Networks).
Reading and Setting the Value
TxRateLimit is root-governed chain state rather than a per-subnet owner setting, changed through
the sudo_set_tx_rate_limit extrinsic. Because it is live chain state, the current value is read
from the chain rather than assumed; the Bittensor SDK exposes a chain query that returns the active
transaction rate limit (Rate Limits,
SubtensorAPI).
The constants reference exposes the startup default as
api.consts.subtensorModule.initialTxRateLimit, listed as 1000. That value is the genesis
constant, while the live TxRateLimit storage value can be changed at root permission after launch
and is what the chain query returns
(Subtensor Constants: initialTxRateLimit).
Distinction from Serving Rate Limit
Serving rate limit is a per-subnet limit on how often a miner can update its serving metadata. Tx rate limit is the network-wide general transaction rate limit that currently governs hotkey swaps, so one is per-subnet and the other applies across the chain (Rate Limits, Subnet Hyperparameters).
- Tx rate limit — network-wide general transaction cooldown.
- Serving rate limit — per-subnet limit on miner serving-metadata updates.
Distinction from Network Rate Limit
Network rate limit paces how often new subnets can be registered. Tx rate limit paces general transactions from an account, so one governs subnet creation cadence and the other account-level transaction spacing (Rate Limits, Subnet Hyperparameters).
- Tx rate limit — cooldown between rate-limited account transactions.
- Network rate limit — wait between new subnet registrations.