Proposal for an In-Protocol Distribution of Block Rewards to Stakers

Governance
1

Summary

A new mechanism is proposed to allow validators to set a block reward commission and share part of their block revenue with their delegators and to receive their own block rewards to an account of their choice.

Commission rates from validator vote accounts will be used by the protocol to calculate post-commission rewards that will be automatically distributed to delegated stake accounts at the end of each epoch

Block rewards after commission will be distributed to an account of the validators choosing. The default will be the validator identity account. If a validator takes no action then block rewards will continue go to the Identity account.

Motivation

Delegated stake directly increases the number of blocks that a validator is allocated in an epoch leader schedule but the core protocol doesn’t support diverting any of that extra revenue to stake delegators.

Due to the lack of core protocol support for distributing block revenue to stakers, validators have developed their own solutions which are not enforced by the core protocol. For example, some validators use NFTs or LSTs to distribute some amount of their block revenue, however this requires trust in the validator’s honesty and accuracy, while making it difficult to surface this information and accurately track resulting yields.

With the option to specify a collector account validators can improve operational security by diverting their revenue into a multisig or cold wallet rather than the identity hot wallet that sits on their servers.

Additionally the ability to specify arbitrary collector accounts, including PDAs, means that additional custom functionality and distribution mechanisms can be built on top of this, such as auto-conversion to USDC or a validator LST, or deployment to Defi.

Changes in the spirit of this proposal

Should any changes be necessary to ensure a safe and functioning implementation, such changes will be permitted without further governance requirements so long as the spirit of the proposal is maintained.

Voting Process

The voting process will proceed as follows:

Discussion period: Validators are encouraged to participate in discussions to address any concerns.

Stake weight collection period: Stake weights will be captured and published for voting. Validators will have the opportunity to verify these weights.

Vote token distribution will require validators to utilize the adapted Jito Merkle Distributor tool (available at GitHub - laine-sa/solgov-distributor: A merkle-based token distributor for the Solana network that allows distributing a combination of unlocked and linearly unlocked tokens.) to claim the vote tokens corresponding to their stake weights.

Three token destination accounts will be created for voting choices: Yes, No, and Abstain.

Validators will have a designated period to vote by sending their tokens to the respective addresses.

After the voting period, if the sum of Yes votes is equal to or greater than 2/3 of the total sum of Yes + No votes, the proposal will pass.

The proposal has a quorum threshold of 33%, abstentions count towards the quorum.

All announcements regarding this process will be made in the Governance category of the Solana Developer Forums.

Stake weights and a tally script will be available at solgov-distributor/votes at master ¡ laine-sa/solgov-distributor ¡ GitHub

Timeline

Epoch 747 - 751: Discussion period

Epoch 752: Stake weights captured and published, discussion/confirmation of stake weights

Epochs 753 - 755: Voting tokens available to claim, voting completes at the end of epoch 755

Discussion

Active participation in discussions about this proposal is crucial. Discussions may also take place on the Solana Developer Forums or on Discord Governance channel. It’s encouraged to consolidate discussions to ensure broad participation and minimize redundancy.

References

1 Like
3

This change will affect small validators greatly. They will be ineviteably forced by the stake pools to set their share of block rewards to 0 level. The only thing that will be left - side deals like sandwiching.

At the same time this change does not affect big private validators. They even still charge commission for inflation rewards with no outflow of stake noticed.

So the outcome for the network will be net bad:

  • Stakers possibly get +1% APY max. Which IMO does not matter considering the volatility of an asset.
  • No additional competition between stake pools as they will all have the same “selling point”. Nothing special to drive a lot of retail stake there really.
  • No effect on big private validators as they have no incentive to share block rewards
  • Great decrease in earnings for the validators depending on stake pools. This will cause decrease of number of those validators and their qualuity.
6 Likes
4

This proposal will no doubtably deter the casual developers / independent technologists / students / enthusiasts etc. from making the jump into Solana Validation (which has a fairly high bar as it stands) and becoming part of the active independent group of validators that run Solana. It will also suffocate existing validators and reduce the validator group to small subset of what it is.

Validator earnings for an independent who is trying to compete for stake through offering a competitive APY will have no sustainable way of surviving if they are forced to give away even their block rewards from the small amount of stake they obtain. (This leaves no revenue stream other than offering their mempool out to sandwiches)

New / current Validators already have large running costs. And so making block rewards yet another race to zero competitive game will strangle the network and deter interested small participants who will simply invest their time and money into alternative networks. With them go their social networks too.

I believe we need every validator we can get, so VOTE NO to this proposal, and so keep and encourage the vitality of Solana!

9 Likes
5

The only goal of this proposal is to make some validators happy with legal implications of holding rewards of stakers for a moment before sending them after every epoch. They never had issues before while holding 50% of block rewards in the past though.

But the consequences of it will be the end of hundreds or even thousands of small validators as they will lose the last source of income they currently have.

Stake continues going to whales instead of small validators or pools and there are just a feel pools that currently support a great number of validators in a fair way. And these require all validators to be running on maximum commission of ZERO. If this proposal gets approved, pools will squeeze validators to the maximum and push them to negative income, while pools still enjoy a healthy 5% fee or more.

This SIMD only came because of SIMD-96 was approved when most validators voted yes to get block rewards that were being burnt! But now, with SIMD-123 we mostly regret this decision as if this gets approved we will not just lose this 50%, but possibly even more.

The approval of this SIMD-123 will cause great loss to the Solana community and even more centralization of stake and this is one of the reasons big validators (the usual influencers) are keen on getting this approved.

Please vote NO to this SIMD and keep us alive, everyone deserves to survive.

8 Likes
6

I do think this would be a nice feature, but also agree that it will completely wipe out the independent validator community. If this goes through, I would bet on <300 total validators in the entire Solana ecosystem come the next bear market. Solana already struggles with a decentralization narrative given the performance requirement of machines, and this will make it worse.

Maybe that’s ok and no one actually cares about decentralization that much, but seems like the risk is pretty high for a pretty small benefit to stakers.

5 Likes
7

Hello everyone!

We would like to emphasize our support for the concerns surrounding this proposal, particularly its potential impact on the validator ecosystem. Implementing this proposal could result in the reduction of many small validators, significantly decreasing the total number of active validators on the network.

This reduction could, in turn, result in a higher degree of centralization. Such an outcome would contradict Solana’s broader vision of fostering a decentralized and resilient blockchain ecosystem.

Decentralization is a fundamental principle that ensures the security, censorship resistance, and long-term sustainability of the network. We believe it is crucial to carefully consider the implications of this proposal to avoid unintended consequences that may hinder Solana’s growth and decentralization efforts.

7 Likes
8

We will vote NO!

As most of other validators already commented this is not going to help the small validators. Currently only 150/1400 validators have more than 300k stake, which means that around 90% are small validators relying on stake pools and SFDP and they will be impacted negatively by this proposal if it goes live.

It is already hard to survive, very competive stake pools and more and more expensive the hardware.

4 Likes
9

While the intent of this SIMD is good, it would be naĂŻve to overlook the potential side effects.

Several features of this SIMD align with practices I already follow manually, and I support the automation and transparency of that portion. The ability to programmatically direct 5% of block rewards to a collector account would greatly improve our transparency. We donate to animal welfare every month, and this is a manual process that could be improved with this SIMD. Additionally, there’s currently little traceability regarding where the funds ultimately go. This SIMD would allow us to build a front-end to display this in a provable and transparent way.

There are other pros mentioned that I won’t dive into for the sake of brevity, but I want to emphasize that I understand and appreciate the motives behind this feature.

Now for the downside. As others have pointed out, this change gives sandwichers and large validators a clear advantage. It also enables a framework for stake pools to squeeze validators harder. While I agree that relying on stake pools is not a sustainable business model, they nonetheless do exist, and we must acknowledge the impact on small/medium-sized validators. I also anticipate that the barrier to entry will rise with this change. It can be tough to break even already without putting block rewards on the table. I guess break even has changed drastically since I last looked so forget that point.

2 Likes
10

I oppose this proposal.
Currently, many small-scale validators are operating their validator servers at the break-even point and are struggling to cover monthly server costs.

If SIMD-123 is passed, as was the case with JITO MEV, it will inevitably be added to the SFDP requirements. In that scenario, I believe that any validators other than the major ones will not be able to survive.

Furthermore, since the same functionality can be achieved with sanctum LST and the Jito tip router, there are no benefits other than from a legal standpoint. Wouldn’t the side effects of SIMD-123 be too great?

11

It is obvious to all validators that this proposal is directed against small and medium-sized validators. The strategies for delegating stakes pools now look like this, so that a stakes gender-dependent validator earns as little as possible with a 0% commission. And they want to take away this earnings from him in the form of priority fees. And it doesn’t seem to matter at all how small and medium-sized validators vote for this proposal, as long as the interest of large validators is obvious. Here are statistics on the number of validators and their total steak in this range.

100 - 100 000 SOL - 903 validators, total stake - 28 073 960 SOL
100 001 - 300 000 SOL - 288 validators, total stake - 53 675 219 SOL
300 001 - 1 000 000 SOL - 67 validators, total stake - 35 556 740 SOL
1 000 000+ SOL - 84 validators, total stake - 266 573 515 SOL

If the sum of Yes votes is equal to or greater than 2/3 of the total sum of Yes + No votes, the proposal will pass.
Let’s assume that small and medium-sized validators reasonably vote against according to the size of their stake. That is, 1191 validators disagree with this proposal. But their total stake is less than 82 million SOL. While 151 validators have a total stake of over 300 million SOL. There is no scenario where small and medium validators could reject this proposal if a group of large validators disagrees with their opinion.

1 Like
12

The proposal may seem appealing on the surface, but in reality, it poses a serious threat to the sustainability of smaller validators and the health of Solana’s validator ecosystem.

Right now, validators already face pressure to lower commission rates to attract stake. Many small validators set their commissions to 0% to stay competitive. If this proposal passes, it will push them to give up 100% of their block production rewards as well, making it impossible to sustain operations.

key risks:

  • Race to 0% commission on all income – Small validators will have no choice but to forgo earnings from block production just to compete, worsening centralization risks.
  • Unfair advantage for larger validators – Those with deep pockets can afford to operate at lower margins, further concentrating stake among the biggest players.
  • Long-term validator instability – Without sustainable rewards, many small validators will shut down, reducing network resilience.
  • While the proposal brings interesting composability and functionality, the cost is too high.

Solana needs a robust, decentralized validator set – not an incentive structure that forces validators to operate at unsustainable margins.

Vote NO on this proposal and protect the future of decentralization on Solana.

3 Likes
13

I’m small validator with just SFDP stake. This proposal will kill me.

14

I completely sympathize with the concerns raised in this forum. They are all legitimate concerns. Greasing the wheels on sharing block rewards will serve to increase the competitiveness on block rewards sharing which will make it harder or impossible for small validators to break even and reduce the profitability of all but the private validators and those with institutional stake agreements.

On the other hand, if a mechanism for sharing block rewards is not implemented, then block reward sharing can (and will) still happen, but in a bespoke manner that is more dangerous for stakers. One example would be that stake pools (like the JITO stake pool especially) could just require validators to deposit half of their block rewards into their JITO tip account every epoch, which will then be distributed to stakers according to the normal JITO tip distribution process. This would be a way to accomplish block rewards sharing but in an objectively worse manner than a well thought out, well implemented, more secure chain native fashion.

At this point, I can see both sides of the debate here and I can’t say I have a clear answer as to how I will vote. I don’t want Solana to offer technically inferior solutions to stakers; but I also don’t want to create a system which puts even more friction in front of validators just getting started. I will be watching arguments in public forums and making my choice based on the nature of arguments I see there. If I come to a definitive conclusion, I will post my final thoughts in this thread.

1 Like
15

We have known for a long time that this proposal was coming, and there already exist multitude of manual and out-of-protocol mechanisms for sharing block rewards. This includes LSTs as well as manual airdrops, USDC airdrops, NFTs and most recently Jito’s TipRouter.

It is inevitable that stakers will demand their fair share of block rewards, and out-of-protocol solutions are universally poorer options, in terms of friction, trust assumptions and transparency.

While I completely understand the concerns validators have with this (concerns that I share), refusing to implement this kind of mechanism and forcing inefficient side-deals is blatantly worse for stakers and for the overall user experience of the staking product.

As an ecosystem focused on rapid accelerationism and innovation it is imperative that we continue to innovate and push forward.

I sincerely hope that the result of this is a moderate and balanced equilibrium of block rewards sharing, where both validators and stakers get to enjoy the fruits of their labour and investments.

I will be voting in favour of this proposal.

16

I’m curious - if 4% inflation paid out as stake rewards represents capital inefficiency, why doesn’t block rewards paid out to stakers represent the same thing?

2 Likes
17

@stakerRash @Grigorii @ily-validator @adi_vb @mariaeverstake @Leapfrog

I understand and share your concerns about the potential impact on small validators. However, these concerns will not be mitigated by rejecting this proposal. Stakers are already demanding block reward sharing, and we’re witnessing rapid growth in off-protocol solutions. Examples include:

  • Jito compelling validators in the jitoSOL stake pool to share rewards through their tip router.
  • Marinade demanding block rewards via their stake auction market.
  • Retail stakers increasingly choosing LSTs that offer reward sharing.

This trend will inevitably continue, becoming increasingly complex and fragmented. The core protocol needs to address this clear network demand explicitly. If we don’t implement a standardized, transparent solution within the protocol, third parties will define how block rewards are shared—often at the expense of validators, as these entities typically extract their own fees.

Voting “no” won’t stop reward sharing; it will simply cede control to external parties. Implementing this mechanism within the protocol standardizes the process, enhances transparency, reduces trust requirements, and improves operational security by allowing validators to direct rewards to secure accounts (e.g., multisigs or cold wallets).

A “no” vote is effectively a vote for third-party intermediaries to control reward distribution, potentially extracting additional fees from validators and stakers alike.

It’s essential we proactively shape this inevitable outcome rather than leaving it to external actors.

2 Likes
18

I am going to vote “no” at this time.

I already distribute block rewards through sanctum LST, and also distribute block rewards to native stakers through my own program as well.

If validators create their own program, they do not have to make extra payments to third parties.
Also, they can flexibly distribute more block rewards to long-term stakers, and less to short-term stakers, for example.The program is not too difficult to implement.

For small validators, the SFDP’s delegation rule is practically enforced; Jito MEV reward was initially allowed at 100%. But, due to the adverse effects of Marinade’s SAM, etc.??, 10% was set as the maximum. The same will no doubt happen with block rewards. And other stake pools will also set block reward % criteria.

If SIMD-123 is applied, validators will become mere commodities. We can only differentiate ourselves by simply setting the less number to a percentage.
Validators should be able to differentiate ourselves by our own ingenuity; SMD-123 takes away the room for ingenuity. It eliminates diversity and drives us into a fruitless race to 0%.

It would bring temptation to vicious side deals such as sandwiches. Add to that a reduction in the number of validators, and security concerns increase.

However, I will make the final vote after listening to the intentions of my stakers.

19

Hey Pico,

one thing to consider is that you’re already doing this out of protocol, but it makes it difficult for your stakers to see and understand the APY they’re earning.

At the same time, what you describe using a custom program, relies on trust and manual transfers from your identity account (even if you automate them with a script, you have to first receive the lamports into the identity account), while with this proposal you could specify your custom program as the collector of your block rewards and still use a custom program.

1 Like
20

Michael, I was not aware that we could use a custom program. Thanks.
Your two points are good ones. From a technical standpoint I think they are great. I also sympathize with the idea of accelerating innovation.
If this proposal passes I may use it.

However, I am still against it because of the increased competition and security risks that remain, and when combined with SIMD-228, the negative impact on small validators is too big. I don’t want to see small validators committing mass suicide towards 0% and disappearing. I don’t want to see users exposed to more sandwich attacks.

I oppose this because I am proud to be a part of this ecosystem and I really like it and want to protect this Solana community.

2 Likes
21

The playing field for validators must be even. Today, large validators have way too much income through block rewards because voting costs are the same no matter how much you stake. This simply should not be. If a validator votes on behalf of 1mil SOL it should pay more for voting then a validator voting for 1 staked SOL. This would level the playing field somewhat because right now with the price of SOL voting costs are the majority of costs for running a validator (the HW costs are probably around 20% of that). Small validators really only have block rewards to cover their costs (no one staked on a validator that keeps X % for themselves) and since they are not leader often don’t receive many block rewards. One could simply say - based on leader schedule - your voting cost is magnified X times based on how often you are leader (someone smart figure out the details :)). You get the ideal - level the playing field. This proposal will just commercialize the opposite. While its true some validators give out block rewards, it is the large validator that does that (as they swim in SOL literally) and can price everyone else out. Do not vote for this. I don’t care that they have to do extra work to give out block rewards, this should only ever be implemented when the playing field is even.

2 Likes