Proposal for Enabling the Reward Full Priority Fee to Validator on Solana Mainnet-beta

Governance
,
1

Background

The current model of collecting priority fees, with 50% being burnt and 50% rewarded, does not fully align with validator incentives and inadvertently encourages side deals. For example, consider a scenario where a transaction submitter wishes to prioritize their transaction. Under the existing model, they might opt to directly pay the block producer a 75% priority fee to ensure their transaction is processed promptly, rather than paying 100% priority fee where the block producer only receives 50%. This creates an imbalance where the incentives of validators are not adequately aligned with the network’s overall health and security.

To rectify this issue, it’s proposed to adjust the priority fee structure to reward validators with 100% of the fees collected. This ensures that validators are appropriately incentivized to prioritize network security and efficiency, rather than being incentivized to engage in potentially detrimental side deals.

This proposal, outlined in Solana Improvement Document number 96 (SIMD-0096), has been fully implemented with the feature:

  • Feature Gate 3opE3EzAKnUftUDURkzMgwpNgimBAypW1mNDYH4x4Zg7 : Reward full priority fee to validators #34731: This feature ensures that 100% of the priority fee is awarded to the validator.

The implementation of this proposal requires the use of a feature gate. While there will be no change to the payment structure for transaction submitters, the software incorporating this proposal will allocate a larger portion of fees to the validator compared to previous versions. Thus, a feature gate is essential to ensure a smooth transition for all validators to the new functionality at the epoch boundary, thereby maintaining consensus.

This feature is currently available in the Master of Agave repo (minimum version 2.0) and can only be activated on mainnet-beta after the release of a sufficient quorum of stake, following normal feature enabling rules. Additionally, it’s recommended to activate this feature after the implementation of Feature BtVN7YjDzNE6Dk7kTT7YTDgMNUZTNgiSJgsdzAeTg2jF to address potential rounding errors.

Testing

The following tests have been conducted to ensure the functionality of the proposed feature:

  1. Unit tests added to the Agave repo demonstrate the feature’s functionality in various scenarios.

test_total_fee_rounding
test_filter_program_errors_and_collect_fee_details
test_check_execution_status_and_charge_fee
test_distribute_transaction_fee_details_normal
test_distribute_transaction_fee_details_zero
test_distribute_transaction_fee_details_burn_all
test_distribute_transaction_fee_details_overflow_failure

  1. Testing performed on a local test cluster with the feature enabled, observed slots advance and bank capitalization change.

Proposal

It is proposed that the Reward Full Priority Fee to Validator feature, as described in Solana Improvement Document 96 (SIMD-0096), be enabled on the Solana Mainnet-beta cluster according to the following steps:

  1. Ensure Feature BtVN7YjDzNE6Dk7kTT7YTDgMNUZTNgiSJgsdzAeTg2jF is enabled to address potential rounding errors.

  2. Enable Feature 3opE3EzAKnUftUDURkzMgwpNgimBAypW1mNDYH4x4Zg7 on the Solana Mainnet-beta cluster.

After these steps, validators will receive 100% of the priority fee as part of their reward.

Voting Process

The voting process will proceed as follows:

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

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

  3. Vote token distribution will require validators to utilize the Jito Merkle Distributor tool (available at https://github.com/jito-foundation/distributor) to claim the vote tokens corresponding to their stake weights.

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

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

  6. 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.

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

Timeline

Epoch 612 - 615: Discussion period

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

Epoch 617: Voting token distribution, vote addresses created, voting begins

Epochs 618 - 620: Voting continues and completes

Epoch 621: Voting is finished, and the resulting tally determines the outcome

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

SIMD-0096: https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0096-reward-collected-priority-fee-in-entirety.md

Feature Gate: Reward full priority fee to validators #34731: https://github.com/solana-labs/solana/issues/34731

11 Likes
2

Thanks for putting this proposal together Tao!

A technical question which maybe should’ve been asked on the SIMD: There is an expectation (at least by some) that this would lead to lower priority fees as the market finds a new equilibrium. This made me wonder if the RPC methods to fetch recent priority fee samples needs to be (or is) adjusted with this change to reflect the changed burn rate?

Overall I believe this change makes sense, though I’d prefer to have more evidence that side deals are happening and are a problem. At the same time the burn on the base fee should in theory protect the original purpose of the burn.

There have been some comments in the past relating to this proposal with reference to economics and reduced burn causing a rise in net emissions on the network, while this might be the case I’m not convinced that this is materially significant relative to the inflationary rewards.

EDIT: On reflection the burn argument doesn’t make sense, as burning prio fees is just a bonus, if prio fees are not burned or prio fees don’t exist at all makes no difference to emission.

2 Likes
3

though I’d prefer to have more evidence that side deals are happening

Jito bundles are sort of like side deals on txn inclusion. Not all bundles are MEV specific and some use cases use Jito bundles with a small tip on non MEV txns for better inclusion.

I don’t see this as a major issue but it is evidence that people are already doing “side deals” in a streamlined way.

2 Likes
4

Agreed, though arguably Jito bundles provide far more utility to users, validators and stakers than priority fees currently can, given they provide for prioritization, rewards to stakers and fee collection by validators. Priority fees currently have no automated, elegant or enforcable mechanism of distribution to stakers, so stakers ultimately should prefer the use of jito bundles.

Above to be seen in context of SIMD-0123 SIMD-0123: Block Fee Distribution by jstarry ¡ Pull Request #123 ¡ solana-foundation/solana-improvement-documents ¡ GitHub

1 Like
5

I support this SIMD.

3 Likes
6

I will vote ‘For’. This will help small validators stay afloat, especially if a block reward sharing system is implemented.

1 Like
7

RPC methods deal with what submitters pay (via set_compute_unit_price), not how much block producers were rewarded. So the change of burn rate should not impact RPC methods.

2 Likes
8

How does this proposal benefit stakers? Seems like this proposal helps validators which is great but doesn’t the 50 percent burn help stakers?

3 Likes
9

I strongly support this SIMD.

3 Likes
10

Fair question. Could see the side deals incentivized by 50% burn don’t benefit stakers either.

4 Likes
11

It’s more transparent, visible, and allows stakers to hold validators accountable since their stake plays a material role in these rewards. With side deals, they could be doing this and stakers would have no idea. Also means validators have more revenue they make which might incentivize them to lower commission without losing income.

It also leads nicely into this proposal: SIMD-0123: Block Fee Distribution by jstarry ¡ Pull Request #123 ¡ solana-foundation/solana-improvement-documents ¡ GitHub

1 Like
12

After carefully reviewing SIMD-0096, we would like to express our support for this enhancement. We believe this proposal is a positive step towards improving network efficiency and aligning validator incentives with Solana’s long-term health and security.

1 Like
13

Juicy Stake will be voting For in favor of this proposal. This will potentially make it easier to achieve break even or profit for newer or smaller validators, which helps delegators gain confidence in the validator they stake with.

1 Like
14

Having just sat in on the tremendous call hosted by Tim and Ben (thank you!), I’d like to express my opinion as someone who is just now trying to break into the validator business.

I think because priority fees are (also) earned relative to the amount of stake you have, this proposal will put us into a “rich get richer” kind of scenario, and it will make it harder for new validators to compete for stake in the long run (because larger validators can afford to offer kickbacks and other financial incentives with the increased revenue).

I also don’t see how this precludes validators from making side deals.

I do agree that this proposal helps aligns validator incentives, but I think maybe I’m hung up on the philosophical debate about which validators are being helped, and whether or not helping them is in the network’s best interest (in terms of decentralization).

Appreciate the discussion; thank you to everybody who is participating!

5 Likes
30

I am for this proposal.

However, there are a few things to consider.
a) if this goes through, we will stop seeing out of protocol payments - Good :+1:t4:
b) Smaller validators will make more - Good :+1:t4:
c) This does nothing for stakers - :-1:t4:

To solve for c, we need to seriously look into the exact mechanism of fee sharing, maybe even make the two changes go live together.

1 Like
33

A is 100% false.

They talked about distribution offchain if they share the reward with stakers. You swapping one thing for exactly the same thing. The irony is ludacris. There is no on chain mechanism to distribute rewards. Therefor its all manipulation and scare tactics acting like its in every users best interest while they pocket this money for themselves and do their own backroom deals. These people can not be trusted. Who is buying into Validators voting to give themselves more money? What makes you believe you are getting any accurate information from them? It’s in their best interest to give themselves more money and thats why they all here talking about it behind their stakers backs and without their inputs.

5 Likes
34

Not in favor of giving validators more sol so they can literally do the exact off chain things they say this prevents. One backroom deal vs another is not saving anyone.

3 Likes
35

Out of protocol does not mean “off-chain”. Today’s priority fee burn circumvention still happens onchain. They just send it as a different transaction to the block producer, on-chain. This proposal would just make those fee payers pay the same fee as part of the same transaction. So this is a good thing for the network. However, a fee sharing mechanism must be introduced so stakers can capture this fee. It’s also important to note that some validators already share all their fees to the stakers, so your particular concern along with many others in this thread are invalid.
All that said, my stance is simple - The proposal should go through but the feature should only be activated along with the staker fee share mechanism.

38

I agree with the mitigation of side deals, but I think the economic impact of such a change needs to be carefully thought through.

39

Everstake fully supports this proposal. By implementing this, we enhance the incentives for validators, thereby reinforcing the network’s security and stability.

1 Like