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.

3 Likes

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

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.

Even though I am aware of the necessity of transferring funds from one provider to another, I have a feeling that this will cause a great deal of instability for the provider.
Imagine that at this point, Phase 4, when the APR is fluctuating a lot for the small SP’s, and in the majority of cases, it is only for a few minutes, delegators will leave, putting the provider in some sensitive situations.

2 Likes

I am strongly leaning towards option one, if I’d have to choose between 1+2.

Although from a user perspective, its harder to get (although I don’t see this a thing as of now), as an SP, its probably very annoying to instantly loose people that are migrating to another SP. You can do much more preparations during the 10 days, where you’d see the pending migrations.

I am really curious: Anyone care to share, why they voted for option 2? :thinking:

I think instant migration which is allowed only once per 30 days for example would be sufficiently good. So if you migrated now, you can’t do that again in the next 30 days. You are free to unstake if you want.

2 Likes

This is extremely similar to Option B/2, except that you propose 30 epochs instead of 10 epochs

Yeah, we have to figure out what number is good. This will need a validator call.

Implementation wise is not so simple:

  1. moveFromDelegationAToDelegationB@amount@destinationSCAddress

  2. vmInput.Caller address is the delegator, it is the user address, or the SC address in case of liquid staking contracts or DAO.

  3. vmInput.RecipientAddress is the delegation contract from which the user wants to move his funds.

  4. destinationSCAddress is verified to be a system delegation contract.

  5. The system checks what was the last time the delegator moved funds to this contract, by checking a new storage in which the epoch was saved.

  6. If epoch == 0 or epoch + 30 < currentEpoch we can go to the next step of moving.

  7. Rewards are calculated for the user and saved into claimable rewards (this code already exists and used when user delegates more), and the new amount of delegation is computed by subtracting the amount value.

  8. New function in ValidatorSC is called which makes unStake and unBond in one call for the staking provider, actually the only thing it needs to do is to change the TotalStakedAmount from the staking provider, without adding it to the unStakedFunds. Unstaking of nodes is happening at the end of the epoch if the SP does not have enough funds.
    a. moveStakeFromValidatorToValidator@stakeAmount@validatorB - it can be called by system delegationContracts only. The caller is the delegation contract from which the funds are moved out.
    b. This function will also increase the TotalStakedAmount for validatorB. Nothing else to do.

  9. delegateForUser@userAddress@amount - it can be called by system delegation contracts only. And will call the internal delegate function, compute rewards for the user if the user already had delegation, increase the delegation amount for the user and save to the new storage that userX have migrated funds at epoch Y.

  10. Process finished.

1 Like

Im 100% for the 30 day lock proposal. I was wondering though, what if validatorB gets a large inflow of migrating stakers and decides to “take advantage” by raising the service fees. Those migrated stakers would either have to suffer the raised fees for the remainder of those 30 days or unstake and lose 10 days of rewards. Would it be possible that a service fee change at the side of validatorB resets the remaining migration lock timers for their current delegators?

1 Like

What about resetting the lock period whenever the staking does something like that (increasing fees)? Or alternative, give the user the possibility to hop once more when this happens?

10 Days unbonding while receiving no rewards is not excessive yet makes delegators really think about whether moving providers is a good idea and beneficial. This strikes a perfect balance between keeping service providers stable with regards to maintaining nodes in the auction process and delegators being free to move their funds elsewhere without being overly penalized.

Any mechanism which allows undelegating / migration of stake at a frequent schedule as we have now could seriously impact smaller providers and lead to nodes failing to qualify where they might not currently.

If delegators truly feel they will benefit in the long term by moving SPs then they will accept the 10 day unbonding with no rewards. Moving providers should be a well considered event and not a spur of the moment thing to chase higher APYs which fluctuate over time anyway.

The current v4 Staking is solid, stable and fair so why change it?

Well, some, including us, the creator of the proposal, think the current v4 is indeed solid - however there is always room for improvement.

Other networks already have such a feature, which allows changing providers without the need of unstaking and later restaking. And those networks are fine. It’s a burden to users, takes extra time, costs more money due to transaction fees and in fact, as outlined in the original proposal, is needed in our opinion to really let the qualities of v4 shine.

If you disagree with this, that is totally fine - this is why we do this, and later a governance vote (once the foundation finally deploys the permissionless governance proposal creation for on-chain voting…) so you can vote against it if you do not like it. That’s totally fine.

Yes, it could. But it could also hurt the larger providers, where people are too lazy to unstake under current cirumstances (given how big the hurdle is to unstake and switch providers).

The free market will decide, democracy, the people, will decide where they will want to go. They can - already. They already can decide where to go, but currently it is slow and painful to do so. With this mechanism in place, in theory nothing changes, because they already always could do that, but in practice, the experience of switching will be super smooth compared to before.

Furthermore, we have seen since v4, that some large providers lost a lot of nodes while some smaller providers started to grow - some at crazy speed. The quickest growth seen among the smaller providers has to have been with Colombia Staking, they went from 1 node to 12 nodes in 2-3 months or so.

Anyways, yes, of course, small providers could be hurt. But also large providers could be hurt. But in the end, nothing should change. Since, as you pointed out, anyone can already switch providers - today!


Besides, it is worth being discussed how long the lock-time should be to change providers. Robert Sasu proposes 30 epochs. It is worth being discussed, since the average user possibly does not need to switch providers very often and a cool-down/lock time of 30 epochs seems to be within realistic realms. 10 epochs as proposd by us was just an original proposal. We came here, to the agora, to discuss it with others and hopefully improve the proposal. If people are fine with 30 epochs as well, it will lessen the “hunt” for higher APYs you are fearing as well.


In fact, in light of recent events, it might be even smarter to additionally include this aspect in the proposal:

Staking Providers can only change their service fee once every xy epochs (e.g. 30 epochs). This way, delegators have a certain guarantee the service fee will stay as-is for at least a good amount of time. Furthermore it even more so eliminates the “hunt for higher APYs” as staking providers will need to provide stability before anything else, since they could no longer compete based on changing the service fee dynamically and advertising higher APYs than their competitors.