If you are in the process of unbonding you should be able to restore your bond to the original validator. You would potentially lose validation reward for the period in which you were unbonding (unless you were rebonding).
If you cancel an unbond, and are now rebonded you should be slashable even for the period you were unbonding from the validator (?)
Is this still a prelaunch task, or can it be punted to postlaunch?
seems like a fairly simple, fairly useful feature - but I agree should not be required prelaunch
We changed the semantics here right? Under that assumption I'm going to close this issue. If I'm wrong please reopen.
nah this is still relevant
fede [12:28 PM]
mean with redelegation canceling you would have to send two txs to (1) cancel and then (2) redelegate again. Why can’t we have it in one pass ?
cwgoes [12:27 PM]
We don't allow redelegation canceling
fede [12:28 PM]
yes but I mean with regards to https://github.com/cosmos/cosmos-sdk/issues/577
cwgoes [12:34 PM]
Ah - "canceling" a redelegation would rebond your stake with the original validator
If you wanted to then redelegate to another validator, you could do that in a multi-Msg transaction
fede [12:39 PM]
So canceling is just a redelegation to the source validator ?
cwgoes [12:39 PM]
If we implement it, canceling a redelegation would re-bond the tokens to the source validator and unbond them from the destination
fede [12:43 PM]
do you still have to wait the unbonding period if you don’t have any modifications (redelegations or slashing) of the original shares ? (edited)
fp4k [12:46 PM]
oooh interesting - yes the destination validator of a redelegation effectively has a delegation, so a “cancel-redelegation” command means that this destination validator delegation would need to redelegate back to the source validator! (and yes that takes an unbonding period) - this is mad ugly
I don’t think we should implement a “cancel-redelegation” command for those reasons… “cancel-unbonding” is simple and nice though
This is a nice to have. There is already an instance of dark UI patterns where a validator's UI allowed three options, "reinvest income, withdraw income, undelegate". The undelegate triggers without a warning of a waiting period. This command will allow a mistake like this to be less punitive.
bump : )
It seems there is still interest in this idea. I would like for someone, maybe from the community, to take a stab at writing an ADR for this.
Namely, I'd like to fully understand the semantics in the protocol changes needed surrounding safety and rewards.
@sunnya97?
Most helpful comment