Voluntary deregistration

[ppolewicz]

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 ./scripts/fix_rust.sh to 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.

[JohnReedV]

Looks good. Need to fix CI

[xerion12]

now this is following good design patterns and clear separation between scheduling and queue logic, which helps keep code organized and easy to follow. Integration with coldkey swap is smart, preventing conflicts when owners schedule both actions, and access control is well thought, allowing subnet owners to schedule or cancel but not remove from queue, while root keeps full control. Defensive programming is used, like checking subnet existence and preventing duplicates, but the queue uses Vec with O(n2) removal, so performance could be better if VecDeque is used instead for O(1) operations. There is no max size limit for the queue, which might be risky if someone tries to fill it, and scheduler slots are consumed with each schedule, so rate limiting could be considered. Error handling is a bit inconsistent, some functions return bool while others use Result, and force_set_deregistration_priority could check subnet existence before enqueueing. Documentation is not very clear about the 5day delay and queue order, and some storage items need more comments. Overall, it’s a strong feature with solid architecture and testing, but needs fixes in performance, security, and documentation before merge. One unique idea is to add a warning event when the queue is near full, so admins can monitor for potential abuse, and maybe allow configurable delay for different subnets.

[gztensor]

Why?