Open in app

Sign in

Write

Sign in

EOS COMMONS DEVELOPMENT FUND PROGRAM

David Margulies
EOS Worker Proposals
Published in
12 min readJan 2, 2019

(AKA PLATFORM DEVELOPMENT FUND, AKA WORKER PROPOSAL SYSTEM, AKA WPS)

Proposers

Anand, Gautam
Buck, Justin
Espinoza, Branden
Karaivanov, Todor
Kauffman, Josh
Lee Kiho
Kim Naeun
Ma Larry
Mao Yifeng
Margulies, David
Pahalahti, Samuli
Pollard, Chris
Seo, Leo
Shi, Ricky

Describe Initiative / 提案描述 / 제안 요약

This proposal is to fund a 6-month bootstrap stage EOS Commons Development Fund System. / 本提案旨在资助为期6个月的启动阶段的EOS公共发展基金系统。/ 이 제안은 6개월간의 EOS 공동 개발 펀드 시스템 부트스트랩 단계를 위한 것입니다.

Our goal is to create a mechanism to fund a portion of the innovation and advancement of the EOS network, and do so in a transparent manner, utilizing community-directed funds, while addressing and reducing the risks of systemic fraud. / 本提案旨在资助为期6个月的启动阶段的EOS公共发展基金系统。我们的目标是建立一个机制，以透明的方式资助EOS网络的创新和发展，利用社区导向的资金，同时消除系统性欺诈的风险。/ 우리의 목표는 EOS 네트워크의 혁신과 진보를 위한 펀드를 제공하는 메커니즘을 만드는 것입니다. 그리고 이를 위한 투명한 방법과 커뮤니티 규제 하의 펀드 운용을 통해 체계적인 사기를 대처하고 미연에 방지하는 것입니다.

The Official language of this Referendum will be English: all efforts have been made to translate accurately to other languages for ease of understanding, but English is the prevailing language in case of dispute. / 本次公投的官方语言将是英语:为了方便理解，我们已尽力准确地翻译成其他语言，但在发生争议时，以英语为主。/ 국민 투표의 공식 언어는 영어가 될 것입니다. 물론 쉬운 이해를 돕기 위한 노력으로, 다른 언어로의 명확한 번역이 이루어질 것이지만, 주요 언어는 영어일 예정입니다.

State Question / 官方问题 / 공식 질문

Should the EOS mainnet establish the EOS Commons Development Program as outlined in this referendum? / EOS主网是否应该像公投中描述的那样建立EOS公共发展计划? / EOS 메인넷에 이번 국민 투표로 제시한 EOS 공동 개발 펀드 프로그램을 설립해야 할까요?

· Yes, I vote to establish the EOS Commons Development Program. / 赞成，我投票赞成建立EOS公共发展计划。/ 네. 저는 EOS 공동 개발 펀드 프로그램 설립에 찬성합니다.

· No, I vote to reject the EOS Commons Development Program. / 反对，我投票反对建立EOS公共发展计划。/ 아니오. 저는 EOS 공동 개발 펀드 프로그램 설립에 반대합니다.

Interpretive Statement (What a Yes Vote Will Do)

The proposal includes:

1. Transfer of Funds.

An amount of 1 million EOS tokens is transferred by the top 21 Block Producers from the eosio.saving account to a newly created eosio.wps account. The purpose of this amount is to fund the EOS Commons Development Program activities for six months. [See Section 7 below for more details on eosio.saving.]

2. Initial Allocation

The first allocation of funding will be immediate and will include funding for

  • Emergency Committee Operations
  • EOS Commons Development Program portal development and management
  • The balance of the initial allocation of 1MM tokens will be held under custody of the Emergency Committee, to be disbursed if, and only if, the community has approved other proposals for funding by the EOS Commons Development Program (as outlined in Article XI of the Constitution).

3. Emergency Committee Operation.

The Emergency Committee is created and formed with the purpose to filter and oversee proposals that go to community vote, oversee the progress of proposals, oversee the use of funds, report Emergency Committee findings back to the community periodically, and assist in the preparation of governance proposals for EOS Commons Development Program Categories.

Updated Budget and proposal links:

Emergency Committee Emergency Proposal Assessment Overview: http://bit.ly/EmCom_assessment

4. EOS Commons Development Program Portal Development and Management.

Portal Development to support the growth of EOS Ecosystem by developing the software and platform for the community to review, discuss, select, fund, and hold accountable projects proposed by community members to benefit EOS; includes the following:

  • Smart contracts for registration, submission, proposal review, and voting.
  • Web platform for registration, submission, forum and voting.
  • Software that incorporates the needs of new categories as they come online.
  • Secure infrastructure to deploy the platform.

Requested EOS on 20190102: ($378,420.00/$2.72)+750 = 139,875

Updated Budget and proposal links:

Preliminary github http://bit.ly/github_draft

5. Recognition of EOS Commons Development Program Categories

The following EOS Commons Development Program categories are established and recognised for future development to allow for the greatest variety of governance options to figure out what works best, while limiting scope for abuse or failure:

  • Oversight — intended for portal maintenance, quality control, and oversight of other categories, as well as supporting any proposals that go through direct referenda instead of one of the EOS Commons Development Program Categories.
  • Infrastructure — for supporting the underlying code base of the blockchain. Examples include security audits, bug patches, and code repository maintenance
  • Community — includes meetups, educational content and platforms, public relations, lawyers, advocates and lobbyists.
  • Development — for supporting developers and ideas.
  • Miscellaneous — for any proposal which may not fit directly into any of the other categories.

6. Open Call for Governance Design Proposals for Individual Categories.

The Emergency Committee will manage a competition for individual category governance structure designs to allow for experimentation with governance without risk to the whole ecosystem:

  • The governance structure for each category is up to worker proposals submitted by the community.
  • Winning Designs are those chosen by community vote.
  • As each category is approved by the community, the category in question becomes active.
  • To become an activated category, the winning submission will be chosen as the one with the highest participation of voting tokens, with no less than 5% of total currency supply, and must maintain no less than 55% Yes votes of the total voting supply, maintained for no less than 15 consecutive days within a period of 60 days.
  • Each active category will be limited to its own financial boundaries,(i.e., 10% of eosio.saving) to limit abuse and waste, and to allow room for future growth if and when token holders decide on it. (See Section 7.)
  • When a category goes live, the Emergency Committee surrenders control over relevant proposals. Over time, the Emergency Committee ceases to exist as its duties are absorbed.

7. Retire the Remaining Balance of eosio.saving.

Until such time as there is community confidence in the various government structures, we propose a recurring retirement of all funds in eosio.saving not allocated to eosio.wps:

  • On day 1, after the initial 1 million EOS tokens are moved to the eosio.wps account:
  • the remainder in eosio.saving will be retired; and,
  • eosio.saving will continue being retired monthly, as it accumulates.
  • Once the Categories have been properly established:
  • 10% of the tokens flowing into eosio.saving per approved Category will be distributed into eosio.wps.
  • Full description: http://bit.ly/eosiosaving_burn (NB, external document reflects a previous intention to bundle ECAF and Mainnet Repository Maintenance. This coupling is no longer planned. However for transparency we will not edit already published documents unless required for accuracy.)

Block Producer Instructions

  • Create a multisig proposal to create an account named eosio.wps with 10 EOS staked for Network bandwidth and 100 EOS staked for CPU bandwidth and 1500000 bytes of RAM
  • The eosio.wps account structure should be crafted with owner permission designated to eosio@active and the active permission set up as a 4 of 7 multisig, with keys provided by the 7 members of the EmCom.
  • Create a multisig proposal to transfer 1 million EOS from eosio.saving to eosio.wps
  • Create a multisig proposal to retire the remaining balance of eosio.saving after the transfer of 1 million tokens has been executed
  • Every 30 days following, a new multisig proposal shall be put forward by the EmCom to retire the unallocated funds within eosio.saving

Arguments

Summary Arguments In Favor

  • EOS requires support and development and funds have been set aside for this purpose.
  • CDF is a safe and secure way to bootstrap this support system.
  • Public goods should be funded by the commons.
  • Decentralization and separation of powers requires an independent CDF.

Summary Arguments Against

  • EOS Inflation is too high at 5%; no development or support is needed so inflation should be reduced to BP rewards.
  • A Commons Development Fund to handle development is a central bureaucracy; instead the money and duties should be trusted to the Block Producers.
  • DPoS does not work; individuals who hold the most tokens have the greatest voting power. Whales would use a fund like this to just vote themselves money.

Arguments In Favor

Public Goods must be supported by the community. As explained in the EOSIO whitepaper [http://bit.ly/eosio_whitepaper], by using a portion of the 4% inflation set aside to fund necessary projects, we can increase and improve the utility of EOS and its overall adoption. This referendum is intended to do the minimum needed to bootstrap the EOS Commons Development Fund. We acknowledge that there is a risk of the CDF getting abused by greedy whales for their own projects. That’s why we start with a small percentage of the available funds and burn the rest. If it turns out that the CDF can’t be used effectively for the benefit of the whole community, only a small amount of money is lost, but we will have learned possible abuse vectors and would be able to account for those in future iterations of the system.

There are systemic irritations on EOS that we could fix or improve, desired features we could add to EOS, and public dApps that would greatly increase system utility and attract new demand. The problem is that often such things benefit everyone, but not so much that anyone alone would have incentive to create them. In such cases, a collective will must create a common good.

Block.One wrote about a number of key features in the EOSIO whitepaper: arbitration, account recovery, Inter-Blockchain Communication, distributed storage, referenda tools, to name a few. Due to internal decisions made by Block.One, these tools have fallen to the community to develop. It seems safest to look to Block.One for ideas and to look to ourselves and the CDF for execution.

We cannot expect block producers or volunteers to take over the role of support, either. We must decentralize the system and decrease reliance on Block Producers. Letting the BPs take more responsibility for the development would consolidate their already very powerful role. Another option, volunteerism, is not a sustainable model for long-term growth. We must enact the provisions for a Commons Development Fund as alluded to in the EOSIO whitepaper. The scope of projects that the community has vocalized a desire for are far-reaching and are too much for single teams to shoulder the cost of. Further, many of these core features are non-monetizable by design. Thus a community-funded approach is the only path forward to see them come to fruition.

Most importantly, if the EOS community desires to have independent governance and/or journalism, it should look into enabling independent funding for it. Any other known methods of funding expose the system to outside influence. The CDF can provide truly independent funding for these critical pieces of the ecosystem.

Rebuttal

Block Producers have done a remarkable job working together to roll out dozens of code patches. Anything beyond these changes needs to come from referendum. To put the power of ‘development and new features’ in the hands of a CDF instead of token holders goes against the spirit of DPOS.

Block producers are paid for their positions and they should be shouldering the cost of these communal goods. They will then be able to advertise that they produced those goods to campaign for increased votes. There will also be free market solutions that arise for many of the problems we face. Someone can come up with a way to monetize the tools we seek, and charge a per-use fee rather than having every token holder’s assets lose value.

The communal funds of the network should not be used as a slush fund for running experiments. There has not been enough evidence to show that a system like this would work as intended. Any failed attempts, over-funded projects, or tokens that end up being used to build out something that the entire community does not directly benefit from comes at a price to every single token holder. A proper system would need to ensure that every token spent would return more value. The plan for how the group will use the money to facilitate the building of these tools is unclear in the proposal. More details are needed about the expected roadmap for this project.

Arguments Against

Using the eosio.saving to fund “Worker Proposals designed to benefit the community” [http://bit.ly/eosio_whitepaper] via an EOS Commons Development Fund Program will devalue all our token holdings through inflation. Inflation on the EOS mainnet is hard capped at 5%. However, only 1% is actually released into circulation as block producer rewards, while the other 4% is held in eosio.saving. Even though this account was created to fund initiatives like a Commons Development Fund / Worker Proposal System, it has really served to lock-down 80% of all inflation, preventing its circulation and therefore preventing EOS token price from decreasing more than it already has. Enabling the community to pull from that pool would decrease token value through inflation.

What EOS needs right now is more users, so funds can be much better spent creating free accounts for new users and establishing URI. When the number of token holders increases, demand for tokens will rise and outside businesses will be attracted to enter the system and invest privately in development.

Further, creating a body to handle the development funds and decide where to direct them is tantamount to creating a central bureaucracy. EOS is a decentralized open-source project and The community is full of open-source builders. EOS tools are being built and offered for free to the community. Further, dozens of base code changes have been signed off by BPs; the BPs are handling network maintenance well, as a part of their normal job description. Nobody is getting paid extra for these things, yet they are all happening. To suggest that the community needs some central body to organize and fund efforts to build and maintain a healthy network, is an insult to the EOS community.

Given the nature of DPoS, individuals who hold or control the greatest number of tokens have the greatest voting power. These whales would use a fund like this to just vote themselves money. Other people will scam the system by not doing the work they promise to do or by creating frivolous boondoggles. The structure of how the funds would be handled, and what they would be used for, need to be more transparent.

Rebuttal

Currently, the eosio.saving account holds in excess of 20,500,000 tokens and increases at a rate of over 100,000 tokens per day. However, the tokens need not be in actual circulation to depress EOS token value; to individuals concerned about the threat of inflation, the existence of those tokens at all poses an ongoing risk to the EOS token value. However, the EOS Commons Development Fund Program has been set up so that the majority of tokens in eosio.saving will be burned — and this includes new inflation flowing into the account. [see section 7] This action forever removes the threat of those tokens depreciating the token value.

Tokens only become available when the token holders decide that the benefit to the system is clear. Token holders do this by approving a Category, allowing 10% of the funds held in eosio.saving to be used to grow the EOS ecosystem. And, even when all five categories are up and running, they can access only a total of 50% of eosio.saving. Since that account equals 5% inflation less BP rewards, total inflation would be effectively capped at 3% (1% BPs + 2% CDF) — 2% less than now.

This is not to say that the 2% potential spending by the CDF would be empty of value. The structure is designed to allow the community to direct spending to improve the overall value of the EOS Ecosystem, which will counteract inflation by increasing utility and demand. Moreover, the category design [See Section 6] is such that it is costly for a whale to hijack a proposal, limits the funds available to steal or waste, and any abuse that is detected is easy to shut down. Importantly, large projects require tranche payments and the achievement of milestones, so even well-intentioned projects that fail to deliver could have their funding stopped if necessary.

When the technology catches up, URI and similar large scale projects can easily be built out and funded by the architecture put in place by and for the CDF. For now though, the system laid out is a temporary structure intended to bootstrap using the smallest amount of funds. Ultimate oversight duties fall on the community to maintain as is proper for the Blockchain; as it should be in the blockchain world. The major design considerations have been to look to the existing open source and blockchain programs and borrow what works, build modular components for flexibility and fungibility, and support the hundreds of developers already laboring to build EOS. The fact that volunteers have been doing more than is reasonable to expect of them is the very reason that they should be supported in their efforts by a functioning Development Fund.

It is important to remember that the community can replace any of the Emergency Committee members — or any of the Category Governance Structures — at any time. This is just like the idea behind Block Producer elections; we trust the community can elect good actors through the DPoS consensus method that EOS is built upon. Just as it’s been proven many times in the real world, delegation, when done well, correlates with efficiency.

Supporting Documentation

Blockchain
Eos
Worker Proposal System
Wps

--

--

David Margulies
EOS Worker Proposals

Written by David Margulies

29 Followers
Editor for

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams