make-it-happen.md

Make it happen

Overview

Want something to happen? Fund it!

MakeItHappen dapp greatly simplifies funding of things like public goods by removing the complexity of coordination and negotiation. Instead of a complex trust-based human process, we use game theory incentives:

• seeing the collected funds, performer has an incentive to make something happen to get the reward
• contributors are encouraged to reward the performer to retrieve their own funds locked in the contract

Thus we need neither oracles nor voting. Each contributor is essentially an oracle for his own fraction of reward.

How it works

Let's consider a simple example:

1. Somebody registers an event he wants to happen. E.g. "A bench installed in ABC park in XYZ city." A minimum of 0.1 ETH is needed to register a new event.
2. He and others fund the event, becoming contributors. Half of the contributed money is pledged as a reward, the other half is locked to server as an incentive for a contributor to return to the app to award funds.
3. A person who can make event happen registers as a performer. To do that, he needs to pay a fee which is at least 0.1% of all collected funds. (The fee is necessary to prevent people from stalling the progress.) A performer is provided with a time interval proportional to the amount of funds he paid: if event happens during this time, we assume that the performer is responsible for it. (Only one performer can be registered at a time.)
4. If event happens, would want to recover their locked funds. When doing so, they need to select the time interval in which the event have happened. A perfomer who was registered at that time will receive the reward from a contributor.
5. If cvent haven't happened, but a contributor wants to recover his funds, he can do so. In this case the sum of money which was pledged as a reward remains in the fund and is effectively controlled by other contributors on pro-rata basis.

The rationale behind this design as well as an explanation of possible issues is covered in example section.

Example

Suppose University student Alice was deeply offended by teacher Umbridge, and would like to commission a graffiti caricature of said teach to be drawn on one of University building walls. But it's hard to find an artist which will take this job, as graffiti artists generally like to preserve their annonimity. Besides that, commissioning such a work might get Alice in a trouble. Alice just wants to make it happen and doesn't mind paying for it. So she uses MakeItHappen app.

Alice registers a new event within the app: "A graffiti caricature of teacher Umbridge appears on one of Univerity building's walls" and provides initial funding of 10 ETH.

A lot of other students hate this teacher, so they'd like to chip in. Bob provides 20 ETH and Claire provides 10 ETH.

At this point maximum reward is 20 ETH (a half of collected funds). This is interesting enough for a local artist Banksy. He needs to deposit money to register himself as a performer. He's planning to start working at 3 a.m. and to make sure that it's unambiguous, he needs deadline to last until 8 a.m. when the painting will be seen. If funds were being collected for 1 month, he needs to pay 0.7% of the total collected funds, i.e. 0.28 ETH.

Alice, Bob and Claire will eventually unlock the reward and their own funds. Banksy will receive 20.14 ETH, Alice will receive 5.035 ETH and so on. They only need to specify the date of the event to reward the correct performer. At no point identities of participants were revealed, so Umbridge cannot punish them.

Resilience

Of course, the above is the "happy case". We need to consider what happens in scenarios where participants bevave in suboptimal way:

• Claire drops out: Claire wants her money back ASAP before the comissioned graffiti is made. She can get 5 ETH back. 35 ETH will remain in the fund, and payouts will be done proportionally: Banksy will receive 17.64 ETH, Alice will receive 5.87 ETH and so on. (So Claire dropping out increased payouts for Alice, but decreased it for Banksy.)

• Unsuccessful performer: Another artists, ThreeD, tries to do the job, but is spooked by police before it's done. His registration fee of 0.28 ETH will be distributed between the successful performer and contributors.

• Bad performer: Another artists, Foo, tries to do the job, but he's a bad artist and drawing is not recognizable. In this case contributors might simply refuse to reward him, waiting for better performer. Contributors might also disagree: say, the drawing is good enough for Alice, so she rewards Foo with 5 ETH. But Bob and Claire will wait for a better performer.

• Claire loses her private key: In this case she cannot to unlock her portion of the reward, so Banksy will get only 15 ETH instead of 20 ETH. That's not too bad.

• Fake perfomer: Somebody might register as a performed after the work is already done. As long as contributors select the correct time of an event, he won't get rewarded, instead his funds will increase the reward.

• Patrol is spooked by performer registration: a campus patrol which wants to prevent the painting from being done might monitor performer registrations. Note that Banksy can confirm himself as a performer in as little as 15 seconds, so normally patrol has very little time to react. (If work can be done quickly.) If this is still a problem, there are some mitigating strategies, such as false alarms done by contributors, grabbing a larger time slot, etc. Still, we hope to avoid this information leak in the future versions of the dapp.

• Stalling: Umbridge can register as a performer herself. E.g. if 40 ETH were collected after 1 month, she will have to pay 40 ETH to register as a performer for 1 month. This money will go into increasing the reward.

• Contributor as a fake performer: a contributor might return money back to himself by registering as a fake performer. A minimal payment necessary to register as a contributor is 0.1%, thus this might be profitable for a contributor to withdraw money this way if he contributed more than 0.2% of total ETH collected. Thus it is a non-issue for funds with thousands of contributors, but might be an issue in smaller funds. We will try to mitigate this problem better in future versions.

Implementation

Solidity contract is here. We also have 95% read web front-end.

Hey, this is exactly what I had in mind for crowdsourcing work. I think this model is very good and has a very promising future.