Skip to content

BIT-0017: Neuron UID registration #30

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

BIT-0017: Neuron UID registration #30

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 57 additions & 0 deletions bits/BIT-0017-Neuron-Registration
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
# BIT-0000: Title of BIT

- **BIT Number:** 0017
- **Title:** Revamping neuron UID registration
- **Author(s):** fish
- **Discussions-to:** none
- **Status:** Draft
- **Type:** Subtensor
- **Created:** 23 Sep 2025
- **Updated:** 23 Sep 2025
- **Requires:** none
- **Replaces:** none

## Abstract

Current issues:
- large burn price fluctuations
- long periods where nobody can register

Proposed fixes:
- price changes every block not every interval
- remove all rate limits from registration

## Motivation

Current neuron UID registration has many issues. It is almost 100% monopolized by reg bots now. And having a performant reg bot can allow you to pay substancially less in registration fees over time. This is flawed. Registration should not be a competition to get your transaction first in the block. And the price mechanism shouldn't be structured in a way that the price is only favorable every other hour. Many subnets have a low adjustment alpha value which cause drastic price movements, but only once per adjustment interval. So, miners end up only registering every other or every 3rd adjustment interval.

## Specification

Proposed new mechanism:
The registration price for new subents should be defined by 2 new hyperparameters settable by the subnet owner, replacing adjustment alpha and adjustment interval.
BurnHalfLife: This will define the number of blocks until the registration price halves from the current value
BurnIncreaseMult: This will define the multiplier that the registration price increases on a registration

Subnets will have a cost that decays as determined by BurnHalfLife and increases by BurnIncreaseMult the block after a registration. MaxRegrationsPerInterval will still be 1.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Subnets will have a cost that decays as determined by BurnHalfLife and increases by BurnIncreaseMult the block after a registration. MaxRegrationsPerInterval will still be 1.
Subnets will have a cost that decays as determined by `BurnHalfLife` and increases by `BurnIncreaseMult` the block after a registration. `MaxRegrationsPerBlock` will still be 1.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

half life is a exponential reduction similar to halving
I think that the formula a linear reduction in value by block - same as subnet registration
NeuronReductionInterval: Number of blocks until the registration price halves from the current value
NeuronIncreaseMult: registration price Multiplier (default is 2)
formula is:

neuron_burn_price = (burn_at_last_reg * NeuronIncreaseMult) - (burn_at_last_reg / NeuronReductionInterval) * (current_block - last_reg_block)
neuron_burn_price = max (neuron_burn_price, minBurnCost)


Param Defaults:
BurnHalfLife: 360
BurnIncreaseMult: 2

Each new subnet will start with a neuron burn cost of 1 tao, halving every 360 blocks. With these defaults, we can target 20 regsitrations per day.

## Rationale

This solves many miner headaches. It eliminates the need for a competitive regitration script in order to get UID slots, and it allows for miners to pay for a slot whenever they want, without rate limits. They will just pay more. It's annoying when miners get rate limited and have to stop their mining operation sitting around until the next adjustment interval. In this new mechanism, there should never be a lock out from new slots, just an exponentional increase in cost as more are bought without waiting. This is also a built-in safety mech for preventing uid spam without adding artificial constrants. It makes everything market-based.

## Backwards Compatibility

No backwards compatibility concerns

## Security Considerations

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Attack vectors

  1. Owner increasing the NeuronReductionInterval so the price remains high for many days (up to 65535 blocks)
    • need to set a high limit to the possible value of NeuronReductionInterval
  2. Owner decreasing the NeuronReductionInterval to 1 or 2 to snipe a cheap registration then resetting the interval to a long value
    • the reset to a high value is blocked by the hyperparameter change rate limit
  3. Owner increasing the NeuronIncreaseMult above 16 so the price remains high for a very long time
    • make this parameter a sudo call
  4. Owner decreasing the NeuronIncreaseMult to less than 1 ... makes it cheap for all miners to be deregistered and forced into immunity
    • make this parameter a sudo call
  5. Miner using a script to register
  • timing is now longer block based, its price based
  • script must pay more for registrations as each registration price increases
  1. Miner using MeV tactics to snipe the cheapest registration
  • FIFO on the Proof of authority nodes
  • the sniping miner must pay more for his registrations as he can no longer batch register at the one price
  1. Miner blocking anyone else from registering
  • the price doubling each registration makes it economically cost prohibitive

Mitigation - limits and formulas

  1. range limit the NeuronIncreaseMult from 1 to 5 with up to 3 decimal points
  2. range limit NeuronReductionInterval from 1 to x where x is a small multiple of days

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NeuronReductionInterval should be controlled by the owner but throttled to like one change a week and capped in a tight range maybe? It only makes sense to change it when uid pressure changes

none
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the new hyperparameters must be limited in such a way that does not in practice allow the subnet owner to prevent the root validators from getting a neuron


## Copyright

This document is licensed under [The Unlicense](https://unlicense.org/).