Should Block.one Vote? A Case for Increasing Vote Cap from 30 to Unlimited

7 min readOct 15, 2018

On October 14, the CEO of Block.one, Brendan Blumer, called on Block Producers (BPs) to solicit the EOS community vote in a personal tweet. Earlier this month, Block.one also hinted they “may, as [they] deem appropriate, vote with other holders to reinforce the integrity of this [election] process”.

It is clear that Block.one is gearing up to vote with their staked tokens, which as of October 15, amount to approximately 100M EOS. While we encourage the decision by Block.one to join the greater EOS community in becoming a voting member, we realize this decision has major implications for the network and for BPs on either side of this vote. Block.one knows this too, as evident in their June 28th news release titled “Block.one’s Participation as Voting EOS Community Member”. In similar fashion to Brendan’s recent tweet, this post prompts BPs to campaign for Block.one’s vote. While this post outlined the criteria for quality Block Producers, it also included the following paragraph:

“To facilitate maximum community choice, Block.one recommends that the system contract be updated to support approval of 50 producers per account compared to the 30 currently allowed. Block.one plans to identify and cast our approval for as many qualified producers as the code will allow.”

This change was never made, and the issue fell silent. Why was their plan to vote tied to this request to increase the voter cap?

Analysis of a Block.one Vote With Current Voter Cap

In modeling a Block.one vote with the current system contract, we have made the following simplifying assumptions:

A snapshot of BP voting was taken in early October
No other votes will change in response to Block.one’s vote
Block.one will vote for 80% of the current top BPs (and exclude 20%)

Given these assumptions, a Block.one vote has the following consequences:

Daily EOS rewards are concentrated on the 30 BPs who receive the vote, with the Top 21 earning 20% more than they currently do.
A large “pay cliff” is created between #30 and #31 that currently does not exist.
The tail of eligible paid BPs is drastically shortened and reduced. Over 40 BPs receive substantially less pay with over 25 BP teams losing their pay entirely.

This quick analysis highlights why Block.one was hoping to raise the vote cap in late June before they voted. While there are many benefits to having them participate in community elections, there are also obvious drawbacks given the current system.

Should Block.one Vote? — Pros & Cons

Pros

Keeps BPs accountable to a large, engaged, and impartial stakeholder
Reduces the influence of other large token holders
Creates a large deterrent to actions that harm the long-term value of EOS

Cons

Concentrates the BP rewards on a select few
Reduces the diversity and health of the Stand-By BP community

Block.one’s vote will have a large impact on BP pay for three reasons:

Block.one cannot move their tokens from their single account so their vote will be heavily concentrated on a select few BPs. Currently 30.
With currently 25% of tokens voting, Block.one’s vote will be a significant percentage of votes cast.
Voting concentration is the largest driver of how BP pay is calculated.

The benefits of a Block.one vote are clear, but is there a way to mitigate the downside to hardworking BPs who don’t make the cut?

Analysis of a Block.one Vote With Increased Producer Voting Caps

Vote Cap: 50

In June, Block.one proposed increasing the voter cap to 50, likely to mitigate their impact to BP pay illustrated above.

This chart displays Block.one voting with their proposed increase to 50 producers. This scenario already looks very different.

The rewards in the Top 21 are more or less the same with the current snapshot.
The pay cliff is pushed back to #50/51, keeping more Stand-By BPs in financially viable situations.
However, there is still a financial pay cliff created and the tail is shortened, leaving over 20 BPs without pay compared to the current distribution.

The large difference between these three scenarios shows what a big impact an arbitrary vote cap number can have in the presence of a Block.one vote. Even the proposed increase to 50 still has a large detrimental impact to dozens of hardworking BP teams. In an effort to find a solution that reduces the impact of Block.one’s vote as much as possible we have modeled the following scenario.

Vote Cap: 80

Arbitrarily setting the voter cap to 80 (roughly the number of BPs currently in a paid position) we come up with the results above. Factoring in a Block.one vote, this scenario is the closest we can model to the current snapshot, although some differences still exist:

The Top 21 make less than they do currently.
Stand-By pay is flattened. The difference in Stand-By pay between #22 and #80 is drastically reduced.
Out results don’t account for the fact other large voters would also vote for 30+ BPs.

The Case for an Unlimited Producer Voting Cap

Given these results, the voting cap should be increased from 30, especially assuming an impending Block.one vote. However, any proposed number will be arbitrary in nature. These models may accurately reflect the math involved in calculating BP pay, but as the cap rises, our ability to model outcomes requires more and more assumptions about how Block.one and other token holders will vote.

In their own words “Block.one plans to identify and cast our approval for as many qualified producers as the code will allow”. But increasing the cap to 80 does not guarantee they designate 80 BPs as “qualified producers”.

Instead of increasing the cap to yet another arbitrary number, why not remove it entirely? In all the scenarios we modeled, Block.one’s vote becomes a “white-list” which creates a stark contrast between the BPs that receive their stamp of approval and those that don’t. If they are gearing up to vote regardless, we should facilitate this white-listing by allowing Block.one to be as inclusive as possible.

Empowering Proxies with Unlimited Voting

The benefits of unlimited voting are not exclusive to Block.one. Currently there is a large contrast in voting patterns between unengaged community members who find the process of voting for even a handful of BPs onerous and time consuming, and community experts who can easily fill up a list of 30 BPs often leaving some solid teams off their list. The ability for the average token holder to outsource their due diligence by proxying their vote helps increase voter engagement, and this should only increase going forward.

There are several proxies unaffiliated with BPs that are working full-time to perform due diligence for the community, continuously vetting BPs and keeping their proxy lists up-to-date. Investing With a Difference, Freedom Proxy, and Mereo Proxy to name a few, all have full rosters, meaning they are working to choose the 30 “best” BPs from a larger list of “good” BPs.

Unlimited voting would change this dynamic. With an unlimited voting cap, proxies could become specialists. Like Block.one, proxies can also become white-lists, who specialize in a certain area evaluating specific criteria, such as “full ownership disclosure and a working website”. While this might seem like basic criteria for BPs to reach, there currently is no way to enforce these requirements, and several BPs in paid positions are collecting rewards while violating the constitution in various ways.

With unlimited voting, a proxy could add any and all BPs that meet some basic prerequisites instead of only the “best 30”. If enough votes are delegated to these proxies, token holders can enforce compliance all by themselves, while leaving the exhaustive research to the specialists of their choosing.

Summary

With low voter participation, the few large token holders who are voting have an over-sized impact on the network. If nothing else, Block.one’s presence will double voter engagement and reduce the ability for any stakeholder to game the system. On top of this, having an engaged token holder white-list quality BPs can be very beneficial for the EOS community.

All indications point to an impending Block.one vote, yet by their own admission voting with the current cap will create some unintended consequences shown in the analysis above. Increasing the vote cap mitigates these impacts while maintaining the benefits of Block.one becoming an active community member.

After taking a close look at several scenarios, EOS Cafe Block believes the best limit is no limit at all, and have submitted a PR to Github to remove the voting cap entirely.

If you agree with this conclusion, or if you disagree, please share your thoughts in the comments below, or in our telegram group. If you support this position please share this post, and don’t forget to vote for eoscafeblock.

Telegram — @eoscafeblock
Twitter — @eoscafeblock
Medium — @eoscafeblock
Steemit — @eoscafeblock
Website — www.eoscafeblock.com