Upcoming Staking Changes in Moonriver’s Runtime Upgrade 1001

Over 13 million transactions have been processed on Moonriver to date, with around 1650 ERC-20 tokens deployed and approximately 925k MOVR tokens staked ($260M+).

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

If you are actively staking MOVRs on Moonriver, you might have noticed that the latest runtime upgrade (runtime version 1000) has changed the way users interact with the staking features of the network.

As Moonriver has matured and demand has increased, the parachain staking module needed to be revamped to improve security and network stability. This document will explain the main changes made to the staking implementation.

Delegations vs. Nominations

Initially, we used terms for the parachain staking implementation as it was a Nominated Proof of Stake model just as on Polkadot/Kusama. For example, we referred to MOVR stakers as nominators, who nominated block producers. This created some confusion, because our parachain staking implementation differs from that used on Polkadot/Kusama, as it only has to incentivize the production of blocks, and not whether they are valid or not (finality). Block finality is ensured by Polkadot/Kusama.

This new upgrade changes the staking related terminology from nominations to delegations. The main reason for this is purely conceptual. The parachain consensus model implemented on Moonriver resembles a Delegated Proof of Stake model more than a Nominated Proof of Stake model, as delegators can directly pick the collators they want to back, instead of 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 at an early stage, we do not expect this rewording of functions associated with staking to cause major disruptions.

Increased Exit Delay

Before, a delegator had two options to exit his delegation of a collator. On the one hand, he could revoke his delegation entirely, and funds would be available within two rounds (exit delay), which was roughly 2 hours. On the other hand, he could decrease his stake down to 5 MOVR tokens, recovering his partial stake instantly (while not intentional, this has been the case since the network launched). Then, the delegator could revoke his remaining delegation, having to wait for the 2 rounds only for those 5 tokens.

With the new upgrade, each round is increased to 600 blocks (versus 300 blocks), and the exit delay is extended from two rounds (previously 2 hours) to 24 rounds (approximately 48 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.