DAO proposal - Delegation strategy update & fee structure changes

Hello chefs, I want to introduce this proposal to discuss together an update to the delegation strategy and the fee structure on Marinade.

What do you propose?

This proposal suggests a number of changes to Marinade’s algorithmic delegation strategy and to the fee structure applied on Marinade. Modifying the fee structure is becoming a necessity given the current market conditions and Marinade’s situation, and it made sense to use this opportunity to rework and improve the delegation strategy overall.

The proposal’s goals are to bring Marinade to a financial equilibrium, improve the delegation strategy flow and change some of the metrics used to calculate score.

This proposal has been designed to maintain the same APY mSOL holders and will mostly affect validators running between 7% and 10% commission.

The main changes in this proposal would include:

  • Raising Marinade’s management fees to 6% (previously 2%, currently 0% with the compensation plan)
  • Modifying the split of the fees from the Unstake liquidity pool between liquidity providers and Marinade from 75%/25% to 50%/50%.
  • Changing the delegation strategy to direct most of the stake towards validators operating at 6% commission or lower.
  • Making the delegation strategy rely less on credits and integrate other scoring metrics.
  • Taking into account some of the changes suggested by validators (stake operations prioritization, redistribution of the overstake in gauges, etc.)
  • Creating a more transparent and easy to understand delegation strategy overall.

What is the rationale behind the proposal?

In order to understand the rationale behind this proposal, it is important to state a few points regarding the general situation for Marinade and the compensation plan currently active. We will then explore the reasoning behind improving the delegation strategy in the same proposal and the rationale behind those improvements.

Why is revisiting the fee structure a necessity?

Marinade operates by taking a small fee on staking rewards, distributed in SOL to stakers. This dependency to SOL price led Marinade to see its revenue divided by more than 6, with SOL dropping in price and TVL stagnating around 7M SOL.

Where Marinade would previously earn enough to cover for all its expenses, its financial balance became negative in February 2022. You can visit the Kitchen Stories from March to June to get more details on the financial overview of Marinade over time, but as of June 30th, 2022 Marinade expenses are around $183k (including $33k paid in MNDE). For July, with the recent changes and reorganization, we estimate the expenses to lower to $113k and $38k paid in MNDE.

On the revenues side, Marinade was earning between $70k and $90k per month with a SOL price around $100, its current TVL and management fees set to 2%. With the unstake compensation plan that started in June and SOL going lower, revenues dropped to $17k for the month of June.

Considering the current treasury status, the outcome of the TEP, and the fact that Marinade was bootstrapped without any initial investment (leading to relying on having a positive balance) and does not have a validator of its own, Marinade will run out of funds in 3 to 5 months in the current situation.

Marinade has already restructured internally to consolidate the team, cut on expenses and survive the bear market (those changes included moving to MNDE compensation for part-time contributors, full-time contributors who weren’t paid on MNDE moving a part of their compensation to MNDE, and a reduction of the number of contributors overall). Unfortunately, these efforts alone won’t suffice, and we need to reconsider the fees (both the compensation plan installed on June, 2 and the previous 2% fees).

Marinade currently operates at 0% fees, due to the compensation plan voted on on-chain by the DAO. This proposal would overrule the compensation plan by modifying the fees to 6%. As of July 17, the compensation plan has been running for 45 days (out of the 90 days planned). With the time needed for this proposal to become an on-chain vote and be executed, we can count 14 to 17 days during which the fees will stay at 0%. In case this proposal is accepted by the DAO, the compensation plan will have stayed active during 59 to 62 days, almost 2/3 of what was planned initially. We believe that the current situation (both for the market and for Marinade) is a valid and necessary reason to end the compensation before the planned date. By our estimation, more than 65% of the SOL has already been redistributed to mSOL holders, given the TVL has grown during these last weeks.

Raising the management fees to 6% would be done in conjunction with a change on the delegation strategy in order to prioritize staking with validators running with lower commissions. This decision would allow mSOL APY to stay the same for users by directing more stake towards validators that are taking a smaller share of the staking rewards.

Another modification in this proposal is the change of the fee share in the Unstake Liquidity pool from a 75/25 split to a 50/50 split between Marinade and liquidity providers. Currently, 75% of the immediate unstake fees are directed towards liquidity providers and 25% to the Marinade treasury. While the APY of this pool is hard to predict as it fully depends on immediate unstake operations, over the last 10 months, the APY for this pool has been 5.50%. As it is also possible to use those LP tokens to mine MNDE, the unstake liquidity pool is currently an attractive liquidity pool that doesn’t benefit mSOL if there’s too much liquidity. We estimate that the optimal target pool size for this pool is 3.5% of the TVL, or 250k SOL currently.

We can also observe that the liquidity in this pool has stayed constant around 500k SOL (worth around $17M which is higher than all mSOL/SOL pools in DeFi), representing 7.1% of the total Marinade TVL. Given that the liquidity in this pool is in SOL, not helping Marinade’s TVL and that there is more than enough available liquidity for the pool to operate, raising the fees taken by Marinade in order to direct some of this liquidity towards mSOL makes sense.

By changing the split to 50%/50%, we expect the Unstake liquidity pool to slowly progress towards this 3.5% of Marinade TVL objective.

The behaviour of liquidity in this pool will be monitored over the next months and if those changes lead to a lack of liquidity in the unstake liquidity pool, another forum proposal can be created to re-discuss and adapt those fees. Nonetheless, the 500k currently sitting in the pool have been extremely sticky those last months, and returns with a 50%/50% share would bring the same returns as currently to liquidity providers as the pool approaches 3.5% of the TVL. For this reason, it is expected that those changes will lead the pool to stabilize around 3.5% of the TVL.

What would those changes bring to the delegation strategy? Why are they needed?

To begin with, as Marinade wants to revisit its fee structure by tweaking some parameters of the delegation strategy, it made sense to combine those changes with improvements that had been identified over the last months. Those changes will also allow to rely less on credits, which has been an increasingly criticized metric as modded nodes appeared over the last months.

First of all, the scoring system of Marinade currently relies heavily on credits. In the last months, we have observed that apart from modded validators skewing the average, most performing validators have similar credits at the end of the epoch. Modded validator clients allowed some validators to score very high with a lot of credits, and it is unclear if this behavior could harm the network if it became the norm (see the discussion started by Shinobi systems). We believe there is a need to rework the delegation strategy and make it rely on another set of metrics, such as data center concentration (for decentralization purposes), commission (as explained above) and overall stability (which would be observed throughout multiple epochs and reward the most stable validators).

Staking priority is also an area where the current strategy can be improved. As of today, Marinade’s algorithm distributes stake to the validators with the best score first, moving then to the second best score, then the third, etc. We realized that it would be beneficial for validators to distribute the stake by prioritizing the validators that are the furthest from their “ideal stake” according to their score.

For example, if a validator has no stake from Marinade but should receive 80k SOL according to its score, the updated strategy would prioritize distributing stake to this validator instead of a validator with a better score that is already staked by Marinade. The gap between the “should_have” stake (according to the delegation strategy for this epoch) and the “current_stake” (by Marinade) would become the way to order staking operations, starting from the highest gap. This value would also be weighted by the number of epochs where a validator has been “missing” some stake from Marinade.

Emergency unstake operations also need to be reworked. Currently, emergency unstake operations need to be manually verified after the scoring process is ran. This delays the scoring that is only validated after this manual verification. One of the goals of this proposal is to make the emergency unstake a separate process, subject to a strict manual approve and separate from the scoring process. This way, scoring would not be blocked by the emergency unstake process and could run in a few minutes and emergency unstake would become a more secure process and be handled on its own.

Another detail in the current delegation strategy is how the overstake from gauges votes is redistributed. If a validator receives too many votes that would lead it to go above 1.5% of the total stake handled by Marinade, the overflow is currently redistributed to all validators. With the planned changes, the SOL that can’t be distributed to the validator would be redistributed in priority to other validators having received votes from the gauges, proportionnaly to the votes they received themselves.

Finally, this proposal also aims to make the delegation strategy more readable and transparent. Marinade would set up ways to gather data about validators performance and stability and store it in a PSQL database. This process would be independent to the scoring process and would just provide a clear overview of the validators that can be consulted and help analyze what is actually happening on-chain. In this database would be stored for each epoch the online status, slots voted, credits earned, etc. for all validators.

Currently, all of this data is taken into account for the score, but each epoch the scoring process runs twice and overwrites the historical data for the epoch on the second run, which is something that we would like to avoid. As part of this new data-gathering process, Marinade would also purchase an IP address database to drop its last dependency (to validators.app), given validators.app is known to sometimes give outdated information on datacenter concentration (as it has been reported on our Discord in some occasions). Those changes will also allow to get a better understanding of the availability of nodes over time, monitor commission changes directly and will solve a small detail of the delegation strategy where validators currently have to avoid upgrading their node when Marinade scoring is running.

In addition to this improvement, Marinade will also work on a validators’ dashboard accessible to everyone, bringing transparency and a better understanding of how the delegation strategy and the stake in Marinade behave. With all those changes, Marinade, validators and stakers will have access to a better overview of the scoring process, the data gathered and will be able to efficiently monitor and analyze what is happening.

What are the implementation details?

The following proposal suggests a number of improvements and changes to the Delegation strategy, coupled with modifications to the fee structure of the mSOL stake pool and of the Marinade Unstake liquidity pool. The rationale behind all those changes is detailed in the section above.

The changes would be deployed in a two-step plan, as follows:

In a first step, fees and validators’ commission changes

  • Marinade management fees would go up from 2% to 6%. As a reminder, this fee is applied after validator’s commission and only on staking rewards. mSOL APY will not be affected by those changes as most of the stake will be redirected to validators running with a lower commission.
  • The maximum commission allowed by the delegation strategy would stay at 10% but a bonus to score would be applied to validators with commissions below it, in order to direct more stake towards lower-commission validators. A score multiplier would be added and correspond to x2 for 9% commission, x3 for 8% commission, x4 for 7% commission and x5 for 6% commission and lower. This bonus wouldn’t be applied to effective votes (coming from the gauges). This way, those changes would not affect the stake currently received from the gauges for anyone.
  • Marinade would also change the fee structure of the Unstake liquidity pool. Currently 25% of the fees are directed to the treasury and 75% are directed towards liquidity providers. After the change, fees would be split 50/50 between Marinade and the liquidity providers.

In a second step, we would deploy a number of improvements to the delegation strategy. The delay of those deliverables is due to the time needed to prepare and integrate the changes to the Delegation strategy.

  • Staking priority

The delegation strategy would no longer order the staking operations by score (currently, the validators with the highest scores get staked until they reach their ideal stake). Instead, staking operation would prioritize the biggest gap between and according to the delegation strategy. These operations could be partial stake in order to reach more validators each epoch.

The difference between “should_have” stake and “current_stake” would also be weighted by the number of epochs during which the validator has been missing stake.

Example: A validator with a “should_have” score of 50k SOL that has been staked 0 SOL for 4 consecutive epochs. If at the end of the fourth epoch, some stake need to be distributed between this validator and a validator missing 50k SOL since 1 epoch, this first validator would be prioritized as the gap would be higher for this first validator than the validator that only waited 1 epoch with 50k stake missing.

  • New data gathering process

A new process, separate from the scoring process, would be implemented to store online status, slots voted, credits earned, etc. periodically to a PSQL database.

This process would allow a better overview of validators’ performance over the epoch as well as separate those data from the score, making them easily accessible and usable. It would also allow to keep a history of those data, whereas score currently overwrites the previous data from the epoch when it runs for the second time.

The last dependency to a third-party service (validators.app, known for sometimes displaying outdated data) affecting the score by allowing to calculate datacenter concentration would also be dropped as Marinade would purchase an IP address database that would be used for this purpose. Maxmind is the solution we are currently currently considering.

The result of these changes will allow a better understanding of nodes availability and performance, as well as allow Marinade to monitor commission changes directly. Another outcome of this change will be that validators will be able to upgrade their node at any time, instead of having to avoid them while the scoring bot was running previously.

  • Scoring process

New metrics would be prioritized in the scoring process over credits. Observing credits and basing the scoring on them led to the validators using a modded node to gain a significant advantage over the others while also skewing the average. The new metrics considered for the scoring process would be:

  • Datacenter concentration
  • Commission
  • Slots skipped (for informational purposes, as we know this metric is less relevant for smaller validators that get less slots over an epoch).
  • Performance over multiple epochs

Another change would affect how stake from the gauges that would go over the 1.5% maximum cap for a validator would be redistributed. While this stake is currently redistributed proportionally to all validators, a change would redirect this “stake overflow” towards other validators that obtained votes in the gauges, proportionally to the votes they received.

  • Validators dashboard & monitoring tools

As part of this proposal, a dashboard accessible to devs, stakers and validators would be created to increase transparency. Marinade would also work on monitoring tools to provide a better overview of the data gathered and of scoring (both publicly and privately, with public dashboards, internal grafana dashboards, automated Discord messages with stats, etc.)

  • Emergency unstake

Emergency unstake would be redesigned as a separate process from scoring, and subject to a strict manual approve for admins. This change would allow the scoring process to run in a few minutes without being blocked by the emergency unstake validation process currently in place, that also requires manual verification but happens at the same time as the scoring process and delays it.

What is the expected positive impact of this change?

This proposal brings a number of changes that should benefit positively Marinade and its users:

  • The fee changes would allow Marinade to go back to being cashflow positive every month, allowing the team to keep on building for the foreseeable future.
  • mSOL users would not see the APY of mSOL change because of this proposal.
  • The unstake liquidity pool would progress towards its optimal state.

While the changes to the delegation strategy are important and will affect validators (especially considering the high percentage of validators running at 10% commission), we expect the changes to have a positive impact in several areas:

  • A better overview of the stake for validators through the dashboard, and of all the validators related data for Marinade in order to keep on iterating on the strategy in the future.
  • A scoring process more reliable and easy to monitor and plan around, that also rewards stability and decentralization before credits
  • A better prioritization of the stake distribution
  • An improvement of the delegation strategy codebase and stability
  • Marinade would not rely anymore on any third party and use objective data coming from the chain or from in-house tools.

Those changes also integrate a number of suggestions offered by validators to Marinade in the last months. We expect them to improve the delegation strategy while staying loyal to Marinade’s values that are decentralization and making Solana the most performant blockchain thanks to its stable validators.

Any other considerations?

It is important to note that a large number of validators run at 10% commission, as it is the maximum commission allowed by the Solana Foundation bootstrapping program. We believe that the Solana network would gain by finding a middle ground on commission allowing validators to earn revenue for their work, while distributing as much value as possible to stakers.

Nonetheless, it is possible that this change will lead Marinade to delegate to a lower number of validators over time, if most of the network stays at 10% commission. This is something that we will need to evaluate going forward. However, it’s important to note that being between 6% and 10% commission will not prevent validators from getting stake from Marinade - but only lead to less stake.

As a reminder, this proposal would overrule the unstake compensation plan. The deployment of those changes would happen in two phases: after a successful DAO vote, the fees and commission changes would be applied immediately after the mandatory delay set on Tribeca. The Marinade team would then start working on all the other planned changes, releasing them when they are ready to be deployed.

Thanks for reading and please comment with your feedback.


I think those changes make sense. One other metric for performance that might be of interest could be block size (I’d go with median block size perhaps, perhaps based on compute per block)… but this is a topic that needs more investigation to see what factors play into this. I do remember seeing some validators in the past with block sizes that were about half the size of others on average for who knows what reason (hardware or other settings?). It is in the interest of the network to spur more investigation and innovation in this area anyway. It’ll happen naturally though once block rewards become more substantial.

For judging credits… yeah this is a tough one. I want to say that we should have this as a factor of some sort but it’s also a mystery as to what affects credits directly outside of mods. My validator is currently ~$1k per month (EPYC 74F3) and last two epochs we were top 100 or so for credits and now this epoch much higher for who knows what reason. I think it is important though that validators are good at restarting and don’t go delinquent often, so credit scores getting lowered by delinquency typically help penalize this unless there is some mod compensation.

I like the idea of slightly stronger weighting for geographic decentralIation but idk how easily this can be spoofed. Ideally it’s not just DC/asn concentration but also city concentration like Stakewiz has on there, and maybe some form of distance from others type weighting that gives further boost to those running in further off places like South America, Africa, etc. It’s expensive to run validators in many countries due to bandwidth costs so it would be cool if there were a way to give those people a boost.

For gauges I personally don’t like just a 1.5% cap. I don’t fully know what the goals are for gauges, but I think the outcome will just be that higher staked, potentially higher commission validators who are better capitalized end up buying up mnde/gauges and become ossified into it and starve out new entrants. They actually have returns so can buy more mnde and keep feeding those back into the gauge pool and toward themselves. I think a better system would be leaving the cap but having something that reduces the power per vote as stake gets higher (some form of this). This will encourage more diversity among gauge participants I’d imagine. I originally purchased 100k MNDE to put forward toward a gauge but the stake impact it now makes isn’t really worth it tbh (I’m a student on a stipend so that much mnde is a lot for me… and it’s a volatile asset so a bit risky). I know a number of other smaller validators who feel the same. I guess the point is also getting other mnde holders to vote for you though… but reducing vote power with stake might also encourage a bit more diversity of voting too.


Great proposal! I learned some things about how delegation currently works just reading it :slight_smile:

I think one thing that might be helpful to add for readers regarding the mSOL APY not changing (please correct me if my understanding is mistaken) – the natural question is where is the extra yield that is going to Marinade coming from, and the answer is validators with 7~10% commissions (implied but never directly pointed out). With this proposal, Marinade would basically become opiniated and consider that commission to be “too high” and would attempt to normalize the yields of validators by controlling how much stake is delegated to them. I think it’s an elegant solution.


Durden’s comment here made me think of something that hadn’t come to mind.

The motivation behind this proposal is to get Marinade to break-even and allow it to continue building. Under which market scenarios would the changes outlined here not be sufficient to achieve that? That is, what breaks the model?

1 Like

If I understand this correctly (@Cerba, please correct me if don’t):

  • Marinade’s income will come from the management fees and increased share of unstake pool; but
  • The mSOL APY will not be affected because Marinade will distribute more stake to validators with lower commission, thus increasing the amount that comes in to distribute before fees.

So it’s not that Marinade is getting yield from validators at 7%-10% - they will merely get a smaller slice of the pie than before.

What @PlayerOfBits describes is accurate, moving the stake towards lower-commission validators will allow Marinade to provide approximately the same APY to mSOL holders as the global APY of Marinade would be going up, as less fees are extracted by the validators commissions.

Regarding @7Layer comments, first of all thanks for the inputs.
Validators’ ability to restart and keep a stable node would have an impact in this new version of the delegation strategy, without relying on credits, which we think is a good way to start extracting ourselves from judging on credits while still valuing uptime and stability

I think your point on weighting certains zones where it’s harder to maintain a node could be a future improvement to reflect on, and maybe we can discuss these potential improvements for the delegation strategy more in detail after this first update, as we see the first results of those improvements and have more data to take educated decisions.

Regarding your suggestions for the gauges, I think they are a bit far from the delegation strategy but it would still be interesting to discuss them, feel free to open a forum discussion to discuss the gauges specifically to gather more feedback on this, it’d be very helpful to collectively reflect around the gauges and how they could be improved.

1 Like

The only scenarios that I think would be leading those changes to not be sufficient would be a drastic fall of Marinade’s TVL, leading the management fees applied on this TVL to bring less revenues than expected, or a SOL token losing a lot of its value over the next months.

Both those scenario could happen but I think it would be counterproductive to start with changes covering for those exceptional scenarios, as another proposal can always come as an addition to this one in case those scenario were to happen.

1 Like

Ad credits: since the credits differ by 1 % among performing validators, to me the order can be a bit random. We still want to take credits into account but e.g. if you have way more credits than what is normal, your score will not go higher.

Ad cap: Do I understand correctly, that you would suggest lowering the cap? And if, how much lower?

1 Like

Hello everyone, is there any questions left around this proposal? As explained in the first post, a part of this plan is relatively time-sensitive so I’d love to get this proposal moving forward.

I’d be happy to hear more feedback and answer any questions left.

1 Like

I think these proposals are very sensible given the current market conditions, as they allow Marinade to stay competitive on APY while ensuring they can retain staff and continue to develop the ecosystem.

Will definitely be interested to see more details on what scoring will look like as vote credits are de-emphasized, but presumably this is something that can continue to be iterated on and optimized over time, after the proposal has been voted on.


Is there any sort of modeling to see how the change to the delegation strategy will impact me as an operator? These changes make sense on paper, but I am curious to see how this will impact my current stake. I am also curious as to how the data center concentration will actually be tallied. Currently my ASN appears to be how that is determined, but my ASN (which is my ISP’s BGP identifier) is HQd out of New Jersey - my node, however, is located in Dallas, TX. This seems like it would lump ALL Equinix nodes into NJ unfairly when they may actually be geographically dispersed.


I think this proposal is well thought out and the reasoning given for the proposed changes makes sense. Just a few questions on potential impact to the validator community:

  • How many of the ~ 455 or so validators that Marinade currently delegates to are at risk of losing stake?

  • What can be done (possibly through public outreach) to encourage these validators to acquire MNDE and participate in gauge voting to make up for any lost stake as a result of the proposed changes to the delegation strategy?

Increased traffic to protocol governance is a somewhat convenient by-product of these changes to the delegation strategy IMO. Although as @7Layer pointed out, it may just lead to more validators hitting the 1.5% cap.

Do we have any idea how many validators might fall under this category (ie already near the 1.5% cap and therefore would not be able to make up the difference via the validator gauges)?

1 Like

Good point - validators who lose stake could still direct some their way using the gauges. However, my first impulse would be to think that Marinade making such a public outreach move, right in the heels of the proposal, could be misinterpreted: I wouldn’t want any affected validator to get the idea that part of the reason behind the change is to drive them to acquire MNDE.

Much as I’d would be happy to get more validators involved in protocol governance, it’s probably best to let that conversation come up organically.

1 Like

Currently, we use unique pair (location and ASN) to calculate the concentration - and we plan to continue doing that (just using a more reliable source of data)

1 Like

@lj1024 answered regarding data center concentration but let me try to answer the first part of your question.

It’s quite hard to predict how this change will affect a specific validator receiving stake today. The first important thing to precise is that gauges will not be affected by those changes, so any stake coming from votes will stay in place no matter what.

Then, if you want to estimate how those changes could affect you directly, it’s possible to use a simple simulation. We created this table to try and help figure things out

This is how stake would be distributed with the new delegation strategy in place, if the current distribution of commissions stay the same for the 450+ validators Marinade stakes to. Currently, the average stake for a 10% commission validator is around 12-13k SOL, and would go down to around 8k SOL.
Nonetheless, just lowering your commission to 9% or 8% would lead to more stake than what you currently have.

If the distribution of commission change drastically and a lot of validators move to 9% commission, we can see that 10% commission validators would lose a bit more stake.

This table is merely a simplification, as other variables will come into play (stability over epochs, location, etc.) but we can observe that 10% validators will lose a little stake if not many validators move to lower commission, and this loss will become larger as more validators move towards lower commission.
Feel free to make a copy of the spreadsheet and give it a look to understand how it would work in this simplified scenario.

This helps us answer @dobby’s question too, currently we have about 400 validators out of 455 that run with a commission higher to 6%, so they would technically “lose” stake if we only consider this change. Nonetheless, since the delegation strategy will rely on “stability over epochs” and “commission” and not credits, this will lead a part of those validators that didn’t score high in credits but run reliable validators to slowly pick up more and more stake, reaching a higher stake than what they had before.

It’s quite hard to predict how all the changes will impact the current situation for sure, but those changes should not affect the total number of validators reached by the strategy, and 10% commission validators will not lose all their stake on day 1, but will have to optimize for the new metrics or lower their commission to benefit fully from Marinade at the same level as they are now.

Regarding the validators already maxed out (or close to) in the gauges, only 1 validator is already at this cap. For others, it will be possible to use MNDE to somehow compensate what they will lose by staying at 10% commission. As PlayerOfBits said, this is not the objective of this proposal and it will be a choice for validators to analyze the gauges situation and see for themselves if it’s worth obtaining stake through this mean.

I think that putting out those changes and having accessible data about the delegation strategy will allow us to reflect on it again in a few months, and see the big picture of the delegation strategy, how gauges play into them, and what parameters could be improved in order to make it even better. I still think we have to start somewhere and renewing the delegation strategy and enabling this data collection will be a huge start.

If you have any more questions, please shoot and we’ll do our best to bring light on them.


Well, I’m still focused on how much weight is put onto location. How are you able to determine the data center location, since the ASN is not the data center location, but rather just the ISP’s BGP identifier and could encompass many data centers (which is the case for Packet aka Equinix - it has one ASN for all of USA)?

1 Like

Every validator has a public IP, we use geolocation as well as ASN. @knoxtrades


That’s what I was looking for :slight_smile: Thanks!


Thanks for answering my questions @Cerba @PlayerOfBits! I think I have a much better understanding now.

1 Like

Makes all perfect sense to me, can’t say much about validators and LP perspective though, they should provide the input here.

Without having done much math, the Only thing I’m wondering is if it’s really the better approach to split gauge stake from overvoted validators only between validators that already have gauge votes or the current distribution to all validators might be the better way?
Maybe you have some numbers/thoughts why this is the better way, already @Cerba ?