update miner dereg docs

[MichaelTrestman]

based on feedback that it was confusing
"The thing is, people are confused about the distinction between validator and miner, as if the subnet is going to deregister one over the other. As I understand it, for the purposes of deregistration, a subnet will neither know nor care whether a neuron is mining or validating. It just pays attention to the emissions/pruning score.

When I get a chance, I think I might end up submitting a modified article to help out, trexman.

Practically speaking, if someone is able to register a validator, and is in the top 64, and is operating correctly (setting weights within the activity_cutoff, not wildly out of consensus with the rest of the validators), and has a decent stake, they'd probably be pretty safe from deregistration.

And if I'm understanding this correctly, there could be an opportunity for exploitation if someone has the assets to stake and sees a subnet with a relatively small number of validators, because they could effectively become the majority consensus by which the lower-staked validators are the compared (based on stake). But let me know if I'm not understanding this correctly.
Fish | Datura, Celium — 6:56 AM
pruning score, based on emissions, is the deciding factor for deregistrations. It has nothing to do with who is a "miner" or "validator". The chain doesn't care about that
whoever has the lowest emissions will get deregistered
if it's a tie, the older UID will get deregistered
and subnet owner hotkey is immune forever
that's all"

https://discord.com/channels/799672011265015819/917906456261578792/1379096548851585114

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 5, 2025 7:33pm

[Jackalgirl]

Each tempo, the '[neuron](../learn/bittensor-building-blocks)' (miner *or* validator node) with the lowest 'pruning score' (based solely on emissions) risks being replaced by a newly registered neuron, who takes over that UID.

In case of a tie, the older node gets deregistered first.

I'd suggest something like:

Each tempo, the '[neuron](../learn/bittensor-building-blocks)' (miner *or* validator node) with the lowest 'pruning score' (based solely on emissions), and that is no longer within its [immunity period](../subnets/subnet-hyperparameters.md#immunity_period), risks being replaced by a newly registered neuron, who takes over that UID. In the unlikely event that all neurons are still immune, the one with the lowest 'pruning score' will be deregistered by the next incoming registration.

In case of a tie, the older neuron gets deregistered first.

[Jackalgirl]

Typical subnets have 256 UID slots, including maximums of 64 validator UIDs and 192 miner UIDs.

I'd recommend something more like:

Typical subnets have 256 UID slots, including maximums of 64 validator UIDs and 192 miner UIDs, though if there are fewer validators, a miner can occupy one of the additional slots.

I'm not sure how to word all of the extra waffle about "the 65th validator" and all that (what I was talking about in the Discord server), and I'm not sure it's necessary.

[chideraao]

@MichaelTrestman, the files are a little bit bloated due to Prettier's auto-formatting. my bad 😅