Activity Cutoff
Activity cutoff is a per-subnet hyperparameter that defines, in blocks, the window a validator has to submit weights during a Yuma Consensus epoch. Official documentation describes it as the number of blocks for stake to become inactive for the purpose of the epoch: a validator that does not submit weights within the first activity-cutoff blocks of an epoch cannot participate until the next epoch.
References: Subnet Hyperparameters
What It Controls
The hyperparameter ties consensus participation to timely weight submission. Within each epoch, a validator must submit its weights inside the activity-cutoff window. If it misses that window, the documentation states it is treated as inactive for the epoch and waits until the next epoch to take part again. The cutoff is measured in blocks, not in wall-clock time.
Reference: Subnet Hyperparameters
Subnet Context
Activity cutoff is one of the subnet hyperparameters, the on-chain state variables that configure a single subnet, for example netuid 1. Like other hyperparameters it is owner-settable, so a subnet owner can change it for their subnet. The documentation lists a default value of 5000 blocks, but the value in force is per-subnet chain state and can differ from the default.
Reference: Subnet Hyperparameters
Why It Matters
The cutoff keeps an epoch’s consensus based on validators that are currently participating. By requiring weights within a bounded block window, it prevents a validator that has gone quiet within the epoch from carrying influence into that epoch’s result. This connects activity cutoff to Yuma Consensus, which aggregates submitted validator weights into the epoch’s outcome.
References: Subnet Hyperparameters, Yuma Consensus
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For activity cutoff, that sequence changes how readers should interpret hyperparameter examples and validator participation windows.
In localnet, activity cutoff can be exercised on an isolated subnet without production stake context. Localnet block counts and epoch timing do not represent mainnet validator participation behavior.
On testnet, activity cutoff applies in a shared non-production network. Testnet epoch windows and weight-submission outcomes are separate from mainnet subnet state.
On mainnet, activity cutoff is a live per-subnet hyperparameter on production subnets such as netuid 1. Observed cutoff values and validator participation depend on the selected subnet’s on-chain hyperparameter state (Subnet Hyperparameters).
The Bittensor Networks reference separates mainnet, testnet, and localnet. An activity-cutoff example from one environment should not be read as representing production participation rules in another environment.
Relationship to Yuma Consensus
Activity Cutoff and Yuma Consensus describe related parts of Bittensor’s incentive system. Yuma Consensus is the on-chain process that aggregates validator weight signals within a subnet into miner incentives and validator dividends, applying consensus clipping, bonding, and emission calculation (Yuma Consensus).
For readers, activity Cutoff names a specific part of that incentive picture, while Yuma Consensus names the consensus process that turns validator weights into the resulting incentives and dividends.
Reader Boundary
This page defines the concept at a high level. It does not report the activity-cutoff value set on any particular subnet, current epoch timing, or which validators are active right now. Those are live chain state that should be checked for the relevant netuid. The 5000-block figure here is the documented default, and the value for a given subnet is owner-settable.
Reference: Subnet Hyperparameters
Activity Cutoff Applies Inside Each Epoch
Subnet hyperparameters measure activity cutoff in blocks within each epoch. Because an epoch spans the block count set by the subnet’s tempo hyperparameter on a subnet such as netuid 1, the cutoff is an early-window rule inside one tempo-sized consensus period rather than a separate schedule.
Official documentation states that a validator must submit validator weights within the first activity-cutoff blocks of the epoch to participate in the current pass (Subnet Hyperparameters).
References: Subnet Hyperparameters, Glossary: Epoch
Missed Submission Waits for the Next Epoch
When a validator does not submit weights inside the activity-cutoff window, official documentation treats that validator as inactive for the current epoch and requires waiting until the next epoch begins before participating again. The rule is about timely weight submission, not about removing stake from the validator.
That waiting period keeps one epoch’s Yuma Consensus pass based on validators who submitted inside the documented window on the selected subnet (Yuma Consensus).
References: Subnet Hyperparameters, Glossary: Activity Cutoff
Tempo Sets the Epoch Length the Cutoff Sits Within
The Glossary: Tempo defines tempo as the subnet-specific block interval over which Yuma Consensus calculates emissions from the latest ranking weight matrix. Activity cutoff therefore applies during the opening block window of each epoch inside that tempo cadence on a subnet such as netuid 1.
Readers comparing the two hyperparameters should keep units straight. Tempo names how many blocks group an epoch; activity cutoff names how many blocks at the start of that epoch allow timely weight submission (Subnet Hyperparameters).
References: Glossary: Tempo, Yuma Consensus