Miner Deregistration

How miner deregistration removes a low-performing Bittensor subnet miner from a UID slot when a subnet needs room for a new registration.

Miner deregistration is the miner-specific case of deregistration in a Bittensor subnet. The official Mining documentation describes it as the removal of a low-performing miner when a subnet is full and a new miner is registered.

Miner-Specific Scope

The broader Deregistration glossary entry applies to subnet miners or subnet validators. Miner deregistration narrows that concept to miners: the participant being removed is a miner occupying a subnet UID slot.

This makes the term role-specific, not a separate scoring system. It describes which type of subnet participant is removed, while the broader deregistration concept describes the general removal process for low-performing subnet participants.

UID Slot Context

The mining documentation places miner deregistration in the context of limited subnet capacity. When a subnet is full, a new miner registration can replace an eligible miner with lower performance. For readers, the important point is that miner deregistration is tied to subnet participation, capacity, and miner performance; it is not a live ranking or a manual recommendation.

Reference: Mining: Miner deregistration

Pruning Score Context

When a subnet is full, the Mining: Miner deregistration documentation identifies the participant with the lowest pruning score as the displacement candidate for a new miner registration. Immunity-period exceptions, tie handling, and full eligibility rules are specified in that reference rather than restated here.

References: Mining: Miner deregistration, Glossary: Deregistration

Development Stage Context

The Introduction to Bittensor describes subnet development as moving from local testing to testchain and then mainchain. For miner deregistration, that sequence changes how readers should interpret examples of miner removal.

In local testing, miner deregistration can show that miner-slot replacement logic is represented inside an isolated subnet environment. That is useful for checking how a miner UID can be vacated, but it does not show that a live public subnet miner has been removed.

On testchain, miner deregistration behavior can be observed in a shared testing network. This gives stronger evidence about how miner removal interacts with new registrations, pruning scores, immunity-period boundaries, and other subnet participants than a private local run, while still keeping the result separate from production mainchain activity.

On mainchain, miner deregistration belongs to live subnet state. The Mining: Miner deregistration reference describes the full-subnet replacement context for miners, so production readings should keep the selected subnet, miner UID slot, block timing, and eligibility context attached.

The Bittensor Networks reference separates mainnet, testnet, and localnet. A miner deregistration example in one environment should not be read as identical evidence about miner removal in another environment.

This distinction matters because miner deregistration is a role-specific subnet outcome, not a standalone quality label. Capacity, miner performance, immunity-period status, and network environment all affect what the example proves.

For readers, this keeps miner deregistration examples from sounding stronger than their environment supports. Local, testchain, and mainchain contexts can all contain miner deregistration language, but they do not carry the same interpretive weight.

When a New Registration Meets a Full Miner Set

Miner deregistration enters the picture when subnet miner UID capacity is exhausted and a new miner still registers. The mining documentation describes removal of the lowest-performing eligible miner so the incoming registration can occupy a slot. That displacement is part of subnet registration economics, not a separate manual purge ordered outside documented rules.

Readers should treat successful miner registration on a full subnet as potentially displacing an existing participant under documented pruning and immunity rules. Which miner is eligible for removal at that moment belongs in live subnet state and official mining references rather than in a static article ranking table. Registration burn payment and displacement eligibility are therefore linked decisions on a full subnet, not independent steps.

References: Mining: Miner deregistration, Glossary: Register

Pruning Score as the Documented Displacement Signal

When displacement is required, the mining documentation identifies the participant with the lowest pruning score as the candidate for replacement by a new registration. Pruning score vocabulary therefore belongs to miner deregistration timing, not to general miner quality branding in isolation.

The distinction helps readers separate ongoing miner evaluation from the specific removal signal used when a full subnet must make room. Tie handling, immunity exceptions, and full eligibility conditions are specified in official mining documentation rather than restated as fixed formulas here. Operational decisions should use current references when a registration event is imminent on a full miner set.

References: Mining: Miner deregistration, Glossary: Deregistration

Participant Removal Versus Subnet Removal

Miner deregistration removes one miner from a UID slot inside a subnet that continues to exist. Subnet deregistration, by contrast, removes an entire subnet to free a network slot when the global subnet cap binds. Official mining documentation describes participant replacement under registration pressure, while subnet deregistration documentation describes whole-market lifecycle removal.

Mixing those levels makes miner policy harder to read. A low-performing miner can be displaced without dissolving the subnet itself. Readers should keep miner deregistration scoped to UID participation inside an active netuid rather than to network-wide subnet sunset events described in subnet lifecycle documentation. The two removal events answer different capacity questions at different network levels.

References: Mining: Miner deregistration, Subnet Deregistration, Glossary: Deregistration

Relationship to Multiple Mechanisms

Subnets can run more than one incentive mechanism in parallel. The Glossary notes that miner performance in one mechanism does not affect their rating in another.

Miner deregistration still describes removal of a low-performing miner from a subnet UID slot. When a subnet uses multiple mechanisms, performance for one mechanism does not by itself describe miner standing in another.

References: Multiple Incentive Mechanisms Within Subnets, Glossary: Multiple Incentive Mechanisms

Relationship to Deregistration

Miner deregistration and deregistration address related but different scopes in Bittensor subnet vocabulary. The Glossary: Deregistration describes removing a subnet miner or subnet validator from a subnet due to poor performance, while Mining: Miner deregistration describes that removal process applied to a low-performing miner when a full subnet accepts a new registration.

For readers, deregistration is the general removal term, while miner deregistration names the miner-specific case of that process.

References: Glossary: Deregistration, Mining: Miner deregistration

Relationship to UID Slot

Miner deregistration and a UID slot are related but different parts of the subnet participation lifecycle. The Glossary: UID Slot describes a participant position inside a subnet, while miner deregistration describes removal of a low-performing miner from that position when subnet capacity and replacement rules require it.

For readers, a UID slot names the occupied miner position, while miner deregistration names the miner-specific process that can vacate that position under official subnet displacement rules.

References: Glossary: UID Slot, Mining: Miner deregistration

Relationship to Netuid

Miner deregistration and a netuid are related but different parts of Bittensor subnet vocabulary. A netuid selects which subnet context is in scope, while miner deregistration describes miner removal inside that selected subnet when eligibility rules are met. The Glossary: Netuid places netuid at the subnet level, and Mining: Miner deregistration describes miner displacement when a full subnet accepts a new registration.

For readers, netuid answers which subnet market is being discussed, while miner deregistration answers what can happen to a low-performing miner inside that subnet.

References: Glossary: Netuid, Mining: Miner deregistration

Relationship to Immunity Period

Miner deregistration and an immunity period address related but different parts of subnet removal timing. The Glossary: Immunity Period describes temporary protection after registration, while miner deregistration describes how a low-performing miner can lose a UID slot once that protection no longer applies or when other eligibility rules are satisfied.

For readers, immunity period names a protection window that can delay ordinary low-performance removal, while miner deregistration names the miner-specific displacement path after that boundary.

References: Glossary: Immunity Period, Mining: Miner deregistration

Relationship to Yuma Consensus

Miner 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, miner 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 the term at a high level. It does not list current miners, count available slots, rank subnet participants, or describe registration steps. Readers should use official subnet references for role-specific operational details.

Relationship to Coinbase

Miner deregistration and coinbase are related but different parts of a miner’s subnet lifecycle. Miner deregistration is the removal of a low-performing miner from a subnet UID slot when the subnet is full and a new miner registers. Coinbase is the per-block protocol mechanism that drives TAO emission, injects TAO into emitting subnets’ pool reserves, accumulates pending emissions, and checks epoch boundaries to trigger Yuma Consensus rounds. The Mining: Miner deregistration documentation describes the removal process, and the Coinbase Implementation documentation describes the per-block emission operation.

Holding a UID slot is what makes a miner visible to coinbase-triggered epoch rounds, so deregistration is the point at which a miner stops receiving coinbase-distributed incentives. While registered, a miner can earn a share of the emissions coinbase allocates each epoch based on validator evaluations; once deregistered, the freed slot no longer appears in the consensus the coinbase round processes, and incentives flow to whoever takes the slot. Coinbase determines the emissions a miner’s slot can earn while occupied; miner deregistration is what ends that eligibility by vacating the slot.

Role Scope

Miner deregistration should be read as removal from a subnet miner slot, not as proof that the account has been removed from every Bittensor role or network context. Miner documentation describes miner registration and deregistration, while subnet deregistration is a separate whole-subnet process (Mining: Miner deregistration, Subnet Deregistration).

This distinction keeps participant-level removal separate from subnet-level removal.

Immunity Period Can Delay Miner Removal

The Glossary: Immunity Period describes temporary protection after registration, while miner deregistration documentation describes removing a low-performing miner when a full subnet accepts a new registration. Immunity vocabulary therefore names a timing boundary that can delay ordinary displacement, not a permanent exemption from subnet performance rules.

Readers evaluating miner removal should keep immunity status attached to the miner UID under review. Miner deregistration remains the miner-specific displacement path once eligibility rules in official mining documentation are satisfied (Mining: Miner deregistration).

Further Reading

Topics SubnetsMining