DAWN-370 ⁃ Community Benefit Contracts migrating to Worker Proposal System #1005
Comments
This should be implemented as a WASM contract that is funded by block rewards not paid to producer. No need to implement worker logic and payout into native c++... |
I see a start date and an end date. Are these like small kick starter projects to help the community or are these community based applications that could potentially reward any user of said smart contract... like steemit or a Lottery contract? |
Some preliminary work is being done on the Worker Proposal management problem (defining the problem space) by a group I've pulled together. Please PM me on Telegram (@thomasbcox) for details or to be included. Trying to keep the group small-ish for now, i.e. thru mid-June 2018. |
The worker proposal system design has gone through many iterations since this was written, so it is OBE |
This issue is to add a new feature for worker proposals that are funded via the 5% inflation.
All proposals are sorted by the stake-weighted votes of EOS token holders, using the same stake used to vote for producers. Each account can vote for up to 20 proposals at a time. Votes decay using same method as votes on producers (by increasing the votes per staked token over time).
Each day N EOS tokens are allocated where N = EOS_SUPPLY * 5%/365 - PRODUCER_PAY_PER_DAY
Once per day proposals are sorted by total votes and for each proposal who is between startdate and enddate is funded all N EOS are consumed. The EOS is deposited to the receiver contract which may then do with it as it chooses.
A fee is required to create new proposals in order to prevent abuse. This fee is set by the block producers and should be equal to 1% of the daily EOS requested by the proposal. The smallest daily request allowed is 1% of N. This will keep the maximum number of funded proposals less than 100 and keep the number of proposals up for consideration relatively small.
The text was updated successfully, but these errors were encountered: