Skip to main content
Share this article:

It’s been over three months since Moonriver was launched on Kusama, rapidly becoming the most active parachain with a largest ecosystem of integrations. Over 13 million transactions have been processed on Moonriver to date, with around 1650 ERC-20 tokens deployed, 340k+ wallets and approximately 925k MOVR tokens staked (~$260M USD).

In order to improve the security and stability of the network, the Moonbeam team has made changes to the staking process that will go into effect through the Runtime 1001 upgrade. This post will walk you through changes to the staking user experience:

Nomenclature: Delegations, Not Nominations

Moonriver is the first parachain to implement a custom parachain staking consensus protocol in Kusama that relies on Delegated Proof of Stake (DPoS), where token holders delegate (stake) their tokens to support specific block producers -collators- and earn rewards.

Initially, the Moonbeam parachain staking implementation mirrored Polkadot’s Nominated Proof of Stake naming convention, in which MOVR stakers were called nominators, who “nominated” block producers. However, this created some confusion, because Moonbeam’s parachain staking implementation differs from that used on Polkadot/Kusama: it is only used to incentivize the production of blocks, and does not impact whether they are valid (finality). Block finality is ensured by Polkadot/Kusama.

Since the parachain consensus model implemented on Moonriver most closely resembles a Delegated Proof of Stake model, staking-related actions will now be referred to as “delegations.” This reflects the idea that delegators can directly pick the collators they want to back, rather than an algorithm deciding for them. Moreover, there is no concept of “slashing,” where nominators lose tokens if they nominate a validator who performs unlawful actions. Because Moonriver is still in an early stage, this renaming of functions associated with staking is not expected to cause major disruptions.

Increased Exit/Unbonding Delay

Before, a delegator had two options to exit their delegation to a collator:

  1. Revoke the delegation entirely, and funds would be available within two rounds (exit delay), which was roughly 2 hours.
  2. Decrease the stake amount to the minimum of 5 MOVR tokens, recovering a partial stake instantly (while not intentional, this has been the case since the network launched) and receiving the remaining 5 MOVR delegation within two rounds.

With the new upgrade, each round is increased to 600 blocks (previously 300 blocks), and the exit delay is extended to 24 rounds (approximately 48 hours) from two rounds (approximately 2 hours) .

Runtime Upgrade Changes

All of the following actions now have an exit delay of 48 hours (at the time of writing):


  • Decrease delegation towards a specific collator (bond-less).
  • Revoke a delegation entirely.


  • Decrease self-bond.
    Leave the collator’s candidate set.

The main reason for extending the exit delay is to increase the stability of the Delegated Proof of Stake consensus mechanism. Before, parachain staking participants could swiftly move their entire stake around collators, or even out of the parachain staking module altogether, which creates potential instabilities in the active set of collators. Consequently, an unstable collator active set could lead to block production issues and hamper network performance. We expect the staked amount to be more stable throughout rounds with the new upgrade.

Note that on Kusama, the exit delay (or unbonding period) is 7 days, while on Polkadot it is 28 days. Another main difference is that on Polkadot/Kusama, nominators do not earn any staking rewards while unbonding their funds. On Moonriver, delegators will earn staking rewards from the value being exited out of a delegation.

Manual Exits

Another meaningful change to the staking interface is related to how delegators/collators can decrease or exit their delegations/bonds entirely.

Before the upgrade, delegators/collators would send a transaction expressing their intention to either reduce their bond (delegation / self-bond) or exit their staked position entirely (revoke delegation / leave the collator’s candidate set). Once the transaction was confirmed, the action would be automatically executed after two rounds (around 2 hours). What we have found based on running Moonriver for over three months is that the scheduling of these automatic executions led to some overweight blocks, which were too big to be validated by Kusama. This resulted in minor network stalls and overall poor network performance.

Therefore, exits are now divided into two actions: scheduling and execution. When a delegator/collator wants to either decrease their bond (delegation / self-bond), or exit entirely (revoke delegation / leave the collator’s candidate set), first, they would need to request to do so (schedule). Once the exit delay period has passed (2 days at the time of writing), the delegator/collator needs to execute their request to be enforced. They can also cancel their action at any time, to be able to schedule another one.

Runtime Upgrade Changes

Note the following:

  • Delegators can only schedule either one bond-less or a revoke request per delegation, not both.
  • If a delegator wants to change their request, they need to cancel the previous request scheduled.
  • Collators can schedule a bond-less or leave the collator’s candidate set independently.
  • Only the collator or delegator can schedule/cancel their requests, but anyone can execute requests once they are ready to be executed.

This resembles the Polkadot/Kusama staking model, where nominators have to unbond their tokens first and then unlock them.

Runtime Upgrade Breaking Changes

DApp developers should consider implementing the new terminology and schedule-execute flow. The main actions that are affected by this change are listed below, divided into the Substrate and Ethereum APIs.

Substrate API

Chain state elements that changed

Note that old state elements have been deprecated (storage has been migrated), but they can still be accessed via the staking precompile:

Old State New State
collatorState2  candidateState
nominatorState2 delegatorState

Extrinsics that changed

Note that old extrinsics have been deprecated:

Old Extrinsic Schedule Extrinsic Execute Extrinsic Cancel Extrinsic
nominate delegate
nominatorBondMore delegatorBondMore
nominatorBondLess scheduleDelegatorBondLess executeDelegationRequest cancelCandidateBondLess
revokeNomination scheduleRevokeDelegation executeDelegationRequest cancelDelegationRequest
leaveNominators  scheduleLeaveDelegators  executeLeaveDelegators cancelLeaveDelegators
candidateBondLess  scheduleCandidateBondLess  executeCandidateBondLess cancelCandidateBondLess
leaveCandidates  scheduleLeaveCandidates  executeLeaveCandidates cancelLeaveCandidates


Events that changed 

Old Event Schedule Event Execute Event Cancel Event
Nomination  Delegation
NominatorAdded  DelegatorAdded
NominatorLeftCollator  DelegatorLeftCandidate
NominatorDueReward  DelegatorDueReward
NominationIncreased  DelegationIncreased
NominationDecreased  DelegationDecreaseScheduled  DelegationDecreased CancelledDelegationRequest
NominatorExitScheduled  DelegatorExitScheduled  DelegatorLeft DelegatorExitCancelled
NominationRevocationScheduled  DelegationRevocationScheduled  DelegationRevoked CancelledDelegationRequest
CollatorBondedMore  CandidateBondedMore
CollatorBondedLess  CandidateBondLessRequested  CandidateBondedLess CancelledCandidateBondLess
CollatorScheduledExit  CandidateScheduledExit  CandidateLeft CancelledCandidateExit
CollatorWentOffline  CandidateWentOffline
CollatorBackOnline  CandidateBackOnline
CollatorLeft  CandidateLeft


Methods that changed in the Staking Precompile

Note that old functions will be deprecated in the near future.

Old Function New Function
is_nominator  is_delegator
min_nomination  min_delegation
nominator_nomination_count  delegator_delegation_count
nominate  delegate
nominator_bond_more  delegator_bond_more




Share this article:
Moonbeam Team

Author Moonbeam Team

More posts by Moonbeam Team