Right now, a staker must set an operator before any commitments can flow through them on this contract.
They can later update the operator that their commitment flows through, triggering a "restaking".
However, they currently cannot signal that they are stopping operations.
A staker should be able to unset the operator (deleting that key), while keeping the reverse mapping of operator -> staker, so they can still be slashed during the unbonding period.
The existing stake to that operator should enter the unbonding period locally, and once that period has passed, they can make a call that will trigger ReleaseStake on the provider (meaning it is fully unbonded, and can release all the way up the chain).
This will require two new ExecuteMsg variants:
- unset operator
- release unbonded (or such)
You may want to add new queries as well to expose this information.
This is also needed to test #61 as it will be the first real way we will trigger release stake in a normal contract flow.
Right now, a staker must set an operator before any commitments can flow through them on this contract.
They can later update the operator that their commitment flows through, triggering a "restaking".
However, they currently cannot signal that they are stopping operations.
A staker should be able to unset the operator (deleting that key), while keeping the reverse mapping of operator -> staker, so they can still be slashed during the unbonding period.
The existing stake to that operator should enter the unbonding period locally, and once that period has passed, they can make a call that will trigger
ReleaseStakeon the provider (meaning it is fully unbonded, and can release all the way up the chain).This will require two new ExecuteMsg variants:
You may want to add new queries as well to expose this information.
This is also needed to test #61 as it will be the first real way we will trigger release stake in a normal contract flow.