Polkadot OpenGov delegate changes can prolong DOT locks.

Choose who votes on the affected track

Replacing a delegate changes representation. Direct voting requires ending that track's delegation, while releasing DOT requires satisfying the remaining locks.

Keep delegated participation

OpenGov separates delegation by track, which groups referenda by their permitted authority. Different tracks can follow different delegates. An adjustment to one track doesn't automatically change the others, so an account can retain some delegations while changing another.

Cast individual referendum votes

An account must stop delegating on a track before it can cast its own votes there. An outstanding prior conviction lock doesn't prevent direct voting once delegation has ended. New votes can create their own commitments, so taking control of voting needn't increase the transferable balance.

End delegation without a replacement

Ending delegation without replacing it removes the active delegated commitment on that track. The previous conviction still governs its release. Waiting while delegation remains active doesn't complete the post-delegation period.

Inspect the account and track before changing settings

Polkadot OpenGov runs on Asset Hub, so check the connected chain and the account whose delegation you're changing. A wallet's total DOT display alone doesn't identify its governance commitments. Inspect the selected track's state, the existing delegated balance, and any prior lock before authorizing a change.

Read the existing delegation

The track's delegation record identifies its target account, balance, and conviction. The balance means DOT committed to voting; multiplying it by the conviction's voting multiplier gives voting weight without increasing the number of tokens held. Record the current settings separately from the replacement settings, including the track identifier. Transaction fees also need an available payment balance, so check the estimate for the actual calls and signing arrangement before submission. A large total balance can coexist with little spendable DOT because of governance freezes or other commitments.

Remove recorded votes before delegating

Direct votes recorded on the same track block a new delegation until those vote records are removed. Removing a completed winning vote with conviction can retain its remaining lock. The account can therefore become eligible to delegate while a prior commitment still restricts transfers.

Conviction settings determine voting weight and waiting periods

The selected conviction determines the weight attached to the delegated DOT and its additional commitment after undelegation. Let P mean the runtime's base vote-locking period. The multipliers below express the protocol relationship without assuming a permanent number of calendar days.

The runtime exposes the base period as VoteLockingPeriod. Polkadot's governance runtime uses Relay Chain block numbers for expiry. A calendar estimate must respect that clock; a displayed date doesn't replace the stored expiry condition.

Undelegation starts the previous conviction commitment

The waiting period for a conviction-backed delegation begins when undelegation takes effect, regardless of how long the delegation was active. Undelegating starts the conviction period even when the delegate never cast a vote.

The setting chosen by the delegating account controls that period. A delegate's own conviction choice doesn't replace it.

At protocol level, the new expiry derives from the Relay Chain block number at undelegation plus the base locking period multiplied by the selected conviction's lock-period factor. The chain retains that commitment as a prior lock. A subsequent delegation can coexist with it. With no conviction, undelegation adds no waiting period, although earlier locks and other balance restrictions can remain.

Replace the target in the required protocol order

An active delegation must end before a replacement can take effect on the same track. Changing the target, balance, or conviction uses that order. The existing lock follows the old settings, while the replacement establishes a new active commitment.

End the existing delegation first

The relevant operations are convictionVoting.undelegate and convictionVoting.delegate, with undelegation first. The replacement identifies the track, destination account, conviction, and DOT balance. Sending another delegation call while the account still delegates on that track encounters the existing-delegation restriction. The replacement also requires an admissible track and a balance that the account can back.

Distinguish a batch from separate transactions

These operations can share a utility batch; they don't inherently require separate signed transactions. An atomic utility.batchAll rolls back its contained changes if a call fails. An ordinary utility.batch can retain earlier successful calls after a later failure. Its interruption event and the final track state determine whether the replacement actually took effect.

Accumulated locks can retain a larger balance for longer

When earlier commitments share a track's prior-lock record, the stored amount and expiry can come from different commitments. The prior-lock accumulator retains the largest committed amount together with the latest expiry. This explains why the newest delegated amount alone can't establish how much DOT remains restricted.

A later, smaller commitment can carry a longer duration. If the prior record still contains a larger amount, accumulation can extend that larger amount to the later expiry. The protocol doesn't preserve every earlier commitment as an independently releasable slice within that record.

Lowering conviction affects the replacement delegation's terms. It doesn't shorten an earlier expiry, cancel its amount, or convert an existing commitment into an immediately transferable balance. Repeated changes can therefore postpone release even when the current settings look less restrictive.

Expired prior records need the lock update that clears them. Until that update, a retained amount can participate in later accumulation. Across tracks, the largest remaining class-lock amount determines the governance restriction on the balance. Release still requires considering each track that retains a restriction.

View full-size image

Delegate activity determines where voting power contributes

If the selected account delegates onward on the same track, incoming delegation doesn't propagate to the next account. Your voting power then contributes to no referendum through that delegation chain. A directly voting delegate can apply incoming power to its standard votes, including ongoing referenda it has already voted on. Its activity on another track doesn't establish participation on this one. Reviewing the target's voting state therefore matters alongside its address or public name.

Direct votes follow referendum outcomes

A direct standard vote with conviction creates a post-referendum commitment when its direction matches the final result. That commitment counts from the referendum's end, and removing its vote record afterward preserves any unexpired portion. Delegation follows the undelegation clock instead, which explains why a delegate's losing vote doesn't eliminate the delegator's commitment. Removing a direct vote while the referendum remains ongoing removes that vote from the tally. A losing direct vote or a vote without conviction doesn't create the same winning-vote commitment. Existing prior locks can still restrict the account.

Expired commitments still need an unlock update

Once the relevant expiry condition is met, convictionVoting.unlock recalculates the lock for the specified track and target account. It clears expired prior commitments while retaining any lock still required by active delegation or recorded votes. Calling it early doesn't bypass conviction.

For direct voting, expired vote records may also need removal before the lock can decrease. Interfaces can combine vote removal and unlocking in one action. The specific operations matter more than the button label. Clearing one track won't release DOT that another track still restricts, and a successful unlock can leave the account's transferable balance unchanged.

Finalized state distinguishes replacement from spendability

A signature authorizes a transaction, and a transaction hash identifies the transaction. Neither proves submission or successful execution.

Finalized execution results and the account's track state show whether undelegation or replacement took effect. The Delegated event identifies the delegating account, recipient, and track; the stored record supplies the accepted balance and conviction. An Undelegated event confirms that the active delegation ended on its track. It doesn't certify that the associated DOT is transferable. Even an unlock event needs interpretation alongside remaining restrictions. Read the resulting account balance separately from the governance state, especially when a batch reports an interruption or another track keeps a larger lock.

Other commitments and public records remain relevant

DOT available for transfer also depends on restrictions outside the changed delegation. Staking, nomination pools, vesting, and held deposits have their own release conditions. An OpenGov adjustment doesn't by itself exit a nomination pool, finish staking withdrawal, or release a deposit. These commitments can overlap with governance restrictions, so adding every displayed locked amount can misstate the unavailable balance.

Delegation records expose the relationship between the account and its chosen voting target. Changing a public display name doesn't remove that on-chain relationship. Ongoing monitoring concerns the target's actual activity on the delegated tracks and the account's remaining lock state. A completed delegate change establishes new representation; it cannot establish unrestricted access to DOT that still backs another commitment.