Tempo
A tempo is a block-based timing interval used by Bittensor subnets. Rewards accumulate during a tempo and are distributed at the interval boundary through Yuma Consensus (Emission).
As a subnet hyperparameter, tempo gives subnet processes a cadence measured in blocks. It is a
timing concept rather than a definition of what useful subnet work means
(Subnet Hyperparameters).
Hyperparameter Boundary
Tempo is a subnet hyperparameter, so it should not be read as one universal value for every subnet. The stable concept is block-based cadence; exact values belong with the relevant subnet parameter source (Subnet Hyperparameters).
This also means a tempo claim needs context. A statement about cadence should say whether it is explaining the concept or referring to a specific subnet setting (Glossary: Tempo).
Documented Type, Default, and Setters
The Subnet Hyperparameters
reference lists tempo as a u16 with a default of 360 blocks, changed in tooling through
btcli sudo set --param tempo.
Those documented figures correspond to named chain startup constants. The constants reference lists
api.consts.subtensorModule.initialTempo as 360, the tempo the chain seeds a new subnet with at
launch, and exposes the owner-setter band as minTempo (360) and maxTempo (50400) — the same
360–50,400 range the set_tempo extrinsic enforces below, which spans about 72 minutes to 7 days at
12-second blocks. The live Tempo storage value is the per-subnet figure in force after launch and
can differ from this initial constant
(Subtensor Constants: initialTempo,
Subnet Hyperparameters).
Unusually, tempo can be updated through one of two distinct setter extrinsics depending on the caller’s permission, and they behave differently:
set_temporequires subnet owner permission, is bounded to[MinTempo, MaxTempo](360–50,400 blocks), and is rate-limited to one call per 360 blocks regardless of the current tempo.sudo_set_temporequires root permission, accepts anyu16, and enforces neither those bounds nor the rate limit (Subnet Hyperparameters).
The practical consequence is that a subnet owner can only move tempo within the documented band and no faster than once every 360 blocks, while a root call can set values outside that band. A reader who sees a tempo below 360 or above 50,400 on a subnet is therefore looking at a value that must have come from the root path rather than the owner setter (Subnet Hyperparameters).
The value in force is per-subnet chain state and can differ from the default, so it should be read
for the subnet in question. For the documented example netuid 1 on Finney mainnet it can be read
with btcli subnet hyperparameters --netuid 1 --network finney, keeping the cadence claim
reproducible against a parseable netuid
(Subnet Hyperparameters: View hyperparameters).
Commit Reveal Timing
Commit Reveal uses tempo-based timing for delayed weight visibility. Its reveal period is expressed in tempos, making tempo relevant to when concealed validator weights become usable (Commit Reveal).
This is a timing relationship, not a new definition of tempo. Tempo remains the block-based cadence; Commit Reveal uses that cadence as part of delayed weight submission and reveal timing (Subnet Hyperparameters).
Multiple Mechanisms Scope
When a subnet has multiple incentive mechanisms, tempo still names the shared subnet cadence. The mechanisms can have separate weight and consensus paths, but that does not require treating tempo as a separate schedule for each mechanism (Multiple Incentive Mechanisms Within Subnets).
Multiple mechanisms clarify how evaluation is organized; tempo clarifies when periodic processing occurs (Glossary: Weight Matrix).
Epoch Scheduling
Each block, coinbase checks whether a subnet should run an epoch using a predictable staggered
schedule documented for Subtensor. An epoch is due when
(block_number + netuid + 1) % (tempo + 1) == 0. The netuid offset spreads subnets across blocks so
they do not all execute Yuma in the same block
(Coinbase Implementation: Epoch execution).
The coinbase flow describes blocks_until_next_epoch counting blocks until that condition is met
and should_run_epoch returning true when the counter reaches zero, which then triggers
drain_pending_emission for that netuid
(Coinbase Implementation: Epoch execution).
Two subnets that share the same tempo value can therefore close epochs on different blocks because each netuid carries a different offset in the modulus, not because they share one network-wide boundary (Glossary: Tempo, Implementation of the Yuma Consensus Epoch).
Yuma Settlement Runs at the Tempo Boundary
Yuma Consensus is the on-chain mechanism that runs at the epoch boundary. It reads the weight matrix recorded inside that window, applies clipping and bonding, and then credits miner incentives and validator dividends on the selected netuid (Yuma Consensus, Glossary: Weight Matrix, Emission: Distribution).
Readers should not read tempo as a payout amount or as proof that settlement already occurred. Outcomes still depend on the weight matrix captured for that epoch on the relevant netuid (Emission).
Coinbase Advances Emission Every Block
Tempo and coinbase relate as a cadence and a per-block process. Tempo is the interval, measured in blocks, that sets how often a subnet runs an epoch to distribute accumulated emission and run consensus, while coinbase is the per-block routine that mints new TAO and advances emission every block regardless of tempo (Glossary: Tempo, Coinbase documentation, Emission).
Readers watching coinbase activity see per-block injection into subnet emission pools; tempo still marks when Yuma turns accumulated weights into miner and validator payouts at the epoch boundary—not every coinbase block closes an epoch (Emission: Injection and distribution, Coinbase documentation).
Tempo Names Cadence, Not Evaluation Work
Tempo names a cadence, not a task. A subnet’s incentive mechanism defines the work being evaluated; tempo defines the block interval over which periodic subnet processes are grouped (Understanding Incentive Mechanisms).
That distinction keeps timing vocabulary separate from evaluation vocabulary. Tempo helps determine when subnet work is processed, while the incentive mechanism explains what validators are evaluating (Subnet Hyperparameters).
Wall-Clock Length Depends on Block Production
Tempo is counted in blocks, so its wall-clock length depends on the network context producing those blocks. Bittensor network documentation separates localnet timing modes from testnet and mainnet, including fast-block and non-fast-block local settings (Bittensor Networks, Glossary: Fast blocks).
For readers, that means a tempo example should keep the block count and the environment label together. The tempo value explains how many blocks group the subnet process; the surrounding network context explains how quickly those blocks pass in that example.
The glossary still gives documented approximate equivalents at standard block production: the 360-block lower bound is about 72 minutes and the 50,400-block upper bound is about 7 days. Those figures assume standard block timing, so an environment producing blocks faster or slower shifts the wall-clock length away from them (Glossary: Tempo).
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For tempo on a subnet such as netuid 1, that sequence changes how readers should interpret block cadence, epoch boundaries, and reward timing.
In localnet, tempo behavior can be tested in an isolated environment. Local examples reflect local block production and subnet parameters rather than production timing.
On testnet, tempo can be observed in a shared, non-production network. Testnet interval boundaries on a selected netuid are separate from mainnet emission and consensus outcomes (Glossary: Tempo).
On mainnet, tempo is the production block cadence that groups subnet processes into periodic reward and consensus timing on the connected Bittensor network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A tempo example from one environment should not be read as representing block cadence or emission timing in another environment.
Distinction from Epoch
Readers often swap epoch and tempo because both appear in subnet timing discussions. Tempo is the hyperparameter that counts how many blocks make up one consensus cycle; epoch names the consensus period in which validators submit weights and Yuma settles outcomes at the cycle boundary (Glossary: Tempo, Glossary: Epoch, Implementation of the Yuma Consensus Epoch).
Use tempo when the question is the block count for one cycle. Use epoch when the question is the full window from submission through boundary settlement.
A tempo should not be treated as the full consensus process: it names the interval, while the epoch names the period in which consensus work is carried out (Glossary: Tempo, Glossary: Epoch).
Distinction from Block
A block is one step of chain progression. Tempo counts how many blocks pass before the next subnet emission step (Glossary: Block, Glossary: Tempo).
- Block — one step of chain progression.
- Tempo — block count that groups periodic subnet distribution.
Distinction from Emission
Emission names both injection and distribution. Injection can run every block, while distribution from accumulated alpha waits for the tempo boundary (Emission, Emission: Injection and distribution).
If the reader is asking when pooled rewards are credited to participants, tempo is the timing label—not the whole emission model.
Distinction from Yuma Consensus
Tempo is the per-subnet hyperparameter that sets how many blocks make up one consensus epoch. It answers how long validators have to submit weights before settlement, not how Yuma turns those submissions into emission shares (Subnet Hyperparameters, Glossary: Tempo, Yuma Consensus).
- Tempo — block count per consensus epoch on a subnet.
- Yuma Consensus — on-chain mechanism that uses validator weights to determine emission shares (Yuma Consensus: Validator emissions).
Distinction from Weights Rate Limit and Activity Cutoff
These block-count settings are easy to confuse with tempo because all are measured in blocks:
| Term | What it names | | ------------------ | --------------------------------------------------------------------------- | | Tempo | Block interval for accumulation and distribution at the boundary | | Weights rate limit | Blocks a validator must wait between weight commits | | Activity cutoff | Early blocks in the epoch when weights must arrive to join the current pass |
(Subnet Hyperparameters, Subnet Hyperparameters: Activity Cutoff).
Tempo sets how long the epoch lasts. Activity cutoff sets how early a validator must act inside that epoch. Weights rate limit spaces repeated commits from the same validator.
Distinction from Subnet Task
Subnet task names the work a subnet expects miners to perform, while tempo names the block-based cadence that groups periodic subnet processes such as weight processing and reward distribution (Glossary: Subnet Task, Glossary: Tempo).
The task defines what miners are evaluated on; tempo defines how often that evaluation is processed into outcomes.
Distinction from Delegation Rewards
Tempo names the subnet epoch boundary when finalized rewards are distributed, while delegation rewards are credited as part of that distribution step rather than as a continuous wallet fee (Glossary: Tempo, Emission).
Tempo names when distribution happens; delegation rewards name one share that distribution credits at that boundary.
Distinction from Emission Split
Tempo is the recurring subnet interval, while an emission split is the role partition applied when that interval ends, not on every block (Glossary: Tempo, Emission).
Tempo names the timing boundary; the emission split names how the accumulated value is partitioned at that boundary.
Distinction from Fast Blocks
Tempo is measured in blocks, not seconds. Fast blocks accelerate block production in local development, so the same tempo elapses in less wall-clock time under that mode (Glossary: Tempo, Glossary: Fast blocks, Run a Local Bittensor Blockchain Instance).
Distinction from Rate Limits
Tempo paces each subnet epoch’s consensus and emission in blocks. Rate limits space repeated chain actions from the same key (Glossary: Tempo, Rate Limits).
Distinction from Commit Reveal Period
Tempo names the block-length cadence of one subnet epoch. The commit reveal period counts how many of those tempos pass before a committed weight set is revealed (Glossary: Tempo, Subnet Hyperparameters, Commit Reveal).
Distinction from Subnet Weights
Subnet weights set how much relative emission share a subnet receives in cross-subnet injection. Tempo sets how often a subnet distributes accumulated rewards through consensus at a block boundary (Glossary: Tempo, Glossary: Subnet Weights, Emission: Injection and Distribution).
- Subnet weights — relative cross-subnet share of TAO injection.
- Tempo — block interval on which a subnet distributes accumulated rewards.
Injection share and distribution cadence answer different timing questions (Emission).
Distinction from Alpha Distribution Ratio
The alpha distribution ratio and tempo name a ratio and an interval. ADR compares two alpha movement paths within a subnet’s tokenomics, while tempo is the block interval that defines a subnet’s epoch and paces when emissions are released and distributed (Glossary: ADR, Glossary: Tempo).
- Alpha distribution ratio — the distribution-versus-injection ratio for subnet alpha.
- Tempo — the block interval that paces a subnet’s epoch and emission release.
Distinction from Bittensor Emissions
Bittensor emissions are newly created TAO and subnet alpha entering the reward system. Tempo is the block interval that defines each subnet epoch and paces release and distribution (Glossary: Tempo, Emission).
- Bittensor emissions — newly created TAO and alpha entering reward flows.
- Tempo — block interval that paces subnet epoch and distribution.
Supply-entry vocabulary and epoch-cadence vocabulary answer different timing questions (Subnet Hyperparameters).
Distinction from Emission Timing
Emission has an accumulation-and-distribution rhythm. Tempo supplies the block-count cadence for that periodic process at subnet boundaries (Emission, Glossary: Tempo).
- Emission timing — accumulation-and-distribution rhythm across the protocol flow.
- Tempo — block interval that marks when subnet distribution runs.
Timing-flow vocabulary spans injection and distribution; tempo vocabulary names the subnet boundary (Yuma Consensus).
Distinction from Coinbase
Tempo is the block interval between epoch distributions; coinbase is the per-block routine that mints and advances emission each block (Glossary: Tempo, Coinbase documentation, Emission).
- Tempo — the block interval between a subnet’s epoch distributions.
- Coinbase — the per-block routine that mints and advances emission each block.
Reader Boundary
Tempo should be read as a block-count cadence for subnet processes. It is not a wall-clock promise, a subnet quality signal, or a substitute for Yuma Consensus. It tells readers how timing is grouped for rewards, epochs, and related subnet processes (Glossary: Tempo).
The article-level point is stable even when specific values differ by subnet: tempo is the cadence that helps turn block progression into periodic subnet consensus and emission timing (Emission).