opentensor
Disallow subnet owners to set AdjustmentAlpha greater than 0.97
Description
Related Issue(s)
- Closes #[issue number]
Type of Change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Documentation update
- [ ] Other (please describe):
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
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have run
cargo fmtandcargo clippyto ensure my code is formatted and linted correctly - [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream modules
Screenshots (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.
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:
- make it so that the sudo key can still set it to whatever it wants, 0 to 1
- make is so that the owner can only set it between 0 and 0.5
- in the migration reduce the current setting down to 0.5 if it's higher than 0.5
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 :(
@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.