Bugfix for: hotkey_swap on a single subnet wipes all root dividend accumulations#2527
Bugfix for: hotkey_swap on a single subnet wipes all root dividend accumulations#2527evgeny-s wants to merge 6 commits intodevnet-readyfrom
hotkey_swap on a single subnet wipes all root dividend accumulations#2527Conversation
hotkey_swap on a single subnet wipes all root dividend accumulations
| pub const InitialStartCallDelay: u64 = 0; | ||
| pub const SubtensorInitialKeySwapOnSubnetCost: TaoBalance = TaoBalance::new(1_000_000); // 0.001 TAO | ||
| pub const HotkeySwapOnSubnetInterval : BlockNumber = 24 * 60 * 60 / 12; // 1 day | ||
| pub const HotkeySwapOnSubnetInterval : BlockNumber = prod_or_fast!(24 * 60 * 60 / 12, 1); // 1 day |
There was a problem hiding this comment.
For zombinet tests
shamil-gadelshin
left a comment
There was a problem hiding this comment.
The fix makes sense but I have a couple of questions about the migration.
| let mut fixed_count: u64 = 0; | ||
| let mut total_count: u64 = 0; | ||
|
|
||
| for ((netuid, hotkey, coldkey), claimed) in RootClaimed::<T>::iter() { |
There was a problem hiding this comment.
It's a huge iteration. Did you have a chance to verify the migration time on the mainnet clone?
There was a problem hiding this comment.
Not yet, but this was my plan. I tried to do it on chopsticks, but I will do the same on the clone.
There was a problem hiding this comment.
Checked the migration, it's pretty heavy.
It was applied on the fifth attempt; all the others had been rejected.
As an option, we can hardcode the affected hotkeys/coldkeys and netuids, because they are known from the indexer.
Will be updating it.
Thanks!
| .saturating_mul(I96F32::from_num(u64::from(root_stake))) | ||
| .saturating_to_num::<u128>(); | ||
|
|
||
| if claimed > claimable { |
There was a problem hiding this comment.
Potential double claim for hotkeys that had already unstaked.
There was a problem hiding this comment.
No double claim is possible. If the coldkey has already unstaked, then claimable = rate * 0 = 0, and since claimed > 0, the migration resets claimed = 0. At this point, both claimed and claimable are 0, owed is 0, and nothing is paid out.
During the stake reclaimed will be adjusted here. But since claimable rate is 0, it is ok.
Description
Fixes #2515
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
./scripts/fix_rust.shto 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.