-
Notifications
You must be signed in to change notification settings - Fork 208
Disallow subnet owners to set AdjustmentAlpha greater than 0.97 #1606
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.
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
base: devnet-ready
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a big change... Most subnet owners have changed their adjustment alpha. Why are we limiting it to root only? Is this being abused?
pallets/subtensor/src/migrations/migrate_reset_adjustment_alpha.rs
Outdated
Show resolved
Hide resolved
These types of changes should have their source and purpose documented in the origination comment. There's nothing stated as to the reason for the change, and it is contrary to the public discussion where this likely came from. Care should be taken when making params root only. |
The change was supposed to:
and the reason for the change is that multiple subnet owners are exploiting the alpha adjustment parameter to prevent the registration price from settling in at its market value, for example setting it to 1 when the price is high, freezing the price in place, circumventing the removal of the minimum price setting by the subnet owner. |
@ppolewicz @keithtensor This doesn't make any sense to me. Adjustment alpha of .5 is worse at finding the market rate than some value like .8-.97. An adjustment alpha value of .5 will have 50% increases in price on full intervals. And this is what you want the max to be? This parameter was designed to help subnets find a market price, and a value of .97 was recommended. Even with a value of .8, the cost will increase by 20% in one interval if someone registers 3 keys and then drop 10% in the next when nobody registers. With constant 20% movements in price, it becomes a reg bot game to register at the lower 20%, and then nobody registers at the higher 20%, when the "market" price should be somewhere in the middle If you want to enforce a cap, I suggest the cap be changed to .97. There is a lot of value in increasing it above .5 to help the subnet find the market price if that's your goal. This PR does the opposite. The only valid concern that you mentioned is if people lock the registration price at a value of 1 or a value very close to 1 to try to get the price not to move. A cap at .97 would fix that. |
Also, I second that we need more descriptive PR descriptions in the future. A change like this is a very big change to subnet owners and miners. Miners will need to start working on optimizing their reg bot scripts if this is merged. And no motivation behind it or the benefits of the PR were mentioned at all. |
@surcyf123 aboslutely - we knew that it needs to be limited but we didn't know what the proper top value should be. Lets make it 0.97 as you say. There was a big discussion about it on opendev and it wasn't properly serialized into the ticket because the recording got corrupted, sorry about that :( |
pallets/subtensor/src/migrations/migrate_reset_adjustment_alpha.rs
Outdated
Show resolved
Hide resolved
pallets/subtensor/src/migrations/migrate_reset_adjustment_alpha.rs
Outdated
Show resolved
Hide resolved
@surcyf123 changed to 0.97 - the reason behind it is that we want to prevent subnet owners from hiking the price and setting alpha adjustment to 1 to bypass the min_burn setting restriction and make the price reflect its market value If further refined this might end up consuming the entire incentive of all subnets with strong uid pressure where its miners will race to the bottom. It's not yet clear if we'll go on that road, but freezing the reg price is unacceptable. |
Description
Related Issue(s)
Type of Change
Breaking Change
If this PR introduces a breaking change, please provide a detailed description of the impact and the migration path for existing applications.
Checklist
cargo fmt
andcargo clippy
to ensure my code is formatted and linted correctlyScreenshots (if applicable)
Please include any relevant screenshots or GIFs that demonstrate the changes made.
Additional Notes
Please provide any additional information or context that may be helpful for reviewers.