mDAO Proposal - Change delegation strategy to use 10 epoch average

Governance
#1

Hello Folks

What do you propose
Marinade has for a long time been leading the way with it’s open and transparent validator staking algorithm and delegation strategy. Every epoch’s calculations/predictions can be viewed on Github and many validators actively track these scores and discuss them on the Marinade Discord.

About six months ago the algorithm was updated to use a 5-epoch average, particularly when looking at vote credits score. (Validators must be in the top 250 vote credits over a 5 epoch average to qualify for Marinade delegation).

Since then there have at various times been discussions around raising this to 10 epochs. In this post I am proposing to raise that threshold to a 10 epoch average.

This will help stabilize the algorithm and reduce excessive stake/unstake operations that cause a lot of fluctuation for validators but also result in costs and lost returns to Marinade due to the warmup period stake experiences when it is moved to a new validator.

Pros of this proposal
10 epochs is between 25-30 days. This means validators will not be eligible for Marinade stake until they have been operating on mainnet-beta for at least a month (vs currently 15 days). It also means a single epoch has a reduced impact on the score.

This will result in a more stable delegation distribution across the majority of validators, with existing emergency unstake rules remaining in place, i.e. for delinquency or of a validator drops out of the top 250 over the 10 epoch average. By raising the entry requirement for new validators this also ensures they have proven their stability and operational ability before receiving Marinade stake. Notably with the current 5 epochs there is a good chance that validators won’t have gone through an upgrade and restart cycle in those 5 epochs, while over 10 epochs this important aspect of running a validator is also factored into their score.

Overall the algo will be less sensitive to smaller performance changes (while still adjusting stake amounts each epoch, i.e. it won’t become completely static) and produce an overall more stable delegation strategy.

Cons of this proposal
It raises the barrier to entry for new validators slightly, as they now must operate a month before being eligible for Marinade stake.

It also poses the potential for too little responsiveness in the case of a sudden performance drop by a validator (though this is countered by existing emergency unstake policy of unstaking large-staked validators who drop out of the top 250 and unstaking delinquent validators).

Conclusion
Changing the marinade delegation strategy to consider a 10 epoch average will produce a more stable and profitable delegation strategy that is less susceptible to sudden/brief performance changes and focuses more on long-term performance and reliability. It creates more stability for validators as well as less unnecessary stake movement and associated lost returns for Marinade.

Please share your thoughts

10 Likes
#2

I agree. Even though I am a new validator, but objectively I think the decision is the right one.
I would also like to emphasize the importance of input from validators to the community, because it’s no secret that people can control 20-30 unnamed validators at a time, and this hurts decentralization. If community input were taken into account when delegating, it would improve decentralization.

1 Like
#3

I’m supportive of a 10 epoch average. I think evening out the stake unstake actions is good long term for mSOL holders and validators.

1 Like
#4

I disagree. While I think long-term it’s not a bad idea, at this point in time I don’t think Solana itself and Marinade are stable enough to introduce a month of lag to parameters adjustment. There are still many challenges ahead, both Marinade and validators should not be in position to wait for 10 epochs for changes to take effect. 5 epochs seems like more reasonable number for now.

I do agree that reducing excessive stake/unstake is important, but that can be addressed differently within the staking bot itself without making the whole system unwieldy.

1 Like
#5

It wouldn’t be a month of lag for any changes. The delegation amounts would still be computed every single epoch, but the up/down movement would be less excessive and there’d be a reduction in “overcorrections”.

Currently a single epoch contributes 20% towards the score, and a valdator could suffer an unexpected restart or other form of delinquency that pushes them out of the top 250. Right now there is even a bug where validators are hanging unexpectedly with no automatic restart, requiring manual intervention to rectify which if not caught quickly and if the operator isn’t currently awake and at their PC can easily cause them excessive downtime which is not necessarily representative of their long term performance. (Ref Github issue)

Using some basic sample data to visualize what I mean:

image
image751×452 7.6 KB

(both graphs use a pattern of 70, 40, 60 30 repeating which is then formed into either a 5 or 10 epoch average and charted, just as a rough indication of how I see this change affecting the overall Marinade algorithm and stake changes)

2 Likes
#6

I am not a validator and I’m not intimately familiar with the current algo, but I generally think this sounds like a good idea.

Seems like the combination of using a 10 epoch average and Cerba’s proposal for DAO voting on validator stake has the potential to greatly increase stability for validators.

1 Like
#7

Although I’m not against a 10 epoch average, imo it is just a bit to early to implement this currently (to soon). Also I’m a bit worried for new validators entering the network maybe feel discouraged by implementing this. On the other side I can see the benefits of a more stabel delegating strategy.
Maybe it’s possible to flag new validator(s) and stake them at an average of 5 epochs and after epoch 15 they will be measured by the normal 10 epoch average?
So maybe we can find a way to still onboard new validators in a way it is now, still need to show good perfromance of course and comply to all prerequisites to get delegation.

1 Like
#8

Good point, there is no reason we can’t have both. I understand @luciotato has commented about this on the validators Discord channel, I’ll let him elaborate if necessary.

@laine It would be up to you if to include this on your final proposal or not, but please do keep it in mind.

#9

Yeah I’m fine with that as long as it isn’t too complex for the Marinade team to implement. How/when/where do I submit a final proposal? (Will wait for more feedback here for a few more days though)

2 Likes
#10

The best way would be to post a new comment on this same thread, with the final description. No need to repeat all your arguments, simply summarize it and add any relevant updates from user comments. (You can see an example of how @Cerba updated his latest proposal here).

You would then create the on-chain proposal in Tribeca, and reference the forum post. You’ll need to create a draft first, and activate it 24 hours later.

My recommendation would be to create the proposal on Sunday so you can activate it on Monday. Engagement seems to drop after Friday, so if you create a proposal mid-way through the week, you may “lose” a few days of engagement as it goes into the weekend, and that may affect its chances of reaching quorum.

5 Likes
#11

Final summary of the proposal I would submit:

Summary: Currently Marinade uses a 5 epoch average in it’s delegation calculation, we propose a change to using a 10 epoch average.

For new validator who have not yet operated for 10 epochs a minimum of 5 epochs should be used and as more epochs become available the number would go up, i.e. a validator that has been active for 7 epochs would have a 7 epoch average used for them.

This helps new validators gain stake without having to wait a full 10 epochs while stabilizing the delegation fluctuations down the line, preventing unnecessary stake and unstake operations etc.

Any further comments or tweaks around the wording here?

#17

Hi Laine,

I understand this will be applied directly, given it’s a low-level change, so no need to make a proposal. Timeline is likely 1-2 weeks, but I’ll let @lj1024 and @repe comment on if that changes.

Cheers!

2 Likes
#18

I am sorry I forgot to respond when we deployed this to production. The 10 epoch average is already in place (for about 2 weeks now).

3 Likes
#19

Thread closed - The suggested change from @laine was implemented as mentioned by @lj1024, about 2 weeks ago. Therefore we consider this discussion and implementation to be concluded for now!