Who should vote for Worker Proposals?
To date, every proposal for a voting system Worker Proposal has assumed that the voting mechanism will be the similar to the voting mechanism used for electing Block Producers. Distributing the EOS savings fund is a different use case though, and there is no inherent reason to keep the same voting scheme for managing it. In this article, I will propose what I see as a more fair, more secure, and overall better way to vote for Worker Proposals - one that allows every token holder to directly control the part of the savings fund that they individually contributed to.
The source of the Worker Proposal Fund (WPF) is newly created tokens, generated through inflation. From a purely economic perspective, this means that all token holders lose a little value, proportionally to their holdings, in order to contribute to the common fund. It would be only fair that token holders are able to control how this fund is spent proportionally to their contributions.
Currently, holders are not able to vote for WPs unless they stake their tokens for NET or CPU. This implies that some token holders are not going to be able to vote proportionally to their holdings because their tokens are unable to be staked for varying reasons - being locked in the RAM contract (or any other user contract that locks up tokens), liquidity, etc.
Tokens that are locked for NET and CPU are able to vote at this time, which covers only some of the possible ways to use the network. This gives an unfair weight for WP voting to two specific groups of the chain users - the dapps and the rent-seeking holders (who stake NET/CPU for other users).
Given that the fund does not belong only to these specific groups of users, but to all token holders, a case can be made that all token holders should be able to vote on how to control it instead of just the above-mentioned specific groups of users. One possible concern with such an implementation would be that this makes the system more vulnerable to abuse. I would argue that this is not true, and that, on the contrary, a system can be devised using this approach that is more secure than the currently proposed system.
So, what about security?
The idea that tokens can be used for voting without any lockup period does not enable bad actors to attack the system without having skin in the game. Token lockup periods can be countered by shorting via derivatives either way. Therefore, removing the lockup period as a requirement to vote does not decrease security.
Furthermore, if ALL token holders are able to vote without any restriction, we would likely see higher voter turnout (even though it can be argued how much higher), which, coupled with appropriate voting thresholds, will increase security against perverting the WP system into a method for passive income by large token holders. With higher voter turnout it takes more tokens to pass a WP single-handedly or through cooperation with others - there are simply more tokens to vote against.
A fair system that enables all token holders to vote for WPs needs to provide for the entropy of token ownership
Tokens change hands daily, and the length of time during which a user has owned a token needs to reflect on their voting power. This also means that such a system should not unconditionally approve projects for funding for future periods without the funds having already been collected from their respective contributors, as we don’t know how exactly tokens will change hands in the future.
A good system would provide token holders with voting power proportional to the funds that have already been generated by their holdings
Let’s dive into an example: Alice holds 100 tokens for a year and then sells them to Bob, who holds them for another two years. The WPF has generated a total of 12 tokens from these 100 tokens during these three years. This should give Alice a voting weight of 4 (4% annually from 100 tokens for 1 year), and Bob a voting weight of 8 (4% annually from 100 tokens for 2 years).
The system also needs to account for spent tokens and how they affect the voting power of users. One possibility is to account for the funds consumed by the Worker Proposals that were voted in and reduce the voting power of the users who supported that proposal proportionally on their previous voting power. In the above example, if a proposal came in that required 2 tokens, Bob voted YES with his 8 voting power and Alice voted NO with her voting power, we would reduce the voting power of Bob by 2 (assuming noone else voted), which would leave him with 6 voting power and Alice with 4 voting power. This makes it fair to both Bob and Alice - Bob supported the project and Alice didn’t.
What about the rest of the token holders - the ones who didn’t vote?
The above method equates their indifference to voting NO, at least with regards to how their voting power is affected. A good system might take a different approach and reduce the voting power of indifferent users proportionally to their own voting power as well, which would incentivize a lot more holders to vote.
Let’s upgrade our example a bit. Let’s say the Alice has 1m voting power, Bob has 2m voting power, and the rest of the voters have 8m voting power. A proposal comes in that requests 1m. Bob votes YES, Alice votes NO, the rest are silent, and the proposal is accepted. 1m is deducted from the fund, Alice’s voting power remains at 1m, and Bob and the rest of the holders get their voting power reduced proportionally - Bob will now have 1.8m voting power and the rest of the voters will have 7.2m voting power. The total amount of voting power is now equal to 10m, 1m down from the previous total amount (as 1m has been spent for this proposal)
Here is the formula used (for the curious reader):
A = total power of users who voted NO
B = total power of users who voted YES
X = total power of the users who didn’t vote
Y = amount of funding for this proposal
A' = A (doesn’t change)
B' = B(B+X-Y)/(B+X)
X' = X(B+X-Y)/(B+X)
This method is slightly less fair to apathetic voters, but this in itself has the benefit that it incentivizes everyone to vote. As argued previously, this increases system security because more tokens being voted makes it harder to abuse the system.
An obvious advantage of this system is that it enables instantaneous voting. There is no longer a need to sustain a vote, as vote power generation is taking care of quick buy-vote-sell schemes. This also increases the security and fairness of the system.
Are there any problems?
One potential problem with this system as that users might want to vote strategically with their tokens in order to preserve their voting power. If Alice approves of a project but she sees that it will be accepted anyway, she may choose to VOTE no so that her voting power is not diminished, while the project is accepted anyway. To mitigate this, projects can be rated upon completion by several independent agencies. Project rating results may be used to financially incentivize users who voted YES for that project. This way, all users would be incentivized to vote YES for a project they believe likely to be rated favourably. This also encourages educated voting by users and increases the quality of approved projects.
Another potential problem is the system being abused for passive income. To mitigate this one, token holders would have to agree that it is undesirable, ideally through a referendum. If it is decided that such an option is against the purpose of the WPF, proposals and/or voters that attempted to abuse they system may be subject to arbitration if they fail to follow this agreement. Setting higher thresholds for accepting proposals will also make it harder to abuse the system in this way.
Final thoughts
A simpler version of this system will reduce voting power of everyone proportionally, thus eliminating some of the complications. To ensure a successful implementation, a balance must be achieved between fairness and complexity. Determining the right balance is not an easy task though, and should be debated. What do you think?