project screenshot 1
project screenshot 2
project screenshot 3
project screenshot 4
project screenshot 5
project screenshot 6

SourcerAO

Enable users of an open-source project to join forces and offer a bounty for the development of a new feature on their project. Development follow-up, delivery and payment are handled by the protocol. The protocol manages delivery disputes thanks to the incentivized community.

SourcerAO

Created At

ETHGlobal Paris

Project Description

SourcerAO enables users of an open-source product to join forces and offer a bounty for the development of a new feature on this product. Users can create projects on the platform, describing the missing features in a specific open-source product. If the project is open to funding, any other user of SourcerAO can contribute to the project and bring funds. These "funders" form a DAO. On the other hand, developers can apply to do the job and get the bounty. They can provide URI to their CV. Similarly, projects are created with a URI redirecting to a description of the development to carry out. These descriptions are stored using IPFS.

Developers can apply for the project and receive the bounty upon completion. The platform also tracks and recognizes developers' contributions to other projects, increasing their reputation score. After a period of time, the application phase closes, and funders vote to select the developer who will undertake the project. The bounty is locked in a contract to ensure payment upon successful completion.

Once the project is finished, there are two possible scenarios: 1 - The delivered product meets the funders' expectations, they allow the payment, the developer receives the bounty, and the project is closed. 2 - Funders are dissatisfied, they refuse to trigger payment. Then, any party (funders or developer) can trigger a dispute process called litigation. An esteemed developer, possessing a high enough reputation, may volunteer to serve as an arbitrator and settle the dispute. He reviews the delivered project and decides the appropriate payment for the developer. The payment is then made automatically. An non-implemented feature could allow either party to appeal, leading to another review. This reviewer is incentivized to do the review: doing it and settling the dispute will have him receive a bail locked at the beginning of the project by both the funders and the developers.

How it's Made

The frontend is built with React, Ether.js, Chakra UI and Vite The contract has been developed using Hardhat The storage of the contract does not stores everything, we rely on IPFS to store data such as project description or developer CV The animation video is made with Manim library

One particular hacky thing accomplish is the way we ensure payment. The bounty is locked on the contract, and in case of dispute, we rely on the community and an incentive mechanism to make sure their will be a mediator that reviews the dispute and settle it. We also provide a reputation system that help project chose their developer and guaranty reviewer quality during dispute

We discussed several aspect that have not been implemented by lack of time:

  • To allow developer to apply to big project without having to give a bail, the platform itself could propose an insurance mechanism, it provides the bail for the developer and takes a part of its bounty to pay the risk (because if their is a dispute, the platform will have to pay the mediator, thus their is a risk).
  • Since the platform is locking funds during the project handling, it could have an investment strategy to safely get yield with these funds. Doing so, the platform can pays improvement of its code itself.
  • Reputation hack: to avoid someone creating fake project to pay himself though the protocol and artificially gain reputation, we could set a locking time for delayed payment, drastically reducing the attack speed.
background image mobile

Join the mailing list

Get the latest news and updates