Immunity Period
An immunity period is a temporary protection window after a miner or validator enters a Bittensor subnet. The glossary defines it as the period during which new subnet entrants are protected from deregistration for poor performance (Glossary: Immunity Period).
In plain language, immunity period answers: for how long after registration is a new subnet entrant protected from being replaced by a stronger candidate? During that window, low performance does not trigger automatic deregistration (Glossary: Immunity Period).
For a reader, immunity period is not a grace period for reward collection. It protects against removal, not against low emission outcomes. A new entrant with poor performance during immunity still earns according to their subnet results; the protection is specifically against the replacement mechanism that removes low performers to free up UID slots (Understanding Subnets).
The term is a timing concept, not a performance score. It says that ordinary low-performance removal is temporarily limited for a new subnet entrant; it does not say the entrant has already produced strong results.
Entry Grace Window
The miner documentation describes the immunity period as a number of blocks that begins when a miner or validator enters a subnet (Mining: Immunity period).
That makes the subnet-entry event part of the meaning. The window exists because a new entrant needs time to begin contributing before ordinary removal rules based on poor performance can apply.
Block Measurement
Immunity period is measured in blocks. The glossary gives the default as 4096 blocks, and the subnet
hyperparameter reference lists ImmunityPeriod as the subnet setting for the protection window
(Glossary: Immunity Period,
Subnet Hyperparameters).
Readers should treat the block count as timing context. A block-based window advances with chain progression, so wall-clock interpretation depends on the surrounding network and block context.
Deregistration Boundary
Immunity period is closely tied to ordinary entrant deregistration. Miner documentation explains that, when a subnet is full and a new subnet entry arrives, the lowest-emission eligible entrant can be replaced; an entrant still inside the immunity period is protected from that ordinary removal path (Mining: Miner deregistration).
What It Does Not Prove
Immunity period does not prove quality, emission rank, or long-term subnet participation. It is a temporary block-count boundary. Performance, weights, and emissions are still interpreted through the subnet’s evaluation and reward mechanisms after subnet entry (Understanding Subnets, Glossary: Immunity Period).
That boundary keeps the term from being overread. An entrant can be protected from ordinary low-performance removal while still needing to earn its later standing under the subnet’s normal rules.
Evidence Boundary
The immunity-period references support claims about temporary post-entry protection. They do not by themselves prove an entrant’s current status, diagnose why an entrant was removed, or state the active window for every subnet without the selected subnet context.
For readers, the safe use of immunity period is as a reference label for a block-measured grace window after subnet entry (Glossary: Immunity Period, Subnet Hyperparameters).
Registration Timing Boundary
The immunity period should be read as a timing context after subnet registration, not as permanent protection. Registration documentation explains how a participant obtains a UID slot, while subnet hyperparameters describe activity and timing controls that shape subnet participation (Mining: Miner registration, Subnet Hyperparameters).
For readers, immunity-period claims should keep the relevant subnet and block context attached. The concept describes an early participation window, not a guarantee that the participant remains active or protected indefinitely.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Immunity Period, this sequence gives readers a boundary for interpreting registration examples, deregistration timing, and subnet lifecycle notes.
Localnet examples are isolated and reflect local chain state, so they are useful for controlled experiments rather than evidence of live Bittensor behavior. Testnet examples add shared non-production conditions, which can reveal integration behavior without touching mainnet state.
On mainnet, Immunity Period examples should be read as live production subnet lifecycle behavior on the production Bittensor network.
The Bittensor Networks reference separates mainnet, testnet, and localnet, so outcomes from one environment should not be treated as proof of behavior in another environment.
Relationship to Yuma Consensus
Immunity Period 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, immunity period 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
Immunity period should not be read as permanent protection, validator immunity, or proof that a UID remains active. It names a block-counted grace window after subnet registration (Glossary: Immunity Period, Mining: Immunity period).
Immunity Delays Miner Deregistration
Miner deregistration documentation explains that a participant can be removed when a subnet is full and a new registration displaces the lowest-scoring incumbent, but immunity period can delay that displacement for a newly registered UID (Mining: Miner deregistration, Mining: Immunity period).
For readers, immunity period is a timing shield on the registration block axis, not a performance waiver. Once the configured block window ends, normal deregistration rules can apply again.
Each Subnet Sets Its Own Immunity Length
The Subnet Hyperparameters entry lists immunity period as a subnet-configurable value measured in blocks after registration. That makes the window subnet-specific rather than a single network-wide constant.
A precise immunity-period claim should name the subnet whose hyperparameters are being cited. The same term can describe different block counts on different subnets.
Block Window Scope
Immunity period should be read as a block-counted grace window measured from the registration block, not as an uptime guarantee, a performance window, or a stake-quality threshold. The mining documentation and the subnet hyperparameters entry both describe immunity period as a number of blocks after registration, with the formula comparing the current block against the registration block (Mining: Immunity period, Subnet Hyperparameters).
For readers, the relevant boundary is the unit and the starting point. The window is measured in blocks, not in time, and it begins at the registration block of a UID rather than at any quality, stake, or activity event. A precise claim should keep the block-counted grace window separate from the surrounding performance, deregistration, and subnet configuration vocabulary.