Delegating and undelegating during the lock period extends it for the initial amount

Question

I'm trying to understand the following behaviour:

• A user delegates their vote (X DOT) with 1x conviction
• Then they change their delegation to a smaller amount (Y DOT) with the same 1x convinction
• Then they undelegate (at time t)
• Before the lock period expires, they delegate Y DOT again with 1x conviction and then undelegate them once more (at time t1)

The apparent result is that the lock period of the initial amount (X DOT) is "reset" when they undelegated the second time. So, X DOT is locked for t1 + 28 days, not t + 28 days, as one would expect.

This is defined in chain state, by prior, when querying democracy.votingOf

If I understand the prior.accumulate function correctly that does this here, it locks the max amount for the max length, effectively perpetuating the initial lock in the above scenario.

Is this correct? Is this a feature or a bug? If it's a feature, what's the reasoning behind it?

Answer 1

We definitely should clean up these behaviors obviously, but right now afaik nobody clearly articulated all the concerns, so what fixes happen maybe lacking somehow unless someone spells out the various perceived shortcomings.

You'll find https://github.com/paritytech/substrate/pull/12359 interesting, but again I do not know what portion of those concerns it covers, likely only staking actions.

Answer 2

Another thing, based on the prior.accumulate function the largest DOT period and longest conviction amount will be used. Meaning that if the first delegation is 200 DOT with 3x conviction, and the delegation is changed to 500 DOT with 1x conviction, the lock period will reset for 500 DOT with 3x conviction. Which would be buggy behavior.

Also, another question: If the lock hasn't been removed even after its period has expired, can we assume the same behavior?