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?

2 Answers 2


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.

  • Thanks Jeff. The PR you shared is an valuable consideration for better UX (to complement fast unstake), but it only covers staking. For delegations, I think the scenario mentioned is not the expected behavior. I think a quick fix could be this: In prior.accumulate check if Y > X and only then restart the lock period. Otherwise, if X >= Y, keep the current lock period. This potentially allows for shorter lock periods for the smaller amount, but not sure if it's a security risk. The proper solution would be to keep track of each lock period separately, like we do with votes.
    – michalis
    Commented Sep 29, 2022 at 11:32

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?

  • 1
    Please ask separate questions as new posts, not in the answer to a question 🙏
    – Nuke
    Commented Oct 7, 2022 at 15:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.