Could you please say more about this? I feel like I’m missing this part in trying to understand how this proposal might mitigate these side deals.
It would seem to me that even if 100% of the priority fee is sent to a validator, that wouldn’t preclude the TXN sender from possibly sending even more of a payment to the validator, on top of 100% of the priority fee?
Appreciate all the thoughtful insights from everyone. I deliberately left side deal details out of proposal, preferring instead of focus on highlighting the misalignment of incentives.
This proposal is not aimed at eliminating all potential side deals, but to realign validator interests in a way that encourages more on-chain activities.
It’s assumed block producers always act in the best interests of themselves and their stakers, removing one obvious interests misalignment might help them to focus on building more valuable blocks.
yea, sender can always pay more to block producer for whatever reason, but just no longer the case that “I pay you 7, so you can put me ahead of other guys who paid 10 priority fee”. With this, sender needs to pay more to continue whatever was doing.
Epoch 616 has begun and this proposal is now in stake weight verification stage.
We are using a merkle distributor voting process, whereby a merkle tree is generated with all validators and their stake weights. The initial step is identical to the TVC vote with a CSV file which can be verified.
In epoch 617 validators will be able to begin claiming their voting tokens.
The CSV file with all stake weights can be found here
The repo with the distributor and details on how to claim tokens can be found here - alternatively Jito’s version of the CLI can also be used, though it will throw an error on claim (which can be ignored) and doesn’t support priority fees for a new claim.
The hashes for the CSV file, merkle tree and the voting token mint address are published here
In summary:
Verify the feature_proposal.csv file has a hash of 3972a374683e9fe9bf63ca179ae603ebf26e9cd5
cat feature-proposal.csv | sort | shasum
Verify the merkle tree has a hash of 3678a96f40de4b6eec8eedbc26c9b731f502362b
cat simd-0096-merkle-tree.json | shasum
The vote token mint address is simd96Cuw3M5TYAkZ1d71ug4bvVHiqHhhJzsFHHQxgq
The total supply will be 368296676892441006 with 1802 participating validators.
The voting destination addresses will be published here and on the repo when voting begins.
Shinobi Systems will be voting ‘no’ on this proposal.
I agree with the general premise of eliminating the 50% priority fee burn, as this burn doesn’t accomplish anything beyond adding some deflation to Solana economics.
However, I think that we need to hold changes to a higher standard. This proposal doesn’t attempt to be a net neutral change on Solana tokenomics; it alters burn rates and without any justification for doing so except as a side effect. It’s time to stop allowing changes with side effects that can be avoided.
If there is economic justification for eliminating this burn source, then let’s hear it. It should have been in the proposal to begin with.
If there is no economic justification for eliminating this burn source, then the proposal shouldn’t be voted for, as making arbitrary economic changes without justification should not be acceptable.
I will vote no on this proposal but hope that we can get another proposal in future that eliminates the priority fee burn while not making arbitrary changes to tokenomics.
Block Logic voting ‘no’ to this proposal in its current form. Happy to continue the discussion…
Agreed with the above, Laine will also be voting no due to a lack of justification and concerns about downstream problems that haven’t been sufficiently addressed. Would like to see this readdressed with block reward distribution discussion (simd 123)
Claim and voting is now live
You can claim your tokens using the distributor CLI 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., the token mint and merkle tree file are published here solgov-distributor/votes/simd0096 at master · laine-sa/solgov-distributor · GitHub
To cast your vote send them to these addresses
VOTING ADDRESSES:
YES: YESsimd96Cuw3M5TYAkZ1d71ug4bvVHiqHhhJzsFHHQ
NO: nosimd96Cuw3M5TYAkZ1d71ug4bvVHiqHhhJzssFHHQ
ABSTAIN: ABSTA1Nsimd96Cuw3M5TYAkZ1d71ug4bvVHiqHhhJzs
We have voted YES to this proposal where - 100% of the priority fees are rewarded to the validators. The main reason is that if a monetary incentive exists for opaque off-chain side deals to occur (whether or not it has been done yet). The fact a fee payer could potentially pay less and get their transaction prioritised, will create integrity issues within the on-chain priority fee market.
SolanaHub voted no to this proposal.
from several reasons:
tx signature:
4gNdy437KhqfH7jh34agib5yYgzWvqtBYtJTW6Zr2bhkS3Kcv8ZjWk11hwyegMNfrXcFGoTxnAVDQZHBQ6ebRtYP
Just to address your points 1 and 4:
Regardless of the above we voted no as well because there’s a lack of detail on the harm of side deals and the unaddressed concern of future block stuffing.
Hi Laine, thanks for replying.
while this proposal
it can’t be voted Yes
As posted in Discord here, we ran the provided verification script during Epoch 616.
It looks like there’s a very minor discrepancy. The discrepancy doesn’t seem to be material, however thought we’d mention it for completeness anyway and decided to post here for additional visibility.
$ bash check_stake_weights.sh ./feature-proposal.csv
ERROR: Stake weights do not match; diff follows
1378c1378
< Fd7btgySsrjuo25CJCj7oE7VPMyezDhnx7pZkj2v69Nk,9441545922873801
---
> Fd7btgySsrjuo25CJCj7oE7VPMyezDhnx7pZkj2v69Nk,9441545922873800
This seems to be a known error as discussed starting here in Discord.
We agree with the “rich get richer” observation and would like to see this addressed in future proposals. It’s a big issue inherent in proof of stake generally and one we wrote about here. While not trivial to address, we believe there are ways to do it, that would require in-protocol mechanisms. The first step is bringing continued awareness to the issue and we appreciate you doing that.
Chainflow plans to vote “Abstain” for Solana SIMD-0096 Reward 100% of priority fee to validator
We plan to abstain because we feel that voting for a proposal that directly impacts validator economics, within a governance process that only allows validators to vote directly, may create a conflict of interest. To avoid any such perception and likely set a precedent for future voting, we are planning to consciously abstain from this vote.
However, in an attempt to provide delegators, both current and prospective, a voice in the process, we will note vote until Epoch 619 at the earliest. The current vote process does not allow a validator to change its vote once cast, which is why we are choosing to delay our vote, working within the confines of the existing governance process.
If you are a current or prospective delegator and would like to provide feedback on our decision before Epoch 619 begins (approximately 2 days from the time of this post), please do by replying directly to this post.
Additional context -
The active discussions on Solana SIMD-0096 that this governance vote sparked feels like a hopeful evolution of the network’s governance process. As a reminder, 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-0096 vote may expose a limitation in a governance system where only validators can vote. For example, 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 to early in the process, so that the validators can consider the information expressed in these options into their vote decision-making framework.
We have made the decision to vote ‘no’ as well.
There are simply too many concerns being raised - not to mention the obvious conflict of interest in voting “yes” to such a proposal (which many have correctly pointed out).
We would like to see an in-depth analysis on the economic impact of such a change before this is pushed through, as well as any other mitigating economic modifications merged into the same proposal. As it stands, although this SIMD is well-intentioned, it was missing some important information when it was created.
The mitigation of side deals is an issue that needs to be addressed, but our opinion is that it needs to be done in a way that does not have unintended consequences (if it does have consequences, those need to be addressed in the same proposal).
This is an interesting perspective regarding the conflict, and I appreciate you’re waiting and inviting feedback, I’d love to see how such engagement works out and encourage that you possibly consider voting YES/NO based on feedback (or the absence of it). Validators are a proxy for delegators, and that proxy can be enacted passively or actively.
Many delegators may not be paying attention or might even just be passive holders who don’t check on the ecosystem frequently, I’d argue validators have a responsibility of stewardship and delegators would expect them to vote based on their overall values and represented “personality” which would factor into the original delegation choice.
Either way I’m interested to see what engagement from delegators you receive
I was going to write my own post, but you’ve summarized my thoughts very well. There are some glaring issues with this proposal:
There is no evidence provided about whether these side deals are happening, let alone a discussion about how impactful they are if they are happening. We are claiming to have a solution to a problem, but failing to describe and quantify the problem in any meaningful way.
There is zero consideration given to how this might impact Solana’s long term tokenomics.
We are asking validators if they want more money for themselves, without consideration to stakers. Nobody will be surprised when there is almost ubiquitous support for this from them (and I know that you, zantetsu, and a few others are a rare exception to this. Thank you).
Fundamental changes like this need to considered far more carefully and with a far more robust discussion than this proposal sets forth.
This proposal does two things effectively:
Addressing concerns raised:
In my view proposals should be small and target specific issues rather than trying to fix a multitude of contentious issues. For a complex proposal addressing many side issues may likely just turn into a stale mate with no progress as different parties prioritise different points within a single complex proposal.