MIP-18 - Migration feature for delegated EGLD to improve the efficiency of the dynamic validator market

Introduction and Reasoning

Staking v4 was a much-needed addition to the mainnet. It introduced a new mechanism to determine node eligibility based on a dynamic top-up market, which is based on the current top-up of the nodes in the auction list. In other words, validators now regulate each other. Validators dynamically decide in this free and open market how much top-up is required on the MultiversX network for a node to be eligible for participation in the consensus algorithm.

However, a key role in this otherwise quite elegant solution is missing to reach the goal of a free and open market. Delegators, in theory, play a role in this system. As has been discussed on X (formerly Twitter) and on the Agora forum, validators should be incentivized to be competitive and offer the best quality, highest rewards, lowest fees, or other perks to attract new delegators (or keep their existing delegators). This was a key argument for introducing Staking v4.

Unfortunately, while in theory delegators do have a powerful position in this open market, in practice they cannot leverage their position without putting themselves at a disadvantage at the same time (a lose-lose situation). For delegators to leverage their position, they need to unstake their EGLD and then later re-stake their EGLD with another provider of their choice.

This fact ultimately means that delegators will not receive rewards for 10 full epochs and also have to pay the transaction fees for unstaking, unbonding (claiming), and finally re-staking with a new provider. So, not only is it time-consuming, but it also costs the delegators all of their rewards for the time of the unstaking period, and furthermore, it also costs the transaction fees of the three required transactions to finish their migration to a new validator.

If we look at the validators today, we will see a wide variety of providers — some offering 6% APR, others offering even 9%. The fee market is also very dynamic, as some validators offer (temporary) 0% fees for growth, many offer competitive fees around 1-5% while others charge up to 15-20% in fees.

The general consensus among community members who manually delegate (as opposed to using liquid staking) is that the reason average delegators do not switch between validators is exactly what has been outlined in the previous paragraphs. For the average person, the required time, transactions, costs, and effort for switching to another staking provider are simply seemingly not worth it.

In practice, it is worth it if the APR difference between validators is high enough or if enough users participate in the open market so that staking providers are incentivized to become competitive, increasing market efficiency for everyone.

However, the reality is that there are only seldom cases where the APR difference is significant enough to make switching providers worthwhile for the user. Additionally, the APR is dynamic and may drop, putting the user in a disadvantageous position again. Furthermore, given the dynamic nature of APR, a user can’t be certain that losing out on 10 days of rewards will be worth it, which provides additional hesitation to making a decision to switch. Thus, due to the perceived risk and the psychological resistance associated with the sunk cost fallacy and comfort zone, individual users are unlikely to switch providers, and consequently, this behavior is reflected on a larger scale among the masses.

If the masses never switch providers regularly based on better conditions, quality, rewards, or other perks, the involvement of the delegators in this open market is practically zero - and this is what we have been seeing for years on the mainnet. Almost nobody switches providers - it is economically totally unfeasible, and the impact of a single individual is next to none.

Therefore, this proposal aims to enhance the delegator’s position by cleverly leveraging a new mechanism that allows easier switching of the staking provider for delegators without impacting the security of the Secure Proof of Stake mechanism one bit.

This proposal represents a small yet significant improvement to the network. The implementation difficulty cannot be precisely estimated, but it is likely not substantial because it does not interfere with the consensus mechanism. Ideally, it should be implemented as an upgrade, deployed to the testnet for thorough testing, and then released to the mainnet promptly. This mechanism is long overdue and highly necessary for increasing the network’s efficiency and competitiveness.


The Proposed Mechanism

The result of intensive discussions among multiple people involved in the creation of this proposal, with an emphasis on not changing anything about the Secure Proof of Stake mechanism or impacting the security of the network in any way, is as follows:

A new feature is added to the mainnet that enables delegators to move their stake to another staking provider without the need to unstake the EGLD. This feature shall be accessible by users and smart contracts alike, so that DAO-governed liquid staking solutions can also make use of this new mechanism.

The exact workflow of this new mechanism is described as follows:

  • The delegator wants to switch from staking provider A to staking provider B for arbitrary reasons. The current epoch is #1, and it is 11 a.m.
  • The delegator initiates the transfer using a new migration function in the global staking smart contract, which leads to the initiation phase of the migration. The time is epoch #1, 11:30 a.m.
  • Staking provider A can see the initiated EGLD migration on the blockchain (through interfaces such as the official explorer or their own node interfaces). Staking provider A is now aware of the migration initiation and can prepare accordingly.
  • Staking provider B can see the initiated EGLD migration on the blockchain just like staking provider A. They can also take appropriate measures, such as adding a new node if necessary.
  • Both staking providers A and B have enough time to act and react to the migration request, as the full migration takes 10 epochs.
  • Epoch #10, 11:00 a.m. - only a few hours remain until the tenth epoch change has commenced. Up until now, the EGLD of the user is still delegated with staking provider A. Therefore, staking provider A has not lost any EGLD in their delegation so far. All their nodes still get to use the user’s delegated EGLD to ensure eligibility in consensus participation. Subsequently, the user is still earning rewards from staking provider A as usual.
  • Epoch #11, 5:00 p.m. - Epoch change has commenced. The migrated EGLD are now fully deducted from staking provider A and accredited to staking provider B. From now on, staking provider B has an increased amount of delegated EGLD, can potentially run more nodes, and the delegator will now earn rewards generated by staking provider B instead of staking provider A.

This mechanism fully incorporates the already existing 10-day unbonding timer, without the consequence of the EGLD being immediately removed from the staking provider.

When unstaking EGLD on the mainnet, the EGLD is removed from the staking provider, which may lead to nodes becoming ineligible for participating in the consensus algorithm. In contrast, this migration mechanism does not remove the EGLD from the staking provider the user wants to migrate from immediately. Instead, the EGLD is removed from the provider only after 10 epochs.

This gives the provider plenty of time to react by preparing the removal of nodes or even changing their modus operandi to become more competitive again and retain their other delegators.

The receiving provider of the migration also gets enough time to potentially prepare and add new nodes to the network, and perhaps adapt fees as well, to ensure a competitive stance.

If there were no 10-epoch preparation time, staking provider A might incur additional costs from running nodes longer than necessary (running more nodes than are eligible). Staking provider B could potentially experience a significant drop in the offered APR (running fewer nodes than what could be possible). The overall network security could be weakened due to the reduced number of eligible nodes for consensus participation.
All of these issues are eliminated through this 10-day migration period.

Furthermore, the user will not experience a loss in rewards during this period. During the 10-epoch period, the delegator will continue receiving rewards from staking provider A, and after the 10th epoch, the delegator will receive rewards from staking provider B onwards.

As another positive side effect, only one transaction will be necessary for the user to migrate their EGLD from provider A to provider B. The mechanism can automatically calculate the epoch in which the change will occur (10 epochs from the current epoch), and upon epoch change, the migration is executed and finalized. This further lowers the barrier to migrating between staking providers and increases the efficiency of doing so, incentivizing delegators to actively participate in the open and dynamic validator market.

All of this will not, nor is it supposed to, impact the way unstaking works. Unstaking from staking providers must and will remain the same.

Before publishing this proposal, a security measure was considered that would limit the maximum relative amount of EGLD that could be migrated from a validator per epoch (e.g., if 20,000 EGLD are delegated, only 2,000 EGLD could be migrated within the same epoch). However, this idea was later abandoned because there is no unstaking limit per epoch—delegators can unstake their EGLD within the same epoch. Thus, imposing a restriction on migration while the unstaking mechanism remains unrestricted would be inconsistent. Additionally, the 10-epoch migration period provides both the receiving and removing validators sufficient time to react and adjust by adding or removing nodes. Therefore, the proposed 10% maximum removal per day limit became irrelevant.

Another case to consider is when a staking provider has a delegation cap. In this scenario, migrations to the staking provider are not possible, preventing the delegation of more EGLD than the maximum allowed. This also gives validators a tool to disable unwanted migrations to their staking pool. However, it is important to emphasize that validators can never disable migrations from their staking provider to other providers.

It shall be stated that the minimum amount to migrate is 1 EGLD. This aligns with the minimum required amount to delegate, ensuring clarity and eliminating any potential confusion.

In the rare edgecase of an initiated migration to a staking provider that originally had no delegation limit/cap, but later, during the ongoing delegation migration added a delegation cap, the original migration request is still executed fully, as this would otherwise give the receiving staking provider an option to censor/cancel normally immutable and irreversible changes to the blockchain. To fully address this issue: The validator cannot change the delegation cap to a lower value than the future delegation amount, that includes all currently delegated EGLD and all soon-to-be migrated EGLD.

If the validator sets their delegation cap to the absolute minimum outlied in this edge case, no new delegations are possible, as it is certain (assuming no unstaking request happen) that the delegation cap will be fully filled. Therefore the seemingly empty space of the set delegation cap is “reserved” by the ongoing migration.


Conclusion

The proposed migration mechanism addresses critical inefficiencies in the current staking market by enabling seamless transitions between staking providers. This innovation will empower delegators, increase the competitive environment among validators introduced by Staking v4, and enhance the overall efficiency of the MultiversX network without affecting the security.

By lowering the barriers to switching providers, an incentive for active participation in the staking market is created, which will lead to better service quality, more competitive APRs, dynamic fee structures and possibly other benefits created by staking providers. The proposed solution ensures that network security remains uncompromised while providing tangible benefits to all stakeholders.

Implementing this mechanism as a timely upgrade, tested on the testnet, is an important move that aligns the delegators interests with the dynamic market created in Staking v4. This change, while looking like just a minor improvement; is a necessary evolution for the sustainability and growth of the MultiversX ecosystem.

1 Like

An alternative approach to the original proposal is as follows:

Instead of having a 10-day migration period, the migration is executed and finalized INSTANTLY.

However, the user’s delegation is locked at the new staking provider for 10 epochs and cannot be moved again to another provider until this 10-epoch lock expires. This does not affect the ability to unstake.

Advantages:

  • Faster Execution: The migration is completed more quickly for users.
  • Simplified Process: The mechanism is less complex and has fewer edge cases to manage. The simplicity could bring this feature to mainnet faster and promote it’s ease-of-use.

Disadvantages:

  • Reduced Predictability for Validators: Affected validators have less time to plan for changes in delegation amounts.
    • Potential APR Drop: The receiving staking provider might experience a temporary drop in APR if significant sums are migrated.

The main difference lies in the user’s delegation being locked for 10 epochs after the migration is completed, rather than the migration process itself taking 10 epochs to finalize.

1 Like

(post deleted by author)

After reading the original proposal and the first comment below it, what option do you prefer?

  • Option 1 (10 day migration period)
  • Option 2 (instant migration)
  • Option 3 (something ENTIRELY different)
0 voters

Before voting, keep in mind all the pros and cons of each option (by reading the proposal and the comment below it, the following text is merely a summary and is probably not sufficient compared to reading the full proposal and the first comment).

Option 2 allows users to switch providers instantly, which is much faster and more convenient for the users. After switching, a 10-epoch lock is placed on the user’s delegated funds. After the lock has passed, the user can redelegate/migrate to another provider again. The lock does not impact the ability to unstake.

Option 1, on the other hand, has no lock period after migrating, but the migration/redelegation itself takes 10 days. This method, while being convenient for the validators to plan outgoing and incoming delegations more effectively and prepare for them, introduces numerous edge cases and is therefore more difficult to implement compared to Option 2.

These are just summaries. It is NOT recommended to vote on this poll without reading the proposal and the first comment. So if you did not read either yet, please do so now, before voting!

ALL VOTES ARE ANONYMOUS

If you happen to have another idea on how to handle redelegations/migrations of delegated EGLD from one provider to another, please write your own comment. Ideally, your idea is sufficiently different from Option 1 or 2.

If instead you have ideas on how to improve Option 1 or 2, feedback and improvement ideas are also welcome.

Please adequately label your comment, whether you have feedback for Option 1 or 2 or if you want to introduce a whole other mechanism that is significantly different from the discussed options.