redelegation limitation

[Fraccaman]

Redelegating to a validator makes any redelegations from that validator fail.
As an example:

• User A has 10 nam bonded to validator X
• User A has 10 nam bonded to validator Y
• User A redelegates 5 nam from validator X to validator Y
• User A redelegates 5 nam from validator Y to validator Z
  • this transaction fails, even if user A has enough bonded tokens

[Liver-23]

but is it a bug? how do other cosmos chains do that?
coz when you redelegate to any other validator, your tokens are blocked for the unbonding period as you undelegated them, so you can't redelegate too often force and back and to and from the same validator, therefore
this is some kind of cometbft default behaviour

it is a default thing in cosmos to prevent hopping, I just checked with two chains in Keplr app

[Liver-23]

otherwise, you can start hopping on and hopping off creating unrequired VP changes too often
imagine you have 30% of vp affect possibility
and you are jumping between validators each 1-2 blocks

[brentstone]

This is not a bug but more likely just a limitation of the software in some respect. @Liver-23 It is enforced in Namada's protocol too that tokens that were already redelegated cannot be redelegated again before they wait the unbonding period.

But the example that @Fraccaman brings up is that Namada currently restricts you from redelegating any tokens from a validator X if you have recently redelegated other tokens to validator X. So even if you have tokens bonded to X, some of which are redelegated and some of which are not, you are unable to even redelegate the tokens that were not themselves redelegated to X. I think it may have had something to do with the order of iteration for unbonding that would've made it difficult to do this otherwise.

Overall, I don't think this is a concerning feature to have. If anything, it keeps the protocol safer.

[Liver-23]

AFAIK
What we discussed in Discord: how can you distinguish which tokens were redelegated and which were not?
If 5 from A moved to B, which had 10 before and now 15, and you allow to move the other 10 from B to C that literally means the initial 5 can be moved from B to C right after the movement from A to B as tokens do not information about which were moved and which were not.

For sure, if I am missing something and it is possible to distinguish between moved and not tokens, this would be a nice protocol improvement of the usability