[FEAT] Operator Management Features

[monaiuu]

Description

Add ability for registered operators to manage their status, bond, and participation in the network. This includes basic operations like going offline/online, adjusting bond amounts with proper unbonding periods, and exiting operator role with appropriate validations.

Status Control

• Going Online/Offline
• Show current status

Bond Management

• Increase bond
• Schedule bond decrease
• Execute scheduled decrease
• Cancel decrease request
• Show pending unbonds with timeline

Leave Operator

• Schedule leave (requires no active delegations)
• Execute leave after delay period
• Cancel leave request

Notes:

• Cannot decrease below minimum bond
• Cannot leave with active delegations
• Must wait delay period for executing unbonds/leave

[drewstone]

@yurixander @AtelyPham @monaiuu can you please meet and discuss building a general component that can support any extrinsic like is done in PolkadotJS?

Lots of this is functionally similar and I believe PolkadotJS uses a pattern that automates some of this.

[drewstone]

And we need to be able to implement these types of things FASTER!

[vutuanlinh2k2]

@drewstone I have some questions here:

1. Cancel Unstake Request, Cancel Leave Request functions are missing in the current contracts, but I assume this is non-critical and we can ignore them for now
2. For Online/Offline Status Control, are we dealing with Per-service availability, Per-blueprint availability or Global status. As I checked with AI, only Per-service availability is available for now
3. Operators CAN leave even with active delegations. We can accept as it is: Let operators leave regardless (delegators can still unstake)
4. Blueprint-Level Bond vs Restaking-Level Bond:

The system has TWO separate bond concepts:
  A. Restaking Self-Stake (OperatorManager):
  - Global operator stake
  - Can increase/decrease with delays
  - Affects minimum stake requirements for all blueprints
  B. Blueprint Bond (Operators.sol):
  - Per-blueprint bond paid during registerOperator()
  - Fixed at registration time
  - Refunded on unregisterOperator()
  - No increase/decrease functions for per-blueprint bonds
If your feature is about blueprint-level bonds, you can only:
  - View current bond: _operatorRegistrations[blueprintId][operator].bondAmount
  - Refund by unregistering (destroys registration)
If your feature is about restaking-level self-stake, you have full functionality (except cancel).

[drewstone]

Correct there is no cancel action, there is schedule and execute afaik. This is fine and we can delete the ability to cancel these requests (i.e. don't make them if you don't want to unstake or leave). If you do unstake and/or leave, you can just join again right after.

Always try to check what tangle substrate had so we can fix or improve our underestanding of what the state is. I think the intention for online/offline status was global so that customers don't select you but it is possible we did get some logic around per service online/offline-ness. Not entirely sure.

On operators being able to leave even with active delegations, yes that is fine, and also this is dependent on the Blueprint implementation itself which can override and implement custom canLeave functions for whatever it expects the behavior to be. These decisions get closer to developer decisions.

I think we should get rid of blueprint specific bond, let me investigate.