Idea: 'Default Proxy Vote Pool' as a counterforce to concentration of power and vote-buying in EOS

There is a continuing discussion as to whether small-EOS-holders are disadvantaged by the six-month lockout rule for EOS staked for voting.

The lockout period is designed to prevent harmful voting, then selling EOS and not being exposed to the effects of that voting.

The 'Founding Fathers', or block.one, still hold the reigns for the setting-up of EOS until the community takes over on June 1. It is preferable that as many issues are cleared up as possible before launch, including issues related to governance. block.one have, in a way, stated a preference for a shallow, broad distribution of power. They have signalled this intention by their crowd-sale design, namely, that it is over the course of one year and has a minimum buy-in of only 0.02 eth. It is a given that the intent of this design was for the benefits a shallow, broad distribution of power brings.

It does not add up that the voting system, to be in place from the get-go, undermines this intent.

Let's suggest a small-EOS-holder proxy vote pool is established, to where unstaked EOS of small holders go by default. The voting of this pool would be specified by an internal constitution stating that all voting is to tend towards the interests of small holders, which by inference, would mean to a broad distribution of power. This produces several problems. What is a small-EOS-holder? Below 100, 1000, 5000? And what about the unstaked EOS of holders above that threshold?

It can be assumed that large-EOS-holders are much more involved with the utilization of their tokens, so as the number of EOS a holder has goes up, the less likely they are unstaked. This phenomenon can be partway explained by what Dan Larimer calls 'Rational Ignorance' in one of the videos by EOS Go. For this reason, a Default Proxy Vote Pool destination for unstaked EOS could rather be established not only for the EOS of small-EOS-holders, but for all unstaked EOS.

What about the internal constitution of this Default Proxy Vote Pool? What governs how it votes? The answers to this might be found already laid out in black and white in the minutes-of-the-meetings held when block.one was deciding on what kind of crowd sale to use. As said above, block.one, as the Founding Fathers, staked their intentions for what shape EOS should take by that very selection of that crowd sale design. For simplicity, and for acceptance of this model, this Default Proxy Vote Pool could also have in its internal constitution the specification that it abstain from all voting on issues not directly related to dispersal of power. Being governed by a constitution focused on the health of the EOS ecosystem would also mean it uses its votes to deal harshly with vote-buying and kickbacks, which are activities inherently implicated in the concentration of power.

A feature of this default proxy vote pool would be the abolishment of the six-month lockup period. How can this happen? The six-month lockup period is designed to stop voting-and-running. The fact is, the EOS in this Default Proxy Vote Pool does not have the ability to move en masse like the EOS of one, or a group of large-EOS-holders has. In spite of this, they are subject to the same confinements of a large holder. There will always be a floating number of EOS in this pool, which changes over time. There will never be harmful voting, governed by the constitution, and never mass flight of EOS. If all Block Producer candidates show benevolent intentions with regards to dispersal of power, votes are spread evenly between them. In effect, this pool, by their combined holdings, now has the power of a whale, while representing small holders and power dispersal, but it does not have the same limitations as it does not pose the same risk.

The article, 'Universal Suffrage for DApps - a proposal by Eva Stöwe' has rightly pointed out that Dapp makers are at a disadvantage in the voting process. In this article, it is proposed that Dapp creators have voting based on resource allocation. For simplicity, although not proposed in the article, let's suppose the Dapp creators can use all their EOS staked for any resource for voting. That, with the unstaked EOS in the Default Proxy Vote Pool put forward in this post, together with EOS staked to voting by large holders, starts to look like a one-EOS-equals-one-vote environment. The only EOS unaccounted for are ones rented out to make a profit. If it is decided that the lessee of these EOS, which are the Dapp makers, can also use these EOS to vote, then all EOS are accounted for and it becomes a one-EOS-equals-one-vote environment. The system outlined here does not rule out the system proposed in the Eva Stöwe article. Elements can coexist. However that system does introduce a heightened level of complexity by incorporate a sliding scale of the power of one EOS regarding voting, meaning a move away from the simple one-EOS-equals-one-vote paradigm.

This post invites many questions such as, who runs the Default Proxy Vote Pool and how are they reimbursed? These questions are not insurmountable. The main thrust of this post was to show the possibility that small-EOS-holders, by virtue of just holding EOS, can add value and participate in the ecosystem through proxy voting while avoiding the six-month lockout period, without enabling the vote-and-run phenomenon.