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

Planning for Bounty System #52

stevemulligan opened this Issue Nov 24, 2018 · 6 comments


None yet
2 participants

stevemulligan commented Nov 24, 2018

This thread was created to discuss, plan and finalize features that will be included in the first version of Ella's bounty system. Please pass it along that we are seeking participation and comments.


This comment has been minimized.


stevemulligan commented Nov 24, 2018

I want to this app to hit a few points

  • Increase community engagement, get more donations, exchange more ideas, build more things.
  • Attract developers. Showcase a list of projects that require dev work and show much bounty has been collected so far.
  • Staking, so people know exactly how much reward will be available and until what time.
  • A process to reach consensus on when bounty should be awarded, maybe multiple ways to do this, and the person starting the project could select from a list.
  • Staking amount and consensus process should be a discussion that eventually reaches a conclusion, workers might suggest changes to rewards, or how to reach consensus that will evolve until a worker accepts the terms, when all stakers and workers agree to the terms, those terms are locked in once work begins.
    - Incorporate ERC-725 identities tied to Discord user ID's.

This comment has been minimized.


stevemulligan commented Nov 25, 2018

After reviewing ERC-725 I feel that while it might be nice to have, it's not required to test the waters and it's vastly more complex and offers far more than I imagined. I would need to spend a month or two just playing with that spec before I knew how to implement it properly so I'm not going to focus on erc725 until we have proven this tool will get used.

Auth will just be a simple discord oauth2 login to make it easy to jump in and start posting or commenting on bounties. Funding a bounty should be easy with a few clicks using MetaMask.

Of course, fund transfers should also be visible if you send from a wallet, and people should still be able to browse content read only without being logged in.

A smart contract for staking bounties will be needed. It will need to hold funds until a date and then return them to original staker, or if consensus is reached award funds to workers. Funds sent direct to an address without using the contract would be considered permanently staked.


This comment has been minimized.

majordutch commented Nov 26, 2018

Hey @stevemulligan, casual observer here. For what it's worth, I like the direction of your proposal. I believe it embraces the community driven aspect of Ellaism and can provide incentive for developers, designers, etc to contribute to building the ecosystem.

I am really interested to see how this turns out.


This comment has been minimized.


stevemulligan commented Nov 27, 2018

I'm sent this to some colleges at work, so I'll post it here as it helps to describe what I think will be a useful tool for us.

Decentralized Topic Funding

I'm in a decentralized community with lots of builders, and non builders that still want to contribute. We have a need to:

  • funnel similar ideas into a discussion that eventually becomes a project
  • connect builders to projects
  • provide funding to these projects
  • award builders or return the funds if the project fails

Seeking Consensus Through Public Engagement

Ideas need a way to compete for attention because there isn't time to build everything.

Engagement on a topic has different avenues

  • Comments, likes, updates from builders
  • Funding
    • Funding also includes a set of terms
    • Funding has a maximum stake time, and are returned if the time expires
  • Pledge of Resources (builders)
    • Also includes a set of terms.
  • Terms are the start of comment threads and have likes, discussion can result in changing terms
  • When pledge of resources terms are met, then all the people providing funding with matching terms will entered into the building phase of the process. Funds are locked
  • Terms will also describe which consensus mechanism should be to decide when funds should be released or when to return to terms phase. (Executive committee or majority threshold)

Trust and Reputation

Crowd funding carries risks whenever the parties do not know each other well. For instance my clock never showed up, it turned out to be fake:

Everyone has to flag the people they trust and how they know them. The trust you are signalling is that you believe the other person is representing their identity honestly and that their intent to deliver resources or funding are genuine.

This trust plays a key role in arriving at consensus for when the project terms have been met. Only people with a two way trust relationship established prior to the building phase will be matched. Sybil attack vectors exist for both funders and builders, so this two way trust is very important to minimize these attacks.


This comment has been minimized.


stevemulligan commented Nov 28, 2018

Funding a Topic

This describes the stages that will take an idea from its genesis to a final state where the bounty is either awarded or returned to stakers.


User: Anyone on the system, read or writing content
Funder: Someone that donates ELLA
Donator: Someone that donates to an idea without desire to hold a stake
Staker: Donator that has a time limit on their support for an idea
Pledger (aka Builder): An recognized individual making a pledge of resources that represents builders, makers, workers
Bounty Faucet: Each bounty awarded gets a 1% bonus of the total amount in the faucet.


Topic: The subject of work that a user wants to build. An rough idea that might need a little refinement over time to attract a pledge of resources.
Terms: Requirements from stakers or pledgers
Agreed Terms: The intersection of all terms between builders and stakers


The first stage is where a user creates the topic. They have in mind a finished product,
or a goal that they want to see achieved in order to award the bounty. The topic
is given a title and a description of what work is needed.

Topics can be anything for which someone is willing to pay a bounty. From making a wiki page, to posting regular tweets, to building a dapp or anything at all. Topics will be
tagged with what type of resources are needed to complete the work.

A screen shot that will be displayed in a project gallery should be included. Files for things like mockups can be attached as well.

The topic is not visible to anyone until the person that created it is willing to stake
some ELLA for bounty. After the initial donation or stake is received, the topic moves to the request for comment stage, RFC.

There will be a minimum stake amount which will probably be around 25 ELLA for at least 24 hours.


In the RFC state users can comment and/or like the topic. Edits to topic meta data can be suggested in the comments, but only the topic creator can make edits. History of edits is preserved and visible.

Comments can have files attached for things like mockups and other content required to do the work. Anyone can mark a topic as a possible duplicate of another, so users can see other similar proposals and compare requirements.

Users can donate directly to the topic from inside the app with MetaMask or outside with any wallet. A direct donation without any associated terms will automatically be sent to the bounty faucet if the topic is ever moved to the abandoned state.

Users can donate with a set of terms. A donation will only be counted as part of the bounty if a pledge of resources has an overlapping set of terms.

Users will be able to mark other users as trusted parties. Two users terms will be tested for a match between two trusted parties.

A builder may at any time choose to apply for the bounty with terms that interact his and any stakers. A staker with terms that did not match will have 24 hours to change their terms to join the bounty for this builder, or they can withdraw their funds. Any staker with still present with matching terms after the 24 window will be included. Staked funds are locked for the minimum time dictated by the agreed terms and the idea enters the Build phase.

Terms are still to be defined but will consist of things like

  • time limit
  • type of consensus used to award bounty
  • minimum stake amount per person


Donators may at any time jump in on existing terms to increase bounty. Anyone can donate during the build phase, but only original stakers that were part of the RFC phase can vote.

The build phase has a time limit defined by the agreed terms. When this time runs out without consensus, project returns to RFC mode. The builder can return to RFC mode at any time if they feel they are unable to satisfy the terms after they start. Stakers may vote to return to RFC according to consensus rules defined in agreed terms if they feel the builder will not be able to complete the task.

Builder can signal completion percentage or request final consensus. Builders can request feedback or unforeseen issues that may require return to RFC stage. In either scenario a discussion may result in more work, or it may result in the bounty being awarded. If the work could only be partially completed, stakers may vote to award a partial bounty. Unspent amounts are returned to the sender or in the case of a direct donation, returned to the bounty faucet.

If a partial or full bounty is awarded the topic is moved to the Done stage. 10% of the total amount in the bounty faucet is added as a bonus.


The bounty has been awarded, community can review history. Added as a badge to everyones profile.


This happens when there are no stakers left, if everyone leaves during the RFC phase.

Voting for awards

These will have to be agreed upon in the terms.

  1. Majority thresholds (50% -> 100%)
  2. Allowed Voters:
    Executive committee - doesn't have to be stakeholders, individual accounts agreed to during RFC phase.
    Only stakeholders - only people that staked a bounty during the RFC phase

This voting has to be done by individuals that we trust to be unique people. It's quite possible that someone could create fake identities and to try and award themselves bounties early, or to get free work done and then let the bounties expire and to reclaim the full amount. To minimize this you need to mark people you know as a trusted individuals.

What properties will go into a set of terms is yet to be defined.


This comment has been minimized.


stevemulligan commented Dec 11, 2018

Dev Dependencies

Dgraph - Graph Database for backend

Front End
React Router

Back End

Even though I don't expect a large number of users for this, I still want to explore what is possible with a Graph DB since I have not used them much.

Visit the Archella Repo to contribute.

Demo site is up at but all you can so do far is login via Discord.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment