EOS.IO is an operating system created for business on the blockchain. All software in its first release has bugs, requires patches, and requires ongoing strategic development. Who will be responsible for providing support for the maintenance of this operating system? How do we add on new features as desired by the community?

Currently, the community relies heavily on the block producers. They are an incredible group who has taken on more than intended, and they should be allowed to focus on producing blocks securely. Similarly, there are many volunteers working away to build this grand venture, but voluntary support on its own is not sustainable for the long-term health of an enterprise decentralized platform. Block.one gave us an admirable beta release. Now, for the EOS Mainnet to reach its full potential, we must fully utilize the power of the larger community. Block.one promised a number of key features that have not come to fruition yet and we, the EOS community, need to take responsibility for them. These include: properly funded core arbitration, account key recovery, IPFS-based storage, referenda tools, clear UX, and a functioning Worker Proposal System, to name a few.

The Core WPS Working Group is working to build a set of tools and a proposed set of rules and guidelines to be utilized towards this goal. By using a portion of the inflation to support necessary projects, we can improve the utility of EOS and its overall adoption. Therefore, we appeal to every member of the EOS community to support the Worker Proposal System, and together help allocate these funds to further accelerate the growth of the EOS blockchain.

Why do we need WPS?

EOS.IO has several improvements to be made and some features are still missing. However, due to the decentralized nature of EOS, there are not enough incentives for individual community developers to spend their time contributing patches and upgrades needed for efficient and scalable advancements. To ensure that EOS.IO keeps up with the changing needs of the community, a Worker Proposal System was introduced in the initial design of the software. This would allow for an allocation of funds to be reserved that could incentivize developers to work on community needs, critical patches, and forward-looking upgrades. This allows the system to fully utilize the strengths of a decentralized community going forward, reducing the reliance on a single source for these new additions. Block.one has given the world a great starting point for the tool, and the Worker Proposal System will allow the community to nurture and grow that tool.

Plan

September/October — Execution of the First Referendum

The first referendum allows the community to authorize the following actions:

1. An amount of 1 million EOS tokens is transferred from the eosio.saving account to a new account, eosio.wps. This fixed amount can only be used for the purposes of what is initially proposed. No one party or individual will have control over these funds. The program is designed in a way that anyone in the community can participate and help decide where these funds are to be allocated. The breakdown of the usage of this amount can be seen in a related article about budgets. This funding is to last for six months, or until the Emergency Committee is dissolved.
   
   
2. The Emergency Category is established along with the Emergency Committee. The Emergency Committee only exists in order to help review and prevent non-legitimate proposals and frauds from going on vote. This category is based on urgent needs rather than a specific type of project. This is the only category included in the first referendum but it will be used to help launch other categories.
   
   
3. From this fund, budgets included in the initial referendum will be allocated to support the EOS.IO Core Arbitration Forum (ECAF) for six months, EOS Mainnet code repository management, the Mainnet security testing, and further development of the Worker Proposal Portal.

November/December — A Governance Competition

The Emergency Committee announces a competition for governance design of each category of works. This concept is to allow for experimentation with governance without risk to the entire system.

January-March — Categories are Voted For

Referendums for each category, along with a party responsible for overseeing it, will be held within the community. As each category is voted for, the category in question becomes active, and proposals that fall under that category can be submitted. There will me a cap on the amount of funds that can be allocated within each category, in order to ensure fairness across different categories and limit potential abuse and/or waste. Furthermore, there will always be a portion of the worker proposal fund remaining, allowing room for future growth and a safety net in case of an emergency need of community funds, if and when token holders decide on it. When the category goes live, the Emergency Committee surrenders control over relevant proposals. Over time, the Emergency Committee ceases to exist as its duties are absorbed.

Proposed Categories

Oversight

This category is for WPS portal maintenance, quality control and oversight of other categories. They also help validate the vote tallies on the databases as well as supporting any proposals that go through direct referendum instead of applying to one of the categories.

Infrastructure

This category is for supporting the underlying code base of the blockchain. This includes security audits, DDOS protection, bug patches and mainnet repository maintenance.

Community

This category supports the resources and spaces that bring people together. This includes meetups, educational content and platforms, public relations, lawyers, advocates and lobbyists.

Development

This category is for supporting developers and ideas. This includes support for decentralized applications and applications that may be necessary for underserved minorities.

Miscellaneous

This category is for swag, burning, and projects that may not fit in other categories.

Fund Approval Process

The fund approval process happens as follows:

Addressing Concerns

We would like to address four major concerns:

• Whales will vote for personal interests.
• $400M/year is too much money until proven useful, 4% is too high of inflation.
• A new centralized group will be ineffective and waste money.
• Block Producers or Block.one can pay for these projects instead of WPS.

Whales will vote for personal interests.

Large stakeholders will vote for personal gain, this is inevitable. This is the same challenge that we face for block producer elections. Nevertheless, as a decentralized Worker Proposal System, the design must still ensure that anyone can be part of the process. The community would not want to block the next great idea because it comes from an unexpected source — in fact, the existence of whales should not prevent the endeavour of designing a sensible worker proposal system. Therefore, in order to prevent fraud, there will be a reviewer system in place; the reviewers responsible for each category will help discern clearly non-legitimate proposals, solely based on an objective and public “proposal checklist”.

$400M per year is too much money until proven useful, 4% is too high.

The goal of the Worker Proposal System should be to spend wisely in ways that benefit and enrich the whole community. There is no need to spend it all. In fact, our first proposal for referendum is to move only a small, fixed amount from the eos.saving account to the worker proposal account (eosio.wps). This will be less than 20% of the eosio.saving account. In the future, the community may even suggest a proposal for burning surplus funds in the eosio.saving account. We are proposing to start the WPS system with a very contained and risk-reduced environment.

A new centralized group will be ineffective and waste money.

With the current design of the Worker Proposal System, no centralized party has control over the funds. As it is programed, the eosio.wps account is community owned, meaning that those funds can’t be accessed without proposal reviews and votes. The main purpose of the Emergency Committee, and other categories in the future, is to remove malicious proposals from being passed on to the community. It is to manage the input of ideas and defer projects that do not fit clear public criteria.

Block producers or Block.one can pay for these projects instead of WPS.

Block producers and other groups such as Block.one will continue to produce exemplary work for the community. Companies can be very efficient in developing resources. However, a community-managed fund can support projects that are not a priority for block producers or private companies. For example, who will fund the management of the github repository with indifference? Who will support the arbitration forum (ECAF)? These projects add value to the community as a whole, but are not profitable on their own. No independent business would fund these vital projects, as there would be little to no ROI, nor should some of these endeavours be built with the need for a return.

We believe that most people support a worker proposal fund; it is the control of a large amount of money that concerns them. That is why we believe in a conservative approach to designing the system, with only a small amount of funds to be available to begin with.

Support a Place to Fund Innovation

Since the introduction of the worker proposal system in the EOS.IO whitepaper, WPS has been a symbolic pledge for a blockchain that funds innovation that fuels the growth of the ecosystem. We call for participation in the EOS community, to come together and support the launch of a Worker Proposal System. Progress demands forging into the unknown and here we stand before the dawn of WPS!

Thank you.

From Current Working Group:

System Design Group

Thomas Cox, David Margulies, Josh Kauffman, Branden Espinoza, Todor Karaivanov, Orchid Kim, Domenic Thomas, Chris Pollard, Larry Ma, Mao Yifeng, Joseph Fanelli, Leo Seo

System Development Group

Jae Chung, Hugo Campanella, Adrian Hunter, Boram Kim, Thomas Do, Syed Jafri, Alfred Cheuk, Sheldon Huang, Abbas Ali, Kedar Iyer, Harry Kim, Sungmin Ma, Darren Tay, Michael Yeates (advisor), Eric Björk (advisor), John Milburn (advisor)

Community Support:

• Nathan James (Scatter)
• Cesar Rodriguez (Nebula Protocol)
• (Gathering Supports in progress)

Link to FAQ, addressing anticipated concerns

Link to WPS telegram channel