Moonriver Technical Update: Staking Changes as Part of Runtime Upgrade 1001

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) .

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

Delegators:

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

Collators:

• 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.

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:

Extrinsics that changed

Note that old extrinsics have been deprecated:

Events that changed

EthereumAPI

Methods that changed in the Staking Precompile

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