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

The effect to tokenomics / supply inflation seems pretty neutral, so I am not concerned with that.

I think this goes part of the way in reducing off-chain agreements, but is not the whole picture. Imagine if a searcher has an OCA with a validator to rebate priority fees in exchange for a slice of the MEV. Then what happens? The searcher can systematically overpay on priority fees and outbid everyone else, thereby winning more, and sharing some of the profits with the validator. The MEV is presumably more lucrative than accepting the highest fee, so they will be incentivized to continue these type of arrangements. IMO, the only way to prevent something like that is to have a dynamic base fee that is burned, and unilateral to all participants such that they canā€™t ignore it, and it becomes a cost center to the searcher. Currently, trivial base fee can be pretty much ignored.

Anyway, I donā€™t object to how or what the proposal is presenting, just that I think it wonā€™t solve the issue of off-chain agreements. Happy to hear any explanations for why my reasoning wrong, also.

5 Likes

No! the sol will Inflation. the price must be decrease.

all solana user will lost the value of sol.

And 99.99% solana users dont know how to make the side deals.

if the validators think the fee is less, they can be another block chain validators, not only solana.

2 Likes

If there is no mechanism to burn SOL on the Solana blockchain, then there will be an issue with tokenomics inflation. In the long run, SOL will become increasingly worthless and no one will be willing to hold SOL.

Any validator is voting against? So anyone can change their stakes.

3 Likes

This has my full support

Support for this proposal from 1000x.sh

This is really concerning, and does nothing for the stakers, obviously all the validators are for this, thatā€™s really not a surprise.

Any validator who are against it, please let us know, so we can change our staking delegation.

2 Likes

Iā€™m not following, while this proposal improves the incentive regarding priority fees, it might not completely eradicate side deals. Validators can still make agreements outside the official channels if the incentives are sufficiently high. How this prevents side-deals from being made, if this is a main goal of that SIMD?

How this prevents side-deals from being made, if this is a main goal of that SIMD?

@denysk Correct, this proposal does not prevent ā€œside dealsā€ for transaction fees. But it removes the main incentive to do them. Let me ask the opposite: Why would validators continue to use an out-of-band mechanism to accept transaction fees when a builtin protocol mechanism guarantees they get 100% of the priority fee?

2 Likes

Iā€™m not sure, sir; Iā€™m just speculating. My point is - that proposal does not cancel any opportunities for side-deals: there are Jito, various mempools, God knows what else would come in short while, but all of them are value added, and not replacement for priority fees.

It is certain that if validator runs Jito (we do) the block will contain Jito-bundles TXs, priority TXs, as well as normal TXs; so running Jito does not eliminate priority fee validator receives, it is just reduces it. And I think to compete with Jito bundled TXs (mind you, that many wallets/projects now supports it) priority fees will need to raise 10-fold.

As a validator Iā€™m not agains the proposal, donā€™t take me wrong, itā€™s a business after all, not a charity case, as we already running 0% inflation fee forever, and 0% Jito fee (so all Jito tips goes to our stakers) and priority fee will be our sole source of profit; but for other validators, who runs 100% Jito fee - this is not much to even consider.

Sorry for the long post, just my 5c.

And on point of stakes/delegators, there are a lot of negative feedback, claiming that this proposal will not benefit stakers but only validators - In fact, its quite opposite, if validator runs 50-100% Jito fee, it only shares part of MEV profit with stakers or not at all in case of 100% fee.

So it does not disadvantage stakers in this case at all. In fact, rising priority fees 2x, may get some 100% MEV fee validators to consider reducing it and therefore start sharing MEV profit with stakers as they are now have expensed covered by priority fee.

Itā€™s quite opposite what most negative posts claim, that proposal is not going to benefit stakers.

Priority Fees are not required, have no minimum, and are not fixed. Look at any hot account in any block, and you will see a range of PFs from zero to some maximum value. There is no such thing as a canonical PF value for any account in any block. When you say someone might offer 75%, that means 75% of what? What does this hypothetical side deal look like?

For example, I never need to pay the max PF for inclusion. If I simply pay the recent median PF, my TX will be included virtually 100% of the time. I donā€™t need to make 75% side deals (whatever that means) to land TXs. Iā€™m not convinced that potential side deals are a big problem (Jito addresses the need to cut a side deal in the first place). On the other hand, the side effects could be worseā€¦

To use PFs, you must first know the prevailing PFs for the writable accounts. Many apps estimate fees using the getRecentPrioritizationFees (gRPF) RPC method or other APIs. Reading recent PFs as input into setting PFs for the next TX creates a feedback loop that can be abused.

This proposal allows a validator to cheaply push PFs higher for hot accounts and keep 100% of the increase when senders raise their PFs to adjust the higher values. Other senders then react to the new higher values by raising their PFs, and a vicious cycle begins. (Weā€™ve already seen the vicious cycle play out when network congestion was bad recently. It happened before and will happen again). Manipulation becomes EV+ for all validators because of the feedback loop. There is a mass incentive to cheat.

Throw in other incentives, and things get spicy. For example, can I influence ORE mining by paying ridiculously high PFs for my mining TXs in my leader slots? It will be effectively free for me to try. YOLO

The proposal allows validators to manipulate PFs without bounds. Iā€™m opposed.

5 Likes

These side deals are miniscule, and I truly believe its not happening or is a very rare occurance. Sounds like smoke and mirrors to push this.why can no one provide evidence and stats if this is such a big deal?

The end results will be validators shoving blocks to create fake high PFs for users since they stand to benefit exponentially in this circumstance.

A tremendous amount of reseach by some of the top people in cryptograghy and gametheory discus PF and all attack vectors in depth. Wny is no real research being down? No proper write up or anything regarding this matter? There is a reason another blockchain burned 100% fees. To avoid validator manipulation of blocks to increase their profits.

Deleting posts that do not agree with your financial incentives is very disturbing. This topic is being blown up on social media and the only people that are for this are the validators for obvious reasons, who is going to be voting no to increasing their own revenue? No one is, thats why this seems very biased and doesnt seem very truthful when no stats or evidence has been provided about these side deals people are claiming.

Technological develpments need to occur to benefit validators such as reducing node requirements to reduce infra costs. Not essentially stealing a deflation aspect people bought into solana for, every user will suffer with higher inflation, doesnt matter how much you undermine the amounts, it still remains a fact.

When a validator above states ā€œcharityā€ you need to look in the mirror because you are the charity with peoples delegations, honestly the networks users owe you all absolutely nothing. If 75% of validators are not profitible that is your issue not the users. Ironically this is also being pushed before firedancer which negates your stances on incentives. Everyone knows the bottleneck is hardware requirements.

Changing monetary policy is a big deal, and legal consequences for such monetary policy changes im sure will arise. Most of you validators own multiple and with such a miniscule pass rate a couple of you are cheating millions of users.

Since posts are being censored and deleted, screen shot taken to prove i did not break any forum rules and am being deleted solely because of abuse of power. The same abuse of power that will manipulate blocks and increase PF for all users. Actions speak louder than words and the severe censorship paints a clear picture how validators will abuse this system.

3 Likes

I believe there is a need for everyone in this conversation to clarify what constitutes a side deal. For instance, does running a Jito-client count as a side deal? If not, what does?

Please note that I have not declared whether I will vote in favor of this proposal; in fact, after consulting with my team, I am likely to abstain. The mention of the ā€œcharityā€ was intended to clarify that validators operate as businesses and have expenses to cover.

When a validator above states ā€œcharityā€ you need to look in the mirror because you are the charity with peoples delegations, honestly the networks users owe you all absolutely nothing. If 75% of validators are not profitible that is your issue not the users. Ironically this is also being pushed before firedancer which negates your stances on incentives. Everyone knows the bottleneck is hardware requirements.

I think many seriously underestimate the potential monthly costs for a validator. Infrastructure is expensive to maintain in order to fulfill validator duties effectively. This includes not just running a basic server but also managing failover infrastructure, upgrade-servers, Jito-relayers, private RPCs - for monitoring solutions, among other things, and Iā€™m not even staring to mention DevOps and labour cost. Additionally, during the bear market - not long ago, an average validator (with an average stake of 100K SOL, for instance) encountered enormous costs compared to the inflation rewards received for performing their duties partly due to the costs of voting, and when priority fees did not exist. During these times, most validators suffered losses and covered these expenses with cash if they had it, or by taking out loans. Now people think validators should run on tiny margins and forget about previous challenges. This above not really relevant to the proposal, but just to explain what validators do, and what challenges they face. For example, If you had used the profitability calculator six months ago, it would likely show a profit loss in most cases, unless you were running an under-spec validator with no failover, etc., which is harmful to the network.

Our position on this proposal is clearā€”we do not see the benefits for the network, but we do see benefits for both stakers and validators, as mentioned in the above post: doubling the priority fees will help us maintain a 0% fee plus 0% MEV fee for much longer and therefore stakers will continue to receive all the MEV profit share.

The end results will be validators shoving blocks to create fake high PFs for users since they stand to benefit exponentially in this circumstance.

Why donā€™t they do it now? its only 50% fees burn now.

Not essentially stealing a deflation aspect people bought into solana for, every user will suffer with higher inflation, doesnt matter how much you undermine the amounts, it still remains a fact.

I believe the change will not significantly impact inflation figures, as the amount of fees burned is minimal compared to the inflation rewards from the total stake.

@brian.long, I donā€™t understand how a validator can control PF if this setting is on the client, and the validator does not even know the list of transactions it receives in the leader slot under normal circumstances, it cannot choose, unless running some sort of modified software.

I agree with Brian on these matters. Side deals to avoid priority fee burn donā€™t exist now (?) and even if they do pop up eventually it doesnā€™t seem like a huge deal.

Other concerns from us (Overclock Validator) are that:

  1. Without a native block reward sharing mechanism, validators will need to rely on bespoke ways of distributing these rewards to be competitive but in various jurisdictions this might increase the regulatory risk for validators (and scrutiny from regulators on Solana generally which could hurt users/ecosystem even outside those jurisdictions). You could say this is an issue already, but 100% priority fee sharing magnifies that issue further.

  2. This SIMD will make it much harder for transaction fees to add significant deflationary pressure. Right now transaction fee burn might be dwarfed by inflation emissions, but itā€™s still possible that fee burn can have a greater impact in the future ā€“ this SIMD makes it far harder for them to be significant in this regard though. Whether deflationary pressure matters is up for debate, but itā€™s worth considering more.

Definitely leaning no as of now

I can understand some of your points regarding infrastructure costs being a validator, but at the same time users and developers are spending money as well just to access the network. This is an issue for nearly everyone. Not validators alone. Are validators like helius going to reduce rpc services for its users, after getting more rewards? Highly unlikely.

Many top validators also have secondary revenue streams with their infrastructure to offset costs.

More importantly on the situation of voting for yourselves with such a minimum amount required to pass a proposal is very concerning, especially since some of the top validators are in fact multiple validators.

So a small handful of people are deciding the fate of the network and millions of participants.

Regarding stuffing blocks, there is a big difference between 50% reward and 100% reward from an attack vector. Stuffing blocks at 50% is not financially beneficial as half of the fee will be burned. With 100% there is absolutely no risk or drawback from validator collusion. Many non validating users believe now that this proposal is validator collusion in itself and will be a gateway to more negative impacts for users.

Lastly, how does this incentivize and bring on new validators as the reward will not be evenly distributed? No new validator coming online is going to compete and benefit in any significant manner. With increasing minimum stake requirements to access QoS they will be even more at a disadvantage. The nodes and access need to be severely worked on that will solve finding better ways to incentivise validators, this shouldnt be simply put off and a rush for some monetary policy change to ignore glaring issues such as infrastructure costs. With firedancer around the corner that will bring validators to more peoples homes and such this is going to fill a lot of incentives in itself.

3 Likes

Yes, as Iā€™ve mentioned before, the current voting system is not perfect, and I would prefer to see quadratic voting implemented instead of weighting by stake. There have been discussions about allowing stakers to vote according to their stake weight, but Iā€™m not sure how those ended, and also this will mean the whales will decide our fate, so quadratic still my preference.

With firedancer around the corner that will bring validators to more peoples homes and such this is going to fill a lot of incentives in itself.

Are you aware that there is a voting fee? Even at 5% inflation fee (let alone 0%) you just break even, please check here: Validator Profit Calculator. There are no minimum stake requirements, you can start a validator with 100 SOL, but youā€™ll just end up burning your SOL on voting fees in your vote account.

1 Like

I am fully aware of vote fees. Im also fully aware that infrastructure if calculating $2500/month costs which at todays prices is slightly over 200 sol a year savings per validator. Bringing infrastructure to peoples homes is going to be a huge incentive regardless of vote fees.

Of course infrastructure costs are dependent and different for everyone but the savings will be a great impact.

Its good to see some logical discussions here, but kind of dissappinted there is no real write up in regards to all pros and cons, including validator collusion risks which is in my opinion a higher risk than some side deals that may or may not be happening. I feel like this proposal is trading one risk for another risk that in my opinion is far more severe and negative towards the network.

My final thought on here will be this. Look at ore as an example of how easy it is to spam blocks with essentially worthless txs. It is a simple script that negatively impacted the network with congestion. On social media some of the key players in solana were trying to work deals it looked like with ore. If this is happening in open view, what is going on behijd the scenes since ore was turned off for now. Whats going to stop validators colluding and writijgna similar script? Yes its all theoritical such as everything else. It is just one possibility and very high risk.

3 Likes

The active discussions here feel like a hopeful evolution of the networkā€™s governance process. Chainflow will be posting more about our vote for this specific SIMD soon. In the meantime, we thought it would be helpful to comment on the voting process itself, specifically regarding who can vote, i.e. validators only, how that decision came about and how delegators can still exercise some degree of power, albeit indirect, to help shape the vote.

The first governance vote, held this past October, determined which stakeholders have the power to vote.

Chainflow voted for the option that would have allowed validators, delegators and other stakeholders to vote.

Ultimately the ā€œvalidators onlyā€ vote prevailed. And now the SIMD 96 vote may expose a limitation in a governance system where only validators can vote.

For example, as we see in some comments above, some stakeholders may perceive validators as voting to enrich themselves at the expense of the broader community and feel powerless without the ability to directly vote and influence the outcome. But remember, even if youā€™re a delegator without direct voting power, you can still exercise indirect decision-making power by delegating to a validator or validators whose voting decisions you align with.

The way the current voting system works is that a validator canā€™t change their vote once itā€™s cast. Over time, hopefully the process evolves to allow a validator to change their vote within a specified time period.

In the meantime, delegators should make their opinions known to the validators they delegate (or are considering delegating) to early in the process, before the voting period starts. Doing this will give validators time to consider the information expressed in these options into their vote decision-making framework.

2 Likes

As I mentioned during that call, I really keyed on Zan from Shinobiā€™s confirmation that priority fees are generally received proportional to total validator stake.

I agree that this exacerbates the ā€œrich get richerā€ scenario inherent in proof of stake networks. Itā€™s an issue Iā€™ve been concerned with for years now and wrote about it here.

Ultimately I believe we need in-protocol mechanisms to mitigate the issue, having seen over the years that relying on human altruism to more equitably distribute stake doesnā€™t work. Lately Iā€™ve been thinking about smoothing functions, i.e. where some proportion of all fees are redistributed to all validators who, for example, are performing at or above a certain level.

Iā€™m also not seeing how this prevents side deals. I feel like Iā€™m missing something here about how the side deals are implemented currently. Maybe @tao-stones could describe this in greater detail (BTW, thanks for putting this proposal up for discussion!).

Chainflow is currently leaning toward abstaining, as we feel that validators may have a conflict of interest when voting for a proposal that could benefit us, without delegators having a more direct way to participate in the voting process.

1 Like