Planning for Bounty System

[stevemulligan]

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.

[stevemulligan]

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.

[stevemulligan]

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.

[majordutch]

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.

[stevemulligan]

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:

https://www.indiegogo.com/projects/coolest-clock-probably-the-coolest-clock-ever#/

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.

[stevemulligan]

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.

Actors

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.

Entities

Topic: The subject of work that a user wants to build. A 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

Genesis

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.

RFC

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

Build

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.

Done

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

Abandoned

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.

[stevemulligan]

Dev Dependencies

Dgraph - Graph Database for backend

Front End
React
Redux
React Router
Socket.io
jsonwebtoken
Web3

Back End
Express
Socket.io
discord.js

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 https://www.archella.org but all you can so do far is login via Discord.

[stevemulligan]

Would there be any objections to trying out https://explorer.bounties.network instead of building our own? What they have is pretty impressive and we can use DAI tokens or ETH.

[stevemulligan]

The Bounties Network platform has already proven to be effective and exposing Ellaism to a larger audience. The platform is open source https://github.com/Bounties-Network

Bounties can be posted at any time for any project that people want to support.

https://explorer.bounties.network

My plan is to close this issue and move the repo that was created.