The concept looks good, I added a couple of comments, but the definition of a BIT in here says the description should be precise - I think the missing part is description of the extrinsic and someone on CoR Discord mentioned that they might accidentally pay double when two miners will race to get a slot.
The extrinsic should be something like register_neuron_limit(netuid, hotkey, limit_price_rao).
It needs to be noted that deregistration code is scheduled for a rewrite, so BIT-17 should probably go along with these:
- Set a minimum number of non-immune, non-immortal UIDs per (sub)subnet · Issue #2058 · opentensor/subtensor · GitHub
- Fix neuron pruning · Issue #1903 · opentensor/subtensor · GitHub
to limit the effort of testing etc.
It will also invalidate Change adjustment_alpha minimum settable by the subnet owner to 0.03 · Issue #2056 · opentensor/subtensor · GitHub and Prohibit registrations in the last 10 blocks of a tempo (2 in fast blocks mode) · Issue #2031 · opentensor/subtensor · GitHub is invalidated by reversing the neuron sorting order when assigning immortality (PR going out on that on 2025-10-03 by Greg).
well there’s a 1 registration per block limit, so your transaction would actually just fail if someone else registered at the same time. But if you are not checking the price, and it increases, we can add another one that is limit register. But we should also have a normal register that just pays the current price.
suggest
NeuronIncreaseMult should be sudo with a range from 1 to 5 with up to 3 decimal points
way too easy for the owner to manipulate when combined with the ReductionInterval
NeuronReductionInterval owner limited from 1 to x where x is a small multiple of days
Where is the link to the design discussion as to what happens when combining this with independent subnet mechanisms?
This has been sent to the development queue and is on #1 or #2 for Spigot right now