The management of the Worker Proposal fund has been under a lot of discussion lately - and for a good reason. The eosio.saving account that is supposed to be distributed for funding Worker Proposals generates about $20M USD monthly (at current EOS prices).
The most straightforward way to distribute funds in the Worker Proposal fund would be by having everyone vote on each proposal through the referendum method that is to be implemented soon. Of course, with so much money to spend, we can all imagine the amount of proposals that will be coming in. Can we really expect each voter to look at all of these projects individually and take an informed decision?
Delegation comes to mind, but statistics disagree. Data from Steem and BitShares shows that very few people users vote through proxies. So unless we want to close our eyes and hope for the best, we shouldn’t count on this to solve scaling.
Perhaps we can solve this by creating an organisation that takes care of this fund? Perhaps something similar to a government of a real-world country that is elected by the token holders and takes care of the budget? Sure, we can try to do that, and it will probably be much better than any current government’s cabinet because we have a great community and great tools to ensure transparency and accountability. But there is still chance for corruption, misuse of funds, and plain old inefficiency.
Instead of creating an official gatekeeper of the fund, I propose that we solve scaling by looking at a different vector - amount of proposals to be voted on. Proposals can be batched into different types: marketing, dapp development, core software updates, Todor’s cool ideas, insurance fund, etc. You get the idea. We could submit these batches to community votes instead of individual proposals, and then get each “batch” to propose a way for managing it. If they come up with a good way to do that, it will be more likely that they will win the referendum and get a portion of the fund to distribute around.
So the community will get to approve these different departments separately, but each of them will be responsible for properly distributing its own budget between individual proposals. Each of these microfunds will be transparent and accountable, because, if they are not, they will be voted out.
One valid concern is that we may get a less efficient system because some of the microfunds will compete with each other. Two or more microfunds may receive fully or partially overlapping proposals, which could lead to inefficiencies. Additionally, microfunds constantly competing for a larger piece of the pie to prove their relative importance may lead to abuse. This has to be weighed in against the possibility for abuse by a fully hierarchical system - with a single organization at the top that controls all its divisions and subdivisions. It’s hard to say which option is more likely to be abused, so we should settle for a mechanism to adjust how flat the structure is. This can be achieved through changing the voting threshold level for accepting/supporting separate microfunds. The higher the threshold, the fewer microfunds we will have, getting closer to a more hierarchical system. A few years from now we will have enough data to adjust this parameter to what works best.
We will also need an “oversight” proposal - one that receives reports from these microfunds, investigates them, and reports back to the community. Or maybe several independent oversight organizations. More importantly, the community will have much fewer proposals to consider for funding, and we can expect much better voter turnout.
With time, this two-layer approach may turn into multiple layers. Microfunds may create their own structure of sub-funds, perhaps with separate voting structure and decentralized micro-governance. This is the right approach to scaling - break everything down into layers. We just need to create the right system infrastructure to support this.
