Subnet Deregistration
Subnet deregistration is the Bittensor subnet-lifecycle mechanism that frees a subnet slot when the network is full. The core case is simple: if the 128-slot cap is already occupied, adding another subnet requires one eligible subnet to leave first (Subnet Deregistration).
Why the Cap Matters
Bittensor treats subnet capacity as a bounded resource. The subnet cap keeps the network from growing by unlimited slot creation, while the deregistration rule gives the system a way to rotate capacity toward subnets with stronger market support (Subnet Deregistration, Understanding Subnets).
This makes deregistration part of subnet lifecycle vocabulary rather than a general failure label. It is about freeing one subnet slot under a documented cap, not about judging every miner, validator, or application running inside every subnet.
Selection Rule
When the cap is full, the eligible subnet with the lowest exponential moving average price is the removal candidate. EMA price is a smoothed alpha-price signal, so the rule is tied to market value over time rather than a one-moment price tick (Subnet Deregistration, Glossary: Alpha Price).
That distinction matters for interpretation. “Lowest EMA price” is the documented comparison, while “weak subnet” is only shorthand. The mechanism does not require a manual content review, a social vote, or a broad quality essay about the subnet.
Immunity and Timing
Newer subnets can be protected by an immunity window, which keeps a freshly created subnet out of the removal comparison while it has time to establish price history. Deregistration is also paced by rate limits, so slot turnover belongs to the same family of delayed, bounded network actions as other sensitive subnet lifecycle changes (Subnet Deregistration, Rate Limits in Bittensor).
The practical reading is that selection is not just “lowest price wins removal.” Eligibility, immunity, and timing are part of the concept. A subnet can have a low market signal and still be outside the comparison if the protected window applies.
Creation Pressure
Subnet deregistration is coupled to subnet creation pressure. A full cap creates the need for slot turnover; without that pressure, the concept is not just a standing ranking table. The lifecycle pair is easier to read as “create a slot” and “free a slot” rather than as unrelated operations (Subnet Deregistration, Create a Subnet).
This boundary separates deregistration from ordinary subnet analysis. A reader can understand the mechanism without listing every possible subnet, comparing teams, or turning the article into a status dashboard.
Development Stage Context
Localnet, testnet, and mainnet examples do not carry the same weight. A localnet example can show how the lifecycle rule behaves in an isolated development environment, while testnet and mainnet belong to separate network contexts with separate histories (Bittensor Networks, Introduction to Bittensor: Subnet development).
Localnet examples are isolated development examples. Testnet examples are shared non-production examples. Mainnet deregistration interpretation concerns production subnet lifecycle on the active network.
Relationship to Yuma Consensus
Subnet 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, subnet 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
Subnet deregistration removes a subnet slot when the 128-slot cap is full. It should be kept separate from miner or validator deregistration inside a continuing subnet, from zero-emission removal, and from predictions about future removals (Subnet Deregistration, Glossary: Deregistration).
The documented comparison is lowest alpha-price EMA among eligible subnets, not a manual quality review or social vote. Immunity windows, rate limits, and creation pressure are part of the concept, not optional timing details (Subnet Deregistration, Rate Limits in Bittensor).
A Full Cap With All Subnets Immune Blocks Entry
Subnet Deregistration documentation describes a case where every occupied subnet is still inside its immunity window. When that happens, the selection step returns no removal candidate, registration fails with a subnet-limit error, and no subnet is deregistered until at least one becomes eligible.
That edge case keeps deregistration vocabulary tied to eligibility rather than to automatic turnover. A full 128-slot network can still refuse a new subnet registration if every incumbent remains immune.
Liquidation Converts Alpha Back to TAO Holders
When a subnet is deregistered, official documentation states that alpha in the subnet is converted through the pool and distributed to alpha holders, with the subnet’s TAO reserve allocated pro-rata. Alpha tokens in that subnet are destroyed as part of dissolution rather than continuing as a live subnet asset.
Deregistration therefore ends the subnet market and settles holder balances. It is not the same as miner or validator deregistration inside a subnet that continues to exist (Glossary: Deregistration).
Zero Emissions Do Not Automatically Remove a Subnet
Official Emission documentation notes that emissions and de-registration are intentionally decoupled: subnets with zero flow-based injection can still remain registered, while subnet deregistration continues to use lowest alpha-price EMA among eligible subnets when the cap is full.
That split keeps two vocabulary paths separate. Negative or zero cross-subnet emission share does not, by itself, trigger the subnet-slot removal rule described in deregistration documentation.