As I’ve watched events unfold in the last week or so in the Steem community, I’ve become convinced that we urgently need a worker proposal system like the one that exists in BitShares, both to speed up and to decentralize the development of the Steem blockchain.

Yesterday, our team took a hard look at what it would take to implement a similar system in Steem (with some improvements based on our experience with the BitShares implementation), and we believe we can deliver a fully tested worker proposal system in 1-2 months at a cost of between $50K-$100K USD (this wide range on completion cost may seem strange to someone who hasn’t been actively involved in software development, but estimating the time to complete a software project is extremely difficult in most cases).

Last night I contacted @ned to see if Steemit would be interested in funding the proposal and he liked the idea, so we decided the next step to get a conversation going would be to write this post to describe our team’s initial idea for how the worker proposal system would work. I’m also planning to attend the Steem alliance meeting on the 27th to have a live discussion of the potential benefits of a worker proposal system.

What is a worker proposal system?

A worker proposal system allows Steem users to publicly propose work that they are willing to do in exchange for pay. Steem users can then vote on these proposals in almost the same way they vote for witnesses (stake weighted votes, but voters can vote for as many proposals as they want). The proposals that get a sufficient amount of vote weight get funded from a special Steem account controlled by the blockchain. For the purposes of this post, I’ll refer to this as the “funding account”.

Disclaimer: this is just a rough spec

A worker proposal system represents a reasonably complex system, both from an economic point of view and from a detailed implementation in code. In this post, I’m skipping some details involved in the actual implementation to keep this post as readable as possible for anyone who has a general interest in how such a system would function.

Who pays for worker proposals (how do funds get into the funding account)?

One of the most potentially controversial aspects of a worker proposal system is “Where does the money come from to pay for worker proposals?”.

Our proposal is to add a small amount of inflation to Steem (e.g. 1% annually) that is paid into the funding account. This ensures long term funding for the blockchain and it also allows for that funding to grow as the blockchain itself becomes more valuable. If we assume that Steem’s market cap remained constant over a year’s period at its current value of $121 million, that would mean 1.2 million SBD would be generated over that period to potentially pay worker proposals.

In addition, anyone can make donations to the funding account and Ned has indicated that Steemit would likely be interested in making such a donation.

[EDIT: After having to make this clarification in at least half a dozen comments, I want to point out that 1% was an e.g. (an example amount of inflation) rather than an actual proposed amount. Also, I am personally completely fine with those funds coming from the reward pool versus a new source of inflation. I'm somewhat neutral on the source and I expect there will be many opinions on what that source should be. That said, feel free to express your opinion as to where the funds should come thru in the comments below, but please let's not forget to think about the rest of the system as well.]

As a side note for any economists reading this post: more properly, I’m talking about increasing the supply of SBD in the same way that new SBD is created to pay for posts, instead of “real” inflation, which refers to the value of a currency relative to physical goods. In Steem-related posts, the term “inflation” is used so often to refer to this creation process that I decided to stick with it for this post. Just be aware that it’s not valid to compare this meaning of inflation to its common meaning with regard to a fiat currency like the US dollar or the Euro.

Worker proposals paid in SBD rather than Steem

Instead of paying workers in Steem, I strongly believe it’s better to pay them in SBD. In practice, SBD maintains a much more stable value versus Steem with regard to external goods (e.g. food). This allows a worker to have a more predictable income from their work and it also makes it easier for stakeholders to evaluate the worth of the funds being asked for.

A large part of my belief that paying worker proposal in SBD will be better than paying in Steem is based on lessons learned from BitShares. In BitShares, the worker proposal system in its “natural state” paid out in units of BTS instead of in one of it’s more stable currencies like BitUSD and BitCNY. This almost always led to one of two problems: 1) if BTS dropped too much in value, the worker was no longer getting paid enough to do their work or 2) if BTS went up too much in value, the worker was getting paid too much for their work, leaving stakeholders unhappy with the deal.

To resolve this problem in BitShares, a third party organization was ultimately set up that collects funds in BTS, but instead pays out BitUSD instead, and most worker proposals on BitShares nowadays operate under the oversight of that organization. But this adds a bunch of overhead and requires trust in a 3rd party organziation to properly handle the funds, so I think it’s much better to design the Steem WPS to natively pay in a more stable currency.

What does a worker proposal look like?

A worker proposal is created by submitting a transaction to the blockchain (a process similar to writing a post or voting) that has the following information:

• account_being_funded (generally this will be an account owned by the person or group creating the proposal, but not always)
• daily_pay (the amount of SBD that is being requested to be paid out daily)
• start_date (when the proposal will begin paying out if it gets enough vote weight)
• end_date (when the proposal expires and can no longer pay out)
• subject (a very brief description or title for the proposal)
• url (a link to a page describing the work proposal in depth, generally this will probably be to a Steem post).

Worker proposal fee

To avoid frivolous proposals that waste the time of stakeholders, we are suggesting that a fee of 10 SBD is required to create a worker proposal. This fee will pay into the funding account.

Capping daily expenditures to ensure proposals get properly vetted

To prevent someone with a high stake from voting in a proposal that drains the funding account before other voters have a chance to vote in favor of other proposals, we’re also proposing a daily budget limit on how much of the funds in the funding account can be spent in a given day. The proposed formula is as follows:

daily_budget_limit = funds_in_funding_account/100 + daily_worker_inflation

Taking a look at the Worker Proposal System in action

Let’s consider an example where we have multiple competing worker proposals:

A) Blockchain Curation Worker: wants 300 SBD per day for 14 days to improve the curation code
B) Marketing worker: wants 100 SBD per day for a year to run ads for Steem on a cryptocurrency site
C) Refund worker: represents stakeholders who don’t want to spend funds on any proposal with less stake weight than the refund worker. It wants 100,000,000 SBD that will “refund” the SBD back to the funding account (effectively, any funds this worker receives don’t get spent but are instead held in reserve in the funding account for possible use in the future).

• Assume funding_account starts with 1000 SBD
• assume daily_inflation = 350 SBD
• daily_budget = 1000/100 + 350 = 10 + 350 = 360

Sorting the active proposals by highest voting weight, if the order is A, B, C, then A would receive it’s entire requested budget (300 SBD), B would only get 60 of the 100 it requested (because only 360 was available in the daily_budget and A gets paid before B starts to get paid). No funds are left for C, so none of the funds for the day are kept in the funding account.

On the other hand, if C (the refund worker) got the highest vote, all the funds for the day would go back to the funding account and neither A or B would get paid that day. The funding account would end the day at 1350 SBD. And the next day’s daily_budget would be 1350/100 + 350 = 363.5 SBD.

Alternatively, if stakeholders want to fund A, but not B, then they would vote for a stakeweighted ordering of A, C (refund worker), B. In this case, A would get 300 SBD, and the rest of the daily_budget would be recycled back to the funding account, B would receive no funding, and the funding account would have 1050 SBD at the end of the day (assuming no new funding was added via a donation).

Don’t like inflation being used to pay for worker proposals? Vote in a “burn” worker

If stakeholders at some point decide they don’t like inflation being used to fund worker proposals, they can create and vote in a “burn” worker that pays a roughly equivalent amount of SBD back to the “null” account. SBD transferred to the “null” account is effectively destroyed since no one can access it.

GUI wallets will need to support the worker proposal system

BlockTrades is proposing to do the blockchain level work for this system and to make the required changes to the command-line wallet, but GUI wallets (e.g. steemit.com) will also need to implement a voting page for proposals similar to the page where users vote for witnesses. This is necessary to give all stakeholders a way to vote for their preferred proposals as soon as the worker proposal system becomes active. Because the process of voting for a worker proposal is very similar to voting for a witness, this shouldn’t be a difficult task.