# Locking periods after Polkadot runtime 1,000,000

Polkadot OpenGov allows DOT holders to voluntarily lock their tokens when they vote for referenda in order to increase their voting power. The same voluntary locking can be selected when they delegate their voting power. You can learn more about this [here](https://wiki.polkadot.network/docs/learn-polkadot-opengov#voluntary-locking).

However, when OpenGov was introduced to Polkadot, the locking periods for each conviction multiplier were incorrectly set to those of Kusama ([multiples of 7 days](https://github.com/paritytech/polkadot/pull/6701/files#diff-fe8c606620a420c2acf20f18fb6402d9baf602f2abf1a0249fc20991b449ec6aR38)), instead of the correct values that existed in Gov1 (multiples of 28 days). This [will be corrected](https://github.com/paritytech/polkadot/commit/d73503cc2351ffec047a4912ecdb3e1eab5f46aa) in the next runtime upgrade. After an issue that was found in the corresponding runtime in Kusama, the runtime upgrade on Polkadot has been postponed.

In this document we explain how this will affect existing votes and delegations.

## TL;DR
Any locks that already exist before the runtime upgrade, will remain the same. Any locks that are introduced after the upgrade, will use the new (correct) locking periods based on the conviction used.

In other words, any votes with conviction that are not removed before the runtime upgrade, even if the referendum has ended, will introduce a lock with the new locking periods. Any delegations with conviction that exist after the upgrade will introduce locks with the new locking periods when they are removed.

If you are interested in actionable items, you can skip to the section "What can I do?", but we recommend reading the whole article to better understand the situation.

## How locks will change

Right now, the locking period multipliers are applied to 7-day periods, and look like this:

| Conviction | Voting power | Locking multiplier | Locking period |
| -------- | -------- | -------- | -------- |
| None | 0.1x | 0x | 0 days |
| 1x | 1x | 1x | 7 days |
| 2x | 2x | 2x | 14 days |
| 3x | 3x | 4x | 28 days |
| 4x | 4x | 8x | 56 days |
| 5x | 5x | 16x | 112 days |
| 6x | 6x | 32x | 224 days |

After the runtime upgrade they will be applied to the correct 28-day periods, and will look like this:

| Conviction | Voting power | Locking multiplier | Locking period |
| -------- | -------- | -------- | -------- |
| None | 0.1x | 0x | 0 days |
| 1x | 1x | 1x | **28 days** |
| 2x | 2x | 2x | **56 days** |
| 3x | 3x | 4x | **112 days** |
| 4x | 4x | 8x | **224 days** |
| 5x | 5x | 16x | **448 days** |
| 6x | 6x | 32x | **896 days** |

## How locks work
First, let us see how conviction voting and the corresponding locks work in the case of direct votes and delegations.

### How locks work when you delegate
When you delegate your vote, your tokens are locked for as long as you delegate on a specific track.

As soon as you undelegate on that track, that's when the locking period starts, provided you had delegated with conviction, and you can unlock them once the locking period expires (with the `convictionVoting.unlock` extrinsic).

If you had delegated without conviction, your tokens can be unlocked as soon as you undelegate them.

Please don't be confused by the scenarios for direct voting in the next section. For delegations the locking period is not affected by the conviction with which the delegate votes, any referenda they may have voted on, or the result of these referenda. **It depends only on the time when you remove your delegation**, and of course, the chosen conviction.

**NOTE:** Each locking period applies separately for each track you were delegating on, as did the delegation itself. Please check the last section "Locks overlap" to learn how this might affect your overall locked balance.

### How locks work when you vote directly
When you vote on a referendum directly, your tokens are locked while the referendum is ongoing, regardless of conviction.

At any point you may choose to remove your vote (with the `convictionVoting.removeVote` extrinsic). When you call that extrinsic, that's when any potential locking period is introduced.

If you had voted without conviction, your tokens can be unlocked as soon as you remove your vote in all cases.

If you had voted with conviction, then we have the following possible scenarios:

#### 1. You remove your vote while the referendum is ongoing:
In that case your vote is removed from the tally and no locking period is introduced. You can unlock your tokens right away (with the `convictionVoting.unlock` extrinsic).
#### 2. You remove your vote after the referendum ended and you voted with the *losing* side:
In that case no locking period is introduced. Your tokens are locked only if you voted with the winning side. You can unlock your tokens right away (with the `convictionVoting.unlock` extrinsic).
#### 3. You remove your vote after the referendum ended and you voted with the *winning* side:
That's when the locking period is introduced, and it starts from when the referendum ended (confirmed or rejected), **not** when you remove your vote. Once that period expires, you can unlock your tokens at any time (with the `convictionVoting.unlock` extrinsic).

**NOTE:** Each locking period applies separately for each referendum you had voted on. Please check the last section "Locks overlap" to learn how this might affect your overall locked balance.

## The effects of the new runtime
Let's see some examples using the simplest case of 1x conviction.

### Effects on delegations
If Account A is delegating to Account B with 1x conviction, we have the following scenarios:

#### 1. Account A *removes* the delegation (and doesn't reapply it to some other account) *before* the runtime upgrade:
The lock is set to **7 days** from the time of the undelegation, and will expire when that period elapses, even if the runtime has been upgraded by then. After it expires, the tokens can be unlocked.
#### 2. Account A *removes* the delegation *after* the runtime upgrade:
The lock will be set to **28 days** from the time of undelegation, and the tokens can be unlocked after that period has elapsed.

**IMPORTANT!!**
It's worth repeating that the locking period is determined and introduced **when you undelegate, not when you delegate**. So, if you delegate before the runtime upgrade and undelegate after, scenario 2 applies and the tokens will be locked for 28 days.

### Effects on direct votes
For direct votes we are interested in **scenario 3** from "How locks work when you vote directly" above, since for scenarios 1 & 2 there's no locking period anyway.

So, for Account A that voted with the winning side on Referendum X with 1x conviction, we have the following scenarios:

#### 1. Referendum X ended *and* they removed their vote before the runtime upgrade
In that case, the lock is introduced before the runtime upgrade. As a result, their tokens will be locked for **7 days** starting from when the referendum ended, even if the 7-day period expires after the runtime upgrade. They can unlock their tokens at any time after that.

#### 2. Referendum X ended before the runtime upgrade *but* they removed their vote after the upgrade
In that case, the lock is introduced after the runtime upgrade. Their tokens will be locked for **28 days** (with the new locking periods) starting from when the referendum ended. They can unlock their tokens after that.

#### 3. Referendum X ends after the runtime upgrade
In that case, when they remove their vote the new locking period of **28 days** will be introduced, starting from when the referendum ended.

## What can I do?
If you have voted or delegated with conviction and don't want your tokens to be locked for longer than currently expected, you should do the following:

1. Remove your direct votes for any concluded referenda where you voted with conviction with the winning side (as described below).
2. Update your direct votes in any ongoing referenda that will not have concluded before the runtime upgrade with a conviction that matches your desired locking period. For example, if you want your tokens to be locked for 28 days you should change the conviction of your votes from 3x to 1x.
3. Update your delegations with a conviction that matches the locking period you want. Please read the relevant section below on how to update your delegations.

Please consult the tables at the top to determine what's the proper conviction for your desired locking period. Obviously, a desired locking period of 7 days or 14 days won't be possible after the runtime upgrade.

If you are interested in maintaining your conviction and don't care about the longer locking periods, you can ignore points 2 and 3, but you can still follow point 1 to avail yourself of the current, shorter locking periods for these referenda.

## How to remove a vote
As mentioned above, for direct votes, any potential locking period for a referendum is introduced when the vote is removed with the extrinsic `convictionVoting.removeVote`.

You can easily see all the referenda you have voted on, along with their status, your vote, and your conviction on [Subsquare](https://polkadot.subsquare.io/votes). From that page you can easily remove your vote for a referendum by clicking on the X button on the right, provided you have connected your account through a supported extension.


**NOTE:** This button only removes the vote. It does not remove any expired locks. These will need to be removed separately with the `convictionVoting.unlock` extrinsic.

### How to change your vote's conviction for an ongoing referendum
To change the conviction of your direct vote for an ongoing referendum all you need to do is vote again with the new conviction.

## How to update your delegations
In order to make any change to your delegations, including changing your conviction, you need to undelegate and then delegate again.

[Nova wallet](https://novawallet.io/) offers an user-friendly way to update your delegations that handles everything under the hood. Please check [their documentation](https://docs.novawallet.io/nova-wallet-wiki/governance/change-delegated-conviction) for instructions.

Alternatively, you can use [this tool](https://www.math-crypto.com/opengov/batch-delegate/) by Math Crypto to generate batch calls that undelegate and delegate, which you can then issue through Polkadot-JS UI. Please note that the locking periods mentioned by the tool are incorrect. Refer to the tables at the top for the correct locking periods.

## Voting or delegating without conviction
When you vote or delegate without conviction there's no locking period, so the runtime upgrade has no effect in these cases. When you remove your vote or your delegation, you can immediately unlock your tokens (yes, they still need to be unlocked with the `convictionVoting.unlock` extrinsic).

## Convictions/Voting power won't change
It's worth noting that the conviction you voted or delegated with (that determines your voting power) won't change with the new runtime. Only the locking periods that correspond to these convictions will change.

## Locks overlap
As always, [locks overlap](https://wiki.polkadot.network/docs/learn-accounts#unlocking-locks).

If you unlock your tokens that were locked because of one referendum, that doesn't necessarily mean that all or any of these tokens will become available if there are locks from other referenda (or for other reasons, like staking).

The situation is similar if you undelegate from some tracks but you still have delegations on other tracks, or if you had delegated with different convictions and/or amounts on different tracks.

Let's see a couple of examples (with the current locking periods):

#### Voting
Account A voted (with the winning side) on referendum 1 with 100 DOT and 2x conviction, and on referendum 2 with 150 DOT and 1x conviction. For the sake of simplicity, let's say both referenda ended at the same time. Account A removes both votes shortly after.

The lock for referendum 1 will expire 14 days after the referendum ended and the lock for referendum 2 will expire after 7 days. During this whole time (since they voted on referendum 2) 150 DOT are locked in total (not 250 DOT).

After the 7 days, Account A removes the lock for referendum 2. Only 50 DOT will actually be unlocked, since 100 DOT are still locked from referendum 1, and will be locked for 7 more days.

#### Delegating
Account B delegated 100 DOT to Account C on the Root track with 2x conviction and 50 DOT on the Big Spender track with 1x conviction. They remove both their delegations at the same time.

100 DOT are locked overall since they delegated on both tracks. 7 days after they undelegated they can remove the lock of the Big Spender track. However, no DOT will be unlocked, because of the existing lock of 100 DOT for the Root track, which can be removed after 7 more days.