Automate rewarding contributors with a slice of ownership over a project and its earnings, when pull requests are merged.
- Install Merge to earn Github app on one or more repositories
- Initialize the app for each repo on mte.slice.so by following the setup process
Merge to earn (MTE) relies on:
- A Slicer, to split the project's ownership and earnings among multiple contributors;
- A Gnosis Safe, typically owned by the project's maintainers, to execute rewards distributions.
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:
- Delegating MTE to propose transactions on the appointed safe;
- Creating a slicer to represent the project.
When a pull request is opened:
- A comment is automatically posted with instructions on how to request a slice reward;
- The MTE bot keeps updating the scheduled slice distribution in the PR discussion, as new requests are made;
- The PR owner can edit the scheduled distribution anytime, for example as new commits are made or after discussing with the reviewer.
When a PR is merged:
- MTE proposes on the project's Gnosis Safe a transaction to mint the agreed amount of slices;
- Once maintainers sign and submit the transaction, the contributors receive the reward. As a result they will receive a proportional share of earnings related to the project's Slicer from that moment onward, directly on slice.so.
See it in action on this Demo PR
MTE first comment and instructions (click to expand)
Example scenario (click to expand)
-
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.
- Each PR has a pinned MTE comment showing the scheduled slice distribution.
- Contributors can manage their slices and withdraw any earnings on slice.so. Slices are ERC1155 tokens so they can also be managed on the owner's ETH wallet and can be freely transferred (learn more on slice.so).
- If a PRs is merged while previous mint proposals haven't been executed, a new transaction will be proposed which includes all those not yet executed queued on the same nonce. It is thus possible to combine multiple proposals in a single transaction, by executing the last transaction proposed by MTE on a safe for each nonce.
- When a slicer is created on mte.slice.so, the appointed Gnosis Safe becomes its controller and is able to mint or burn new slices or sell products on the slicer's decentralized store.
- The max total number of slices that can be created for a project is 4B. See below the suggestion on how to quantify slices as reward.
Define in advance how slice rewards are calculated
- We suggest rewarding 1 slice for 1$ value of work, or something like that. This greatly facilitates estimating how many slices to give to initial and future contributors.
Add reward tags to issues and PRs
- To incentivise and prioritise contributions, you can add tags to issues and PRs to signal the potential reward for contributors.
Merge to earn requires executing transaction on the Ethereum blockchain in the following instances:
- Setting up a project: The setup process involves creating a slicer for a project. Costs around 400k gas, around $4-8*
- Executing a safe transaction after merging PRs: Gas costs are variable and generally amount to 100k gas for transaction, around $1-2* (note that multiple PRs can be batched into a single transaction, see 3rd bullet point in notes)
*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:
- Requires satisfying hard requirements;
- Yields low rewards;
- Can be easily and quickly mitigated by project owners.
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.