[mDAO Proposal] Delegation Strategy Revamp

[lj1024]

I ask MNDE holders for support of my proposal that changes our Delegation Strategy so that it becomes transparent, iterable and simple (no change of the Marinade stake pool contract needed).

What do you propose?

• Replace the scoring software of the Delegation Strategy:
• Formalize the algorithmic part of the Delegation Strategy and update/simplify overall rules and parameters
  • Liquid Self-stake part of our pool:
    • Open it to all mSOL holders
    • Allow mSOL holders to direct stake to their validator of preference
    • The percentage of the stake allocated to mSOL voting will be set at 20%
    • User-selected validator must:
      • Minimum amount of non-Marinade stake on the validator in all of the past 10 epochs: 100 SOL
      • Maximum observed commission in all of the past 10 epochs ≤ 10 %
      • Not blacklisted for running vote-lagging upgrades, commission rugs
      • Running one of the version from the list specified by Marinade team (changes in the list to be announced in discord - we will mostly follow Solana Foundation’s Delegation Program’s guidelines)
  • MNDE gauges controlled part of our pool:
    • Gauges control 20 % of the stake (unchanged)
    • Only MNDE votes on eligible validators count:
      • Minimum amount of non-Marinade stake on the validator in all of the past 10 epochs: 100 SOL
      • Maximum observed commission in all of the past 10 epochs ≤ 10 %
      • Must be within 75th percentile of the score assigned by the algorithmic part of the Delegation Strategy
      • Not blacklisted for running vote-lagging upgrades, commission rugs
      • Running one of the version from the list specified by Marinade team (changes in the list to be announced in discord - we will mostly follow Solana Foundation’s Delegation Program’s guidelines)
    • No validator can receive more than 10 % of the TVL governed directly by MNDE (So the cap in SOL at the time of writing this proposal is roughly 668 k * 0.1 ~ 66.8 k SOL)
    • If there is an overflow of MNDE votes for an eligible validator, the overflow is split proportionally between eligible validators proportionally based on the received votes.
    • If there is fewer than 10 eligible validators voted for (e.g. 8 validators, each reaching the cap), the overflow goes towards algorithmic staking.
  • Algorithmic stake

    • Only eligible validators can receive stake:

      • Minimum amount of non-Marinade stake on the validator in the past 10 epochs: 1000 SOL
      • Maximum observed commission in the past 10 epochs ≤ 10 %
      • Not blacklisted for running vote-lagging upgrades, commission rugs
      • Running one of the version from the list specified by Marinade team (changes in the list to be announced in discord - we will mostly follow Solana Foundation’s Delegation Program’s guidelines)

    • Top 100 validators who are eligible for Algorithmic stake by Marinade receive stake proportionally to the score assigned.

    • The score is calculated for each validator as a weighted (w) average of normalized components (c):
      

    • Min-max normalization is applied on each of the components and each component then becomes a number between 0 and 1 ⇒ the overall score is also a number between 0 - 1 (We might multiply that by 10 or 100 for UI purposes). This assures each component has the same magnitude and can be affected by the set of weights in a predictable way.

    • The proposed weights applied to data between epochs 396 and 405 give similar estimated results in regards to mSOL performance (less than 0.5 % difference ⇒ negligible) and similar (or arguably better results) for decentralization support within the ecosystem ⇒ this makes it in my opinion a good starting point as the outcome for mSOL holders remains the same and we can easily build/explore on top of this simple and transparent model.

Weight	Component
10	Commission-adjusted credits averaged over the past 10 epochs
2	Stake concentration by data center averaged over the past 10 epochs
1	Skip rate averaged over the past 10 epochs; If a validator at any given epoch had fewer than 200 leader slots, minimum of their skip rate and cluster stake-weighted skip rate is used instead.

What is the rationale behind the proposal?

Our Delegation Strategy (DS) began as a fork of https://github.com/solana-foundation/stake-o-matic by Solana Labs until it reached its current state and it could use some improvements.

What is wrong with the current DS?

• It is a single piece of software that combines data collection, many data transformations and scoring; it has acquired lots of technical debt over time ⇒ difficult to navigate even for us, who develop/maintain the system.
• Its output is stored in https://github.com/marinade-finance/staking-status as text files = low transparency
• the scoring is a bit too complex and difficult to understand ⇒ low transparency
• It is not possible to replicate the scoring output that happened in the past (because data collection and scoring are done at the same time) ⇒ low transparency
• It is difficult for validators to understand what to change to receive the stake from Marinade ⇒ low transparency
• When MNDE gauges overflow the cap per validator, the overflow does not necessarily go towards other MNDE voted validators, which results in MNDE controlling less stake ⇒ confusing behavior
• The scoring DB is stored as sqlite DB on github, where we are hitting GH limits of 100 MB per file ⇒ technical issues
• It does not understand commission rugs automatically.
• We currently stake with the same number of validators as we did when the SOL price was $ 200 ⇒ Now most of the validators that we stake with receive less than 10k SOL and that is too little to make a difference.

How the planned changes improve DS:

• The data collection is split from the scoring (We already have a new system for data collection we use for our Validator dashboards)
  • The scoring itself then becomes: CSV file with input, a short R script producing scores and interesting graphs
  • The formula in the R script and its parameters can be easily iterated over ⇒ this leads to great transparency as any past scoring result can be easily verified and compared with alternative parameters
• The output of the scoring will be available as:
  • A separate section on each of the validator’s detail in our dashboards
  • An overall report with simple steps on how to reproduce the results and play with them a bit
• Stake distributed by MNDE gauges will be in usual cases spread only over validators who have votes
• It is easy to make it understand commission rugs

What is the expected positive impact of this change?

While the performance of the algorithmic staking algorithm remains the same, it is much easier to iterate over and is much more transparent. E.g. if we decide to take into account MEV rewards from Jito, mTransaction, Solana-MEV or Firedancer it is easy to model the change and immediately see the impact. (We already collect MEV rewards for each Jito validator but since the rewards are very small as of now and impact even on Jito’s own APY is less than 0.1% (E.g. APY could change from 7 % to 7.007 %) we do not take MEV rewards into account for our own staking yet)

Algorithmic stake distribution should remain similar in nature:

You can compare with e.g. stake distribution within the whole Solana cluster (which is quite alarming):

R script to compute scores yourself

validators <- read.csv("403-412.csv")

validators$normalized_dc_concentration <- normalize(1 - validators$avg_dc_concentration)
validators$normalized_grace_skip_rate <- normalize(1 - validators$avg_grace_skip_rate)
validators$normalized_adjusted_credits <- normalize(validators$avg_adjusted_credits)

MARINADE_VALIDATORS_COUNT <- 100
WEIGHT_ADJUSTED_CREDITS <- 10
WEIGHT_GRACE_SKIP_RATE <- 1
WEIGHT_DC_CONCENTRATION <- 2

validators$score <- (0
  + validators$normalized_dc_concentration * WEIGHT_DC_CONCENTRATION
  + validators$normalized_grace_skip_rate * WEIGHT_GRACE_SKIP_RATE
  + validators$normalized_adjusted_credits * WEIGHT_ADJUSTED_CREDITS
) / (WEIGHT_ADJUSTED_CREDITS + WEIGHT_GRACE_SKIP_RATE + WEIGHT_DC_CONCENTRATION)

validators$eligible_algo_stake <- TRUE
validators$eligible_algo_stake[validators$max_commission > 10] = FALSE
validators$eligible_algo_stake[validators$minimum_stake < 1000] = FALSE

sorted_validators[sorted_validators$eligible_algo_stake == TRUE,]

validators$rank <- rank(-validators$score)
sorted_validators <- validators[order(validators$rank),]
marinade_validators = head(sorted_validators[sorted_validators$eligible_algo_stake == TRUE,], MARINADE_VALIDATORS_COUNT)

403-412.csv

Disclaimer: The snapshot has been a bit simplified: e.g. some of the suspected vote laggers are already removed. In the production code this will be done properly, so after each scoring run, the snapshot will be available in full.

[7Layer]

My first suggestion is just that I think the gauge voting should be weighted similarly to the algorithmic strategy. I.e. a validator might have 1 million mnde of votes but depending on its scoring, the impact of that 1 million mnde in terms of how much sol is directed toward the validator can change. I think it’s ok to be more lenient with the 1:1 msol validator of choice, but since a certain $ worth of mnde can direct much more sol in $ terms, I think it’s better that criteria are applied so that better capitalized validators cant just act as a parasite and direct stake at their validator regardless of performance. Maybe the 75th percentile system is good enough though…

Second suggestion is that eventually not only DC’s are considered but more geographically far-ranging categories (i.e. countries or continents). Regulations are different across countries so it’s worth thinking about decentralization in those terms, and also network distribution in the case of country/continent spread. Egress costs get expensive outside of the US and EU. What I think is great about the Solana Foundation Delegation Program is that you see validators located in further off, unique regions supported (many being in central or eastern Russia).

As Laine and I brought up before, if you want to include skip rate I think it would be better to take a window of epochs to get a larger sample size. It may be that some validators will only have enough slots to be worth counting after they are delegated from Marinade. What you could do is start tracking their skip rate once they receive their Marinade delegation, and if the performance is too poor you could have a # of epochs where they lose their marinade stake and can’t get it back even if their other criteria make them eligible again. A # of epochs should be enough time for them to make whatever adjustments they need to.

Outside of that I think it’s worth starting to brainstorm in the background how delegation might work later on when Solana introduces slashing or other penalties. I imagine it’ll make delegation to validators less free-flowing given the risks. Might want to start thinking about validator insurance, harder selection criteria, etc.

[lj1024]

Thanks for sharing the opinions!

Ad your first suggestion: This is a very interesting idea but changing vote weights is a tricky topic and we are not sure yet whether it is going to be addressed e.g. by quadratic voting when applying the votes or later in here. Let’s isolate further changes to MNDE gauges. I am also thinking that maybe MNDE gauges eligibility could be changed e.g. to be at least XX % of the score of the last scored validator that received algo. stake. Percentile is a tricky thing to set as what if 50 % validators have almost identical performance (as is the case now.) WDYT about this?

Ad your seconds suggestion (geo decentralization): Yes, this is also quite important and I duly note the feedback, but I would put this for the next iteration. It will be important to do further analysis on what geographical - or even geopolitical distribution means. (E.g. should we consider EU a single entity because of regulations - probably yes? What about staking in geographical areas that participate in an armed conflict and it is more likely that they are going to suffer e.g. large scale power outages? etc) - but this will be a great discussion and if can quantify this metric in the future, we will be able to put it easily to the proposed model.

Ad skip rate: The proposal state that the skip rate used is going to be averaged over 10 epochs (seems like quite a long window); Also for smaller validators the better (for them) from cluster average skip rate and their own skip rate is used. As this is averaged over several epochs, I do not think we need additional set of rules for losing stake and not being able to recover it for x epochs. Afterall, redelegate instruction is coming and we have another project already scoped and planned to implement it, so we can benefit from it.

Ad slashing: Oh yeah, we are going to engage in these discussions - afterall slashing is a feature that truly unlocks the potential of staking pools (and especially with redelegate instruction it gets quite easy for us to react in time)

[rnyhse.sol]

Well all of this make perfect sense, thank you lj1024. Also I assume you still inted to exclude the superminority since it’s not explicitly mentioned?

Do I get it right that the algo is intended to not stake to more than 100 validators?

To be honest, and mainly based on my gut feeling, less on data and facts:
While I understand the argument that the stake would be less relevant the more validators receive a piece, I feel it hurts the decentralization promise of Marinade.
Rather staking less useful amounts to a higher number of validators to support them somehow suits my understanding of Marinades mission much more, than helping “only” 100 validators to eventually break even.
I’d be interested to see who those 100 validators would be as of now and get input by other validators on this.
Supporting 450 validators at least to me is a very strong selling point in conjunction with competetive APY.
When we talk about 100 validators one might as well go to Jito with higher APY or SolBlaze which also supports decentralization well.

[lj1024]

Apologies, I made a mistake in the R-script (that resulted in incorrect picking of validators). The scipt is fixed, input data in the proposal is updated to the latest 10 epochs and contains suggested changes (e.g. skip rate is calculated as min(cluster skip rate, skip rate) for validators with < 200 blocks in an epoch). The dencentralization graph is updated accordingly (previous claims about similar decentralization still stand). The overall validator stake weighted performance is pretty much the same (it has increased within statistical error).

In discord some people mentioned that they do not want to run R script themselves, let me share the results here:
Who would receive stake: marinade-validators.csv
All validators sorted by the score (apart from first estimate of vote laggers who are not even in the source file): sorted-validators.csv

Again, based on the feedback in discord: Maybe we could consider MNDE eligibility to not be 75 percentile but rather having a score at least e.g. 0.9 of the worst-scored validator in the set of the validators selected by the algo (that would currently result in validator having to be roughly top 800 by our score and would therefore make it easier)

[lj1024]

Thanks for a reaction to the proposal.

We dropped the out-of-superminority requirement. However, in the set chosen by the algo, none of the validators is in the superminority (at least now). Arguably, it may be more difficult to have a good voting performance if you are a large validator e.g. because of more network traffic. Also, superminority is mostly in Amazon, Packet and Teraswitch - this makes them quite concentrated and the algorithm penalizes that. Futhermore, if Marinade wants to grow and obtain more stake, it is inevitable that we will have to stake with some validators in the superminority, eventually (Good validators are supposed to grow and get new stake, why should we abandon them? E.g. Ben from Cogent Crypto).

I think gut feeling is important and not everything has to be about data, so no worries! E.g. We have MNDE gauges, that bring our APY down a bit at the moment.

helping “only” 100 validators to eventually break even

It is not really about helping them break even anymore, we simply do not have enough stake to do that with current SOL prices. If our TVL grows ($ value either from sheer amount of SOL and/or $ value from the SOL price), there is no reason not to increase the number again.

Jito may have slightly better APY, but please, do not believe the > 8 % they show on their website as that is a complete nonsense (as I explained some time ago on twitter in a “small” rant: https://twitter.com/__lj1024/status/1614645280921759745). APY is a terrible metric but we can at least compare the xSOL growth:
This is how price of the tokens for different protocols changed at the end of the previous epoch:

Jito	Lido	Marinade
1.000439335	1.000432355	1.000430845
This means that if you stake 1000 SOL with Marinade and 1000 SOL with Jito (and use their own APY formula), over the course of a full year, just based on that 1 epoch, you will get about 2 SOL more (out of 80) with Jito. Based on data from the next epoch, it may well be the other way around. (Did not check SolBlaze, so I do not know the situation there)

Another small point that goes towards our responsibility for APY is that we expect a small bump there as a user of the liquid self-stake is doing a significant upgrade of their HW and we have 1.2 M SOL staked with them - that means they should get as good a performance as validators chosen by the algo.

And finally, let me give you another argument for the reduction to 100: If the scoring is more competitive and 1) it is clear to validators where they are lacking (transparency of the formula + upgrades of our dashboard); 2) it is simple to “get points” by moving out of Teraswitch; this might lead to a general improvement of the network.

Halfway through this response I felt it may get a bit long, hope you made it through and that it brought you some value.

[rnyhse.sol]

Thanks a lot LJ, very good points, lot of value .
I agree with your arguments, and if the limitation is simply owed to the lack of TVL and can be increased, when sensible, later I think it’s fine at least for me, for now.
Just thinking couldn’t that be part of the strategy at a later point? But I think I already see problems in this… like unhappy validators for getting staked and unstaked by Marinade due to TVL/price volatility.

Another gut feeling of mine - sorry -: though on one side I’d happily see validators like Ben, Laine, and co supported via Marinade stake, that also means that other validators that didn’t break even may loose Marinade stake against “big”, well performing validators, no?
But again I see the challenge / limits of the delegation strategy on that.

[lj1024]

TVL x validator count could be a part of DS - as always there is plenty to be improved and in the end, anyone can make a proposal how exactly to do it. Maybe some thresholds could be applied so it is not that volatile - after redelegation is done and can be used on Solana, this also becomes a different story (we will no longer lose up to 4 % of our staking rewards constantly re-balancing the stakes).

Ah, don’t apologize for feelings, just because something cannot be easily quantified does not mean it is not valid or relevant.

What you say about losing stake to bigger, well performing validators is true. At the same time validators deserve to be rewarded for their hard-work. It is no easy task to make this your daily job. And if you are that capable? Staking with you makes a lot of sense as there is a huge level of trust in your capabilities (and uptime of the validator) based on your historical record. That will be even more true as we go on - when slashing is here, we all will have to think twice where to put that trust (= stake).

In my opinion, seasoned and trusted validators will be always the backbone of Solana. I welcome newcomers but admittedly, it is going to be more and more difficult for them to establish the necessary level of trust to receive lots of stake.

[lj1024]

The proposal will contain the following change (based on feedback in discord):

MNDE eligibility to not be 75 percentile but rather having a score of at least 90 % of the worst-scored validator in the set of the validators selected by the algo part of the DS.

[luciotato]

I propose to make it a little more flexible:

where it says:

@lj1024

the percentage of the stake allocated to mSOL voting will be set at 20%

I believe you should leave some room for configuration here, it should read:
“the percentage of the stake allocated to mSOL voting can be configured from 15% to 40% depending on mSOL holders participation”

[lj1024]

I respectfully disagree. A fixed percentage range for stake allocation provides clarity and stability, whereas allowing for variable configuration could lead to confusion and uncertainty. Let’s keep a specific number and evaluate if another value should be used (or how to define it based on mSOL holders participation) later, when we have data from actual usage and see how this product affects our metrics (TVL, APY, decentralization, …).

[Cerba]

I fully support this delegation strategy revamp. Thanks, LJ for the detailed proposal and the R script allowing us to compute what the score would look like with those changes in place, I think it’s really helpful.

I tend to agree with @7Layer on the MNDE gauges being weighted according to their score, which makes it “more expensive” to support a low-score validator with MNDE, but I also agree that those changes should be part of another proposal and isolated so we can discuss them more in depth.

[defivan]

@lj1024

Allow mSOL holders to direct stake to their validator of preference

this feature will benefit the stakers a bit more, and thats great. giving one more opportunity of preference to the user is crucial in developing a decentralised community and supporters behind of it. for sure, it will attract more mSol stakers to participate in direct staking and more importantly will add more locked liquidity to Solana as overall

[lj1024]

Summing up the proposal with all the added changes and with phases

The version in this post is what will be voted on.

Phases

1. Update performance based staking eligibility rules and formula, update MNDE gauges calculation and eligibility rules
2. Open part of TVL to mSOL holders (mSOL gauges)
3. Move partners from self-stake product to mSOL gauges and close the self-stake product

What do you propose?

• Replace the scoring software of the Delegation Strategy:
• Formalize the algorithmic part of the Delegation Strategy and update/simplify overall rules and parameters
  • Liquid Self-stake part of our pool:
    • Open it to all mSOL holders
    • Allow mSOL holders to direct stake to their validator of preference
    • The percentage of the stake allocated to mSOL voting will be set at 20%
    • User-selected validator must:
      • Minimum amount of non-Marinade stake on the validator in all of the past 10 epochs: 100 SOL
      • Maximum observed commission in all of the past 10 epochs ≤ 10 %
      • Not blacklisted for running vote-lagging upgrades, commission rugs
      • Running one of the version from the list specified by Marinade team (changes in the list to be announced in discord - we will mostly follow Solana Foundation’s Delegation Program’s guidelines)
  • MNDE gauges controlled part of our pool:
    • Gauges control 20 % of the stake (unchanged)
    • Only MNDE votes on eligible validators count:
      • Minimum amount of non-Marinade stake on the validator in all of the past 10 epochs: 100 SOL
      • Maximum observed commission in all of the past 10 epochs ≤ 10 %
      • Must have a score of at least 90 % of the worst-scored validator in the set of the validators selected by the algo part of the DS.
      • Not blacklisted for running vote-lagging upgrades, commission rugs
      • Running one of the version from the list specified by Marinade team (changes in the list to be announced in discord - we will mostly follow Solana Foundation’s Delegation Program’s guidelines)
    • No validator can receive more than 10 % of the TVL governed directly by MNDE.
    • If there is an overflow of MNDE votes for an eligible validator, the overflow is split between eligible validators proportionally based on the received votes.
    • If there is fewer than 10 eligible validators voted for (e.g. 8 validators, each reaching the cap), the overflow goes towards algorithmic staking.
  • Algorithmic stake

    • Only eligible validators can receive stake:

      • Minimum amount of non-Marinade stake on the validator in the past 10 epochs: 1000 SOL
      • Maximum observed commission in the past 10 epochs ≤ 10 %
      • Not blacklisted for running vote-lagging upgrades, commission rugs
      • Running one of the version from the list specified by Marinade team (changes in the list to be announced in discord - we will mostly follow Solana Foundation’s Delegation Program’s guidelines)

    • Top 100 validators who are eligible for Algorithmic stake by Marinade receive stake proportionally to the score assigned.

    • The score is calculated for each validator as a weighted (w) average of normalized components (c):
      

    • Min-max normalization is applied on each of the components and each component then becomes a number between 0 and 1 ⇒ the overall score is also a number between 0 - 1 (We might multiply that by 10 or 100 for UI purposes). This assures each component has the same magnitude and can be affected by the set of weights in a predictable way.

Weight	Component
10	Commission-adjusted credits averaged over the past 10 epochs
2	Stake concentration by data center averaged over the past 10 epochs
1	Skip rate averaged over the past 10 epochs; If a validator at any given epoch had fewer than 200 leader slots, minimum of their skip rate and cluster stake-weighted skip rate is used instead.

[lj1024]

Voting on the proposal is here: Tribeca - Solana Governance By DAOs, For DAOs

[btuck]

This proposal has officially passed the mDAO vote and will be installed around the beginning of April

View here: Tribeca - Solana Governance By DAOs, For DAOs