Deregistration
Deregistration is the removal of a Bittensor subnet miner or subnet validator from a subnet because of poor performance. The glossary defines the term at the subnet role level rather than as a wallet or account label (Glossary: Deregistration).
The term is most useful as a replacement-boundary concept. It explains how a low-performing entrant can lose its subnet position when capacity and eligibility rules allow replacement.
Capacity Context
Miner documentation describes deregistration in the context of a full subnet. When every available position is occupied and a new entrant arrives, the lowest-emission eligible entrant can be replaced (Mining: Miner deregistration).
The Mining: Miner deregistration reference makes deregistration different from ordinary low rewards: a role can perform poorly without being removed if the surrounding capacity and eligibility conditions are not met.
Performance Boundary
Deregistration is tied to poor performance, but the article should not turn that into a general quality judgment without context. The mining reference describes the replacement path around low emissions, subnet capacity, and eligibility (Mining: Miner deregistration).
For readers, the relevant claim is not simply that someone ranked low. It is that the subnet replacement rule has a specific context in which an eligible low-performing entrant can lose its position.
Immunity Period Boundary
The immunity period is the main timing boundary around ordinary deregistration. It protects new subnet entrants from low-performance removal for a block-measured grace window (Glossary: Immunity Period, Mining: Immunity period).
This keeps deregistration from being read as immediate after subnet entry. A new entrant can have a temporary protection window before the ordinary removal path applies.
Miner and Validator Scope
The glossary defines deregistration for both subnet miners and subnet validators. Miner documentation gives the miner-focused example, while validator documentation describes the same general removal idea for validators (Glossary: Deregistration, Mining: Miner deregistration, Validating: Validator deregistration).
That scope matters because the general term is role-neutral. A page about deregistration should preserve whether it is discussing the general concept, a miner-specific case, or a validator-specific case.
Evidence Boundary
Deregistration references support claims about subnet-role removal under poor-performance and replacement conditions. They do not by themselves prove a current entrant’s status, diagnose why a specific position changed, or describe removal of an entire subnet.
For readers, the safe use of deregistration is as a reference label for entrant-level removal inside a continuing subnet. Subnet deregistration is a different topic because it removes an entire subnet rather than one miner or validator from a continuing subnet (Subnet Deregistration, Glossary: Deregistration).
Relationship to UID Slot
Deregistration and a UID slot describe two sides of the same participant-level lifecycle event. The Glossary: Deregistration describes removal of a subnet miner or validator from a subnet, while the Glossary: UID Slot describes the participant position that miner or validator occupies inside the subnet.
For readers, deregistration names the removal process, while the UID slot names the position that can be vacated by that process. This keeps entrant-level removal separate from subnet-level removal and from ordinary changes in rewards or performance.
Selection Boundary
Deregistration should be described as a protocol selection outcome, not as a general judgment about a participant outside the subnet context. The subnet deregistration source ties removal to subnet capacity and selection rules, while registration documentation explains how UID slots are obtained in the first place (Subnet Deregistration, Mining: Miner registration).
For readers, the important context is the selected subnet and the rule that produced the removal. A deregistration claim should avoid implying that the same account is removed from every subnet or from the network as a whole.
Relationship to Yuma Consensus
Deregistration 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, deregistration 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 article defines deregistration at a high level. It does not list current subnet entrants, rank participants, or describe registration commands. Live replacement eligibility belongs in official mining and validator references (Glossary: Deregistration).
Full Subnet Capacity Enables Replacement
Miner documentation describes deregistration when a subnet is full and a new entrant registers. The lowest-emission eligible entrant can then be replaced under documented rules (Mining: Miner deregistration).
Deregistration vocabulary therefore depends on subnet capacity and eligibility context, not on a standalone performance label detached from registration pressure.
Role-Specific Articles Narrow the General Term
The Glossary: Deregistration applies to both subnet miners and subnet validators. Miner and validator documentation each describe the removal path for that role inside a continuing subnet (Validating: Validator deregistration).
Readers should name whether the prose means general deregistration, miner deregistration, or validator deregistration before citing displacement outcomes.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Deregistration, that sequence changes how readers should interpret removal examples, subnet-capacity observations, and eligibility comparisons.
In localnet, Deregistration examples can be exercised in an isolated environment. Localnet observations reflect local chain state and local configuration rather than production Bittensor behavior.
On testnet, Deregistration behavior can be observed in a shared, non-production network. Testnet examples are useful for checking interactions under shared chain conditions while staying separate from mainnet state.
On mainnet, Deregistration describes live production subnet removal behavior on the production Bittensor network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. An example or outcome from one environment should not be read as evidence of production behavior in another environment.