The reward system for open source development
Automate rewarding contributors with a slice of ownership over a project and its earnings, when pull requests are merged.
Merge to earn (MTE) relies on:
The setup process is carried out on mte.slice.so by someone who is both owner of the repo and the safe related to the project. It consists in:
When a pull request is opened:
When a PR is merged:
See it in action on this Demo PR
A project starts with 1000 slices to each of its 5 creators, for their initial work. The creators share equal ownership over the project's slicer, and those who act as maintainers are also owners of the Gnosis Safe which approves new slice distributions.
Any payment sent to the slicer at this stage will be split equally between creators (20% each).
A new contributor opens a PR and asks for 500 slices for its work. Once the PR is merged and the transaction is submitted on the safe, slices are minted to its wallet.
Any payment sent to the slicer at this stage will be split: ~9% to the contributor, ~18% to each project creator
As a result, contributors are retributed proportionally to their work and receive earnings based on when their PRs were merged.
Everything is handled transparently on-chain, while Github settings and permissions can be used to customize what happens between opening and merging a PR.
Merge to earn requires executing transaction on the Ethereum blockchain in the following instances:
*Based on an ETH price of $1000 and a gas price of 10-20 gwei
Merge to earn projects can be considered safe against attackers attempting to steal earnings by compromising Github accounts or ETH wallets.
In fact, compromising a project is not worth for an attacker as it:
Let's consider the case where an attacker gains access to a maintainer's Github account. In this case, they would be able to merge fake PRs and propose malicious transactions to the project's multisig to reward themselves with slices.
However, nothing would happen until the quorum of multisig owners execute the malicious transaction. If maintainers are aware an attack has happened, or just check the accuracy of the transactions to be executed (as it's always advised to) this scenario is highly unlikely to happen.
But even if maintainers mistakenly execute a malicious transaction, they still have plenty of time to get the situation under control by reverting the undesired outcome. In this case the attacker only gets part of the earnings that were received by the project between the moment their transaction was executed and when it was reverted, which in most cases should be a negligible amount.
A more complex attack would involve the attacker obtaining the private keys of enough multisig owners' wallets, allowing them to autonomously execute transactions on the project's Gnosis Safe. This is extremely hard to achieve, especially for multisig with a high quorum, but let's consider this scenario anyway.
Due to how slicers are designed, an attacker wouldn't still be able to get the project earnings received until that point, but only what was received after he gained control and executed a malicious transaction. The Slice protocol has been designed to safeguard against this kind of attacks.
On the contrary, to mitigate such an attack, project owners just need to reinitialize MTE for their repository with a new slicer and multisig, distribute ownership to contributors as it was before the attack, and redirect any future earnings to the new slicer. This is technically trivial and can be done in minutes, rendering an attacker powerless.
This project uses Merge to earn to reward contributors with a piece of the Merge to earn slicer and its earnings, when pull requests are merged.