EOSCommunity.org Forums

Stake-based Voting Proposal Feedback

We wanted to take a moment and outline where Greymass stands in relation to the most recent proposal from Block.one, which can be found here:

While the intentions and motivation behind this proposal are good - the approach this proposal takes seems far too complicated. We believe the same objectives can be achieved in a much more elegant manner, both improving the user experience and creating an easier upgrade path. We also feel much of the original intent of staking pools, as outlined in the original proposal by Dan in 2019, has been lost within this proposal which drastically reduces the positive effects it could have on the network. While other benefits arguably still persist in this proposal, we feel it’s important to look at it critically.

To outline some of the critisism above of the proposal on specific topics:

  • Complicated: The proposal as its written is a complete change from how rewards are distributed today. In todays system, the rewards generated by the system itself are all distributed through the REX pool. These rewards include Name Bid proceeds, RAM fees, PowerUp/REX Fees, and potentially more in the future. This proposal changes that path for rewards while rewriting a large portion of the system contracts in the process. This will have unintended side effects both from the User Experience to the Developer Experience.
  • User Experience: EOS token holders have spent the last few years staking their EOS tokens to REX in order to earn a passive return. This proposal changes that dynamic and will now require all of those users to perform a series of actions in order to migrate their currently staked tokens (REX) in to this new system. If this new proposal were to be deployed today, it is our understanding that users would be forceably opted-out of rewards they were expecting until a point in time they opted back in through these new systems.
  • Development Experience: The new proposal alters the system contracts which will require every user interface that interacts with the system contracts to update and follow along with these new conventions. This is a significant investment of time from the EOS developer community which will potentially cause friction and frustration, much like we’ve seen with the transition from REX/Staking to PowerUp.
  • Original Intentions: The original proposal for staking pools included long-term lockups for tokens in exchange for both voting rights and rewards. This was both to incentivize thinking long-term for the network itself as well as to combat manipulation in voting. The proposal as its presented removes the long-term lockup aspect, which diminishes the potential effectiveness of the system to accomplish its original goals.

With that being said, there are still aspects of this proposal which we should proceed with, since they ultimately provide value to both the token holders and the network itself. However, it is our recommendation that instead of approving this proposal, we try to use existing systems to achieve the same goals (even if we, Greymass, don’t fully recognize their benefits).

The REX pool for example could more easily be leveraged to achieve the same goals. Routing this new source of inflation directly into the existing REX pool could:

  • Allow all existing token holders staked into REX to automatically participate in this new rewards system.
  • Prevent unneeded alterations to every EOS application that interacts with these system contracts.
  • Remove the need to rewrite/deploy large portions of the system contract.

EOS Nation has proposed something along these lines which we believe serves as a better starting point for these discussions than the original proposal from Block.one.

Before we wrap this up, we also wanted to take a moment to pull each point of the proposal out and address them. Here are our opinions on the intentions of each point, regardless of the proposed implementation:

Proposal: We are proposing a staking pool system that can directly reward token-holders in exchange for their vote (required) and securing the network.

It is our belief that distributing inflation without any form of effort and/or committment will provide little value. It may provide some level of “marketing” or “attention” benefits to the network, but the overall economic benefit to the network itself and its participants remains mostly an unknown. With how complex this proposal already is on a technical level, it raises the question of if this level of effort is ultimately worth it - of if something more simple like using REX makes more sense.

The idea of creating a secondary flow of inflation is also a positive in terms of decentralization (as outlined in one of our posts on inflation years ago) and additionally serves as a mechanism to encourage voting.

It incentivizes voting by effectively taxing the tokens that do not vote and then rewarding the tokens which do. The effectiveness of this kind of tax is questionable especially when distributed so widely and at such a low cost. It is our opinion that the rewarding of inflation should come at a greater cost than just voting, whether in opportunity (time lock) or in effort (investment of ones time). We originally mentioned systems like Worker Proposals (investment of ones time) as much more effective recipients of inflation, and the recent EdenOS initiatives could fit this category as well.

With the only clear benefit from our perspective being that of marketing, we don’t explicitly support or reject this direction. We have a hard time finding any reason this proposal would have a meaningful impact, but would not stand in the way of its deployment.

Proposal: To reduce this gap we are proposing the removal of bpay rewards and instead propose to distribute all rewards through vpay.

We support the removal of bpay. The original intention of bpay was to help offset additional costs which the top 21 incurred, which in reality is not the situation we find ourselves in today. Running a block producer in any position near top 21 has relatively the same costs associated with it, and with only the top 21 receiving this benefit, puts those outside of this range at a disadvantage.

The removal of bpay helps level the playing field ever so slightly.

Proposal: To help facilitate a healthy distribution of vpay rewards all votes must include 21 block producer candidates.

No objection or support for this voting requirement. Over years of discussion on vote requirements (through Steem, Hive, EOS, etc) no concrete benefit we are aware of has been discovered by setting a minimum number of candidates to vote for.

Proposal: We are proposing that Block Producers who underperform, or fail to produce blocks at their designated time, will create a penalty effect that decreases the total inflation in the system.

No objections. This isn’t typically a problem within EOS - but it would create a feedback loop with engaged voters. If a block producer fails to perform, not only would all block producers see less rewards, but so would the voters within the system earning staking rewards.