Sharing Block Rewards and Arbitrary Lamports with Stakers

[Benhawkins18]

With SIMD-0096 (remove burn from priority fees), users expressed concerns of not being able to benefit from the increased block rewards, and validators expressed they’d like to be able to share block rewards. Along with sharing block rewards, validators do not have a way to share arbitrary sources of revenue. Some validators have used liquid staking tokens to share block rewards and other sources of revenue by adding SOL to an LST reserve account, but this can only benefit liquid staking users where a vast majority of staking is done natively.

This needs to be done in protocol because it's incredibly expensive to load 1.5m and growing stake accounts. Anything that isn't in protocol has to do hundreds of thousands of transactions and update all of the stake account balances. We see see this behaviour with Jito’s merkel tree claim-based distribution which requires hundreds of thousands of transactions to claim and move SOL each epoch to stakers.

We can piggy back off of the epoch rewards calculation that already does these expensive accounts loads while providing a very simple solution for validators to share block rewards and any other sources of revenue.

Proposed Solution:

1. Create a staker lamport distribution system. Each vote account would have a derived stake rewards pool account. This stake rewards pool account would be able to receive lamports at any point during the epoch. Each epoch, during inflation reward calculations, any lamports above the rent for the reward pool account would be removed from the account and be added to the total inflation rewards. The inflation rewards + stake rewards pool account would then be distributed to all stakers. [1]* This could be used by the validator or any rewards system to efficiently distribute lamports to all of a validator’s stakers.

2. Create a block rewards commission system that divides block rewards into two accounts. One account would be the aforementioned stake rewards pool account, and the other would be the validator block reward account. The validator block reward account would be defined in the vote account along with a commission value set separate from inflation rewards commission. The validator block reward account would be assignable to any address, defaulting to the identity account, and it would receive all of the commission from block rewards.

Example: A validator that has 20% block reward commission and creates a block that has a total of 100 million lamports in fees. 20 million lamports would go to their validator block reward account, and 80 million would go to the staker collector account to be distributed.

Prerequisites:

• The leader schedule system would have to be defined by vote accounts instead of identity accounts. SIMD-0180: Leader Schedule Migration
• Vote accounts would need to be updated by adding a for value for block rewards commission, a bump for the derived staker collection account, and a public key for the validator block reward collector account (defaults to identity). Possibly something like SIMD-0185: Vote Account v4

Potential Next Steps:

1. Get comments on this proposal and revise as needed.
2. Ensure broad buy-in from validators, users, and core devs.
3. Revize prerequisite SIMDs.
4. Update SIMD-0123: Block Revenue Distribution to be commented on, revised, and approved to reflect the desired distribution mechanism.
5. Validators vote on the new SIMD.
6. Prioritize with core devs.

[1] inflation rewards are always added as active stake. There’s a complication in which these lamports from the collector account will be existing lamports that aren’t staked. One could design this system to just add to the unstaked portion of lamports, requiring users to withdraw these lamports similar to the existing Jito system. Alternatively, one could design it to go in as staked lamports, but would have to deal with the total activating stake limit and potential complications there. If the collector account’s lamports are added as stake, one would have to deal with treating these lamports as “activating” aka “warming up” stake.

[uri-bloXroute]

contrarian take:
pre-0096 50% of the value goes to the validators directly, 40% benefit the stakers (thru burn, since 80% of SOL is staked), and 10% benefits non-staked SOL (thru burn)

what's the point of removing the burn, passing 100% to the validators, and then effectively adding a competition vector so we should expect most to be rewarded to stakers, except in those situations like FTX owned SOL where the staked is tied long term with a provider, who would take advantage and won't roll this value to its stakers?

what's the value of these 2 changes and is it significantly better and worth the implementation and activation of 2 SIMD?

(I don't fully back this argument, and having designed such tooling for Paladin can appreciate its usefulness, but playing devil's advocate here)

[michaelh-laine]

1. The change in burn has already been passed, so undoing this isn't currently up for debate
2. The burn provides a fixed split to validators rather than ability to specify custom rates
3. It doesn't allow for any alternate revenue sharing, such as swqos partnership revenue
4. Ecosystem is largely designed around measuring stake account delta as measure of staking APY, standardizing mechanisms for block rewards sharing, which exist in various forms already (regardless of prio fee burn) ensures we can create standards and transparency for measuring and comparison between validators
5. Block rewards until a year ago were wholly insignificant, but with long-term reduction of inflation and current position of block rewards providing significant revenue sharing these in a normalized manner is important to continue providing incentive for staking and resulting economic security (cue Toly, it's a meme). Further, larger validators have resources to push down block rewards to stakers through custom systems that smaller validators cannot compete with, having a standardized system ensures we maintain a somewhat fair and competitive validator market place

[jstarry]

pre-0096 50% of the value goes to the validators directly, 40% benefit the stakers (thru burn, since 80% of SOL is staked), and 10% benefits non-staked SOL (thru burn)

Yeah this is kinda true but I think it makes more sense for stakers to benefit directly from the fees earned by the validator they delegate stake to rather than from the burn. This incentivizes stake to move to validators who are producing valid blocks and producing blocks that are full.

But to play along with your devil's advocate argument, I think this feature could have an indirect centralizing effect on delegated stake. Validators with relatively small amounts of delegated stake will get fewer leader slots and therefore earn less total block fees to compensate for the voting fees they need to pay each epoch. This means they probably need to set a higher block reward commission rate than validators with more stake which may cause stakers to move elsewhere. I think this problem already exists though with the existing commission rate for inflation rewards so it doesn't feel like a valid reason to block this proposal.

[michaelh-laine]

Thanks Ben, glad to see this conversation being taken forward.

I'm not sure it would be necessary to specify a validator block reward collector account, this would require additional space in the vote account and for the vast majority they would use the default of the identity account to ensure their funds for vote fees remain covered.

Aside from this the system makes sense, I think the pool reward account can be treated as an activating stake account and it should be possible to amend the stake activation/deactivation to include these in those figures, the main difference being that the staked lamports amount can change until the last slot of the epoch (but this is already the case for regular stake accounts as well).

Additionally, similar to Jito, the pool rewards account seed can include the epoch number, creating a separate account for each epoch, this may make tracking activating stake easier, the pool rewards account would be closed post-distribution and the remaining state bond used to fund the N+2 rewards pool account, a validator would need to put up the funds up-front to fund state bonds for two accounts, for epochs N and N+1, in epoch N+1 during rewards distribution account for N is closed and N+2 is opened, and so on.

[jstarry]

I'm not sure it would be necessary to specify a validator block reward collector account, this would require additional space in the vote account and for the vast majority they would use the default of the identity account to ensure their funds for vote fees remain covered.

The additional space is not really an issue because it's just 32 extra bytes and we should be able to free up a lot of allocated space by removing (or at least paring down) the prior_votes field.

The main motivation for allowing a custom collector account is that it allows validators more customization on how fees are collected. Their collector account could be a PDA which is controlled by a program which uses a custom reward distribution mechanism or allows you to use a cold wallet or multisig to take custody of rewards rather than the protocol putting all earned rewards in an account which has to be a hot wallet right now. But you are right that if you allow validators to divert block rewards to a different account, they could forget to top up their voting authority with funds for votes. Not sure what to do about that risk yet.

[michaelh-laine]

True if the space is trivial then it's probably a feature worth having, the multisig thing for example, I use a script right now to syphon funds off the hot account