Telos User Guide: Understanding Worker Proposals
Creating and promoting a blockchain is an ongoing effort. There will always be needs for new development updates, from small bug-fixes to major new features. There will also always be a need to promote the chain to more users and communities, to educate people about it, to engage in the broader world of cryptocurrency, computing, and society, and even to support the network’s interests through lobbying and legal efforts. As a blockchain grows and spreads, its needs evolve, and there will always be a need to hire people to do a variety of types of work that the users deem necessary. When a network is unable to effectively spend money, it stops growing and begins to die. There are several examples in the blockchain world of projects that failed to provide for adequate development after launch and withered.
Why have worker proposals?
Worker proposals are the way that Telos provides for and selects projects to fund in order to continuously develop, promote, and advance the Telos blockchain. Inflation creates an ongoing source of funds. Any Telos user can make a proposal about how to use these funds and all users can vote on which worker proposals to ultimately fund. Selecting what projects to fund in this manner ensures that the growth of Telos is always guided by the priorities of Telos users.
Ongoing funding through worker proposals is the lifeblood of Telos. There will always be some new security exploit that needs to be patched. Because Telos has custom code for its many innovations, the developers will always have to perform tests on any new EOS.IO reference code released by BlockOne to check for conflicts and correct any that arise. For this reason, Telos has a group of core developers who perform these checks and updates.
It may seem like needing a team of core developers is a burden that less technically advanced chains don’t have to support, but in reality, the fact that Telos has its own core developers in addition to the BlockOne developers working on the reference code is a major advantage for Telos over other EOS.IO chains. It means that we have a group of developers at the ready when problems strike. It also means that Telos can continue pushing the technical boundaries.
Already these innovations have created additional value on the network. Every time the Telos core developers create a feature that does not yet exist on other EOS.IO blockchains, Telos apps have a new opportunity to do things that cannot be done on other chains. Over time this will create not only a large increase in the value of Telos as the technical leader among EOS.IO chains, but it will also let us all, as Telos users, do things that we could not do before.
It’s in the interest of all Telos users to support the core developers and make this an enviable position for developers to aspire to — not only for the prestige, but for the money. Few people can contribute to projects for long without being paid. Telos needs core developers who can afford to stay involved over the long term. If we can make the position of Telos Core Dev consistently well paid, then Telos will attract a large number of talented developers coming up with great new ideas about how to improve the network. (Telos is one of the most inclusive of blockchain development teams; any developer who has the skills and drive can join. Moreover, developers can also propose side projects from outside the core developer team.) Telos will have a deep bench of experienced developers expanding its capabilities, solving problems and improving efficiency. The growth of Telos will not be decided solely by the priorities of the EOS.IO developers. That way, if BlockOne should ever decide to stop developing EOS.IO or if they take it in a direction that Telos users no longer believe in, Telos will already have a strong team at hand to keep building our blockchain.
Ongoing development, then, is arguably one of the most important areas to fund with worker proposals. But there are other priorities as well: Promotion of the network is also of vital importance; As is education; As is continuing to provide free accounts to new users. In fact, there are many types of uses for these funds and it’s impossible to foresee all of the possibilities that may face Telos in the future. This is why there are few initial rules in place about what can or cannot be a worker proposal, and no selection committee.
Telos worker proposals
A worker proposal itself is quite simple: a person or team who wants to do work for the chain (or already have performed work without being paid) writes up a proposal for the work that they would like to do (or have done) and ask for funds from eosio.saving to pay for this. The proposer submits this document from their account using Sqrl wallet or another portal. A worker proposal submission is made of this document, which is uploaded to TIPFS decentralized file storage, and an amount that will be paid to a designated Telos account if the voters decide to approve it. The transaction can also include multiple recurring payments (one per 29-day “cycle”). The voting on the proposal must continue to be approved by voters with each cycle in order to be paid. Because the worker proposal system (WPS) is built on smart contracts, any proposal that is voted in will automatically be able to execute its proposed transaction upon the end of the election. There’s no human intervention in the system other than voting.
The funds for the WPS comes from automatic daily inflation. Each day, an amount of new TLOS is generated as inflation and deposited into an account reserved for the WPS called eosio.saving. Telos WPS receives a 1.5% annualized rate of inflation. This is in addition to the inflation earned by block producers for operating the network. Eosio.saving also currently earns some funds from namespace auctions and RAM trading fees, but these may be diverted to support REX in the near future. In the first year from launch, the WPS will receive approximately 430,000 TLOS every 30 days which accrues until a worker proposal is approved and money is spent from the account.
Any user can vote for or against any worker proposal during its 5 million block (29 day) voting period. At the end of the voting, if the proposal has received votes (yes, no or abstain) from more than 5.0% of all available Telos votes and has a simple majority of yes votes over no votes, will pass and the proposer will be able to execute the transaction. As long as there are enough funds in eosio.saving, the transaction will be paid. If there are not enough funds, then the proposer must wait until adequate funds accrue.
Because there are no rules about what can or cannot be proposed, there is always the risk that some worker proposal may seem ridiculous to many Telos users. A worker proposal could demand that money is given to someone who has nothing to do with the betterment of Telos for no good reason. If enough people vote for it, then it will pass. This is why voting is important. Telos users can and probably should vote to strike down these types of proposals.
It’s possible that someone who owns a very large percentage of the TLOS tokensupply could create proposals that just give a lot of TLOS to themselves for doing nothing. If the account controls enough tokens, then it could vote to enable this transaction. This is one of the dangers of having a small number of people controlling a massive percentage of the votes. EOS has not yet created a WPS largely because of this issue. There is a very reasonable fear that the large centralized owners of EOS could just suck out all of the inflation from the EOS system without adding anything of value. Fortunately, this is not a concern on Telos. There are no massive TLOS owners with the power to pass proposals on their own voting power alone. Telos requires a plurality, which allows for this additional freedom in the WPS.
To prevent a massive amount of proposals from clogging the system, worker proposals require a deposit fee of 3% of the amount requested per cycle (50 TLOS minimum). These funds need to be transferred from the account submitting the proposal before the proposal itself is submitted. If a proposal receives more than 0.1% of available Telos votes and at least 20% yes votes, then its deposit will be returned to the proposer.
The origin of the Telos WPS
The Telos WPS was created by the Telos Launch Group and guided by principles that explain why certain decisions were made. For example, accepted worker proposals pay out immediately without needing to hit milestones. This is done to reduce complexity, but also so that people can create proposals and not have to finance the projects themselves and only collect after the project is finished. The TLG wanted anyone to be able to propose and carry out proposals without needing to have the financial means to carry the cost themselves. Otherwise, only rich people and companies would be able to participate.
The Telos WPS does not have any committee or authority to judge whether a worker proposal is “valid” or “worthy” of acceptance. Of course, people and proxies will form and share these opinions within the community, but creating some WPS acceptance board to review proposals would only inject an additional complexity into the system along with the agendas of the people on that board. There would be questions about where such a board would come from and the source of its legitimacy. It is simpler to use the direct democracy of the Telos voting system.
There is recourse for worker proposals that are accepted but do not deliver on their promises. The block producers can decide to file an arbitration against the proposer and present evidence to an elected arbitrator about why funds should be returned. The arbitrator would then decide. The reason this responsibility was placed on the block producers instead of any Telos user is that it prevents harassment from users who may not like how a project came out, or just don’t like the proposer, as opposed to really protecting the chain from unrealized promises.
The ultimate protection, of course, is voting. The Telos WPS was informed by the WPS of the Dash cryptocurrency. That system evolved over several years, so its strengths and weaknesses were apparent. Its biggest weakness was that only Dash masternode operators could vote. (Masternodes are a proof of stake mechanism where someone who holds 1,000 DASH coins and operates node software gains inflation payments and voting privileges.) Telos addresses this plutocracy problem by opening voting to every user.
One thing that can be learned from looking at the Dash WPS is how proposers can effectively advance their proposals. Because funds are delivered in full and with limited ability to retrieve them from bad actors, passing a proposal requires a lot of trust from the community. There are several ways to earn this trust. One is to perform the work before submitting a proposal. This eliminates the question of whether the work will actually be done. Of course, it also puts the risk of not being paid on the proposer. The first several proposals from the Telos Core Developers, for example, will be using this simply because they have been working on Telos since launch without pay. The Telos Foundation is also likely to pay certain bootstrapping costs and perform work prior to seeking reimbursement to replenish its funds. For proposers not willing or able to shoulder the full cost of their projects before seeking payment, a good strategy has been to start with small projects to convince the community that they will deliver on their promises before asking for larger amounts. People seeking to submit very large proposals would be wise to break them up into several phases with clear deliverables to build trust. Ideally, these deliverables would each benefit Telos on their own, without requiring future steps. Finally, starting out with single-cycle proposals is generally more likely to yield acceptance than multi-cycle proposals — at least until groups are known and trusted. However, multi-cycle voting can be more convenient once a proposer is known.
Ultimately, any problems that the Telos community identifies with the system can be addressed through voting for a governance amendment, and, of course, voting for a worker proposal to fund the development of a better solution.
Current WPS voting
The current version of WPS voting is still at the “minimum viable product” stage. In order to launch Telos and start growing the network, some voting features are yet to be implemented. Voting is entirely functional as of now, but once this new development takes place, it will be improved. This would always be a chicken-and-egg situation where you need WPS to pay for future development of a WPS system. The TLG took the approach of getting a workable system in place that could iterate as time passes.
The current voting system has two traits that may come as a surprise to users and are already flagged for improvement in the next version of Trail voting. First, accounts vote with both their liquid and staked balances. This will be changed to staked tokens only in the future to better match other forms of Telos voting. The other unexpected feature is that, in this version, proxies cannot vote for accounts that have pledged their block producer votes to them. Each Telos account must currently vote for worker proposals individually, even if they have proxied their BP votes to another account.
While Telos users naturally expect all voting to resemble voting for block producers, the fact is that, due to its design, the block producer voting system is not suitable for any other kind of voting. For this reason, the Telos developers needed to create an entirely new voting system called the Trail voting service. This was a major undertaking and the complexity of building this system is the reason why no other EOS.IO chains have had an auxiliary voting system. (Only after Trail voting was complete did EOS.IO gain an auxiliary voting system that bore a very strong resemblance to early versions of Trail posted on the Telos public Github repository.) Trail service is a powerful advantage for Telos that any app developer can take advantage of, but it does have further to go, and the ability to incorporate proxy voting is one of the features that just isn’t complete yet.
Worker proposals are a key component of Telos that allows the network to continuously grow, expand, reach more users, and add features and tools. As a democratic system, the outcomes of the Telos WPS will depend on the engagement of voters. Telos has the ability to attract and retain talented developers, marketers, promoters, and others who improve the network and are paid to do so. As this process builds Telos and the TLOS token value increases as a result, each month’s WPS inflation will grow and allow the chain to do more things with its money. Worker proposals are the lifeblood of the Telos blockchain. Well spent, they give Telos a way to grow and thrive.
More about GoodBlock can be found at: www.goodblock.io
Join us on Twitter @GoodBlockio
Vote for GoodBlock on the Telos Blockchain Network @goodblocktls