Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DAWN-370 ⁃ Community Benefit Contracts migrating to Worker Proposal System #1005

bytemaster opened this issue Dec 26, 2017 · 4 comments


Copy link

@bytemaster bytemaster commented Dec 26, 2017

This issue is to add a new feature for worker proposals that are funded via the 5% inflation.

createprop {
  account_name   creator
  account_name    receiver 
  prop_name         propposal
  time_point_sec   startdate 
  time_point_sec   enddate
  uint64_t              eos_tokens_per_day;
  uint64_t              fee
voteprop {
   account_name voter;
   prop_name       proposal;
   bool                  accept; /// false to remove vote, true to add vote

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.

@bytemaster bytemaster added this to the EOS Dawn 3.0 milestone Dec 26, 2017
@blockone-syncclient blockone-syncclient changed the title Community Benefit Contracts migrating to Worker Proposal System NOON-370 ⁃ Community Benefit Contracts migrating to Worker Proposal System Dec 27, 2017
Copy link
Contributor Author

@bytemaster bytemaster commented Dec 27, 2017

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++...

@blockone-syncclient blockone-syncclient changed the title NOON-370 ⁃ Community Benefit Contracts migrating to Worker Proposal System DAWN-370 ⁃ Community Benefit Contracts migrating to Worker Proposal System Jan 16, 2018
Copy link

@cabraswel cabraswel commented Mar 19, 2018

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?

@bytemaster bytemaster modified the milestones: Q1, 2018, Q2, 2018 Mar 20, 2018
@gleehokie gleehokie modified the milestones: Q2, 2018, Backlog May 6, 2018
Copy link

@thomasbcox thomasbcox commented May 20, 2018

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.

Copy link

@brianjohnson5972 brianjohnson5972 commented Oct 23, 2018

The worker proposal system design has gone through many iterations since this was written, so it is OBE

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants