diff --git a/RFCs/RFC-0005: Protocol Upgrade to Enable Automatic Distribution of Delegation Rewards.md b/RFCs/RFC-0005: Protocol Upgrade to Enable Automatic Distribution of Delegation Rewards.md new file mode 100644 index 0000000..773ddd6 --- /dev/null +++ b/RFCs/RFC-0005: Protocol Upgrade to Enable Automatic Distribution of Delegation Rewards.md @@ -0,0 +1,53 @@ +# RFC-0005: [Protocol Upgrade to Enable Automatic Distribution of Delegation Rewards] + +- **Intent**: [To request a protocol upgrade for automatic distribution of delegation rewards.] +- **Submitted by**: [lamps, discord: lamps6718, twitter:lamps945 ] +- **Submitted on**: [26 Dec 2023] + +## Abstract + +This RFC aims to address one big pain point affecting all node operators on Mina network, which is the distribution of delegation rewards. The current mechanism relies the node operators to voluntarily calculate the rewards and send them back to the delegators. It is error-prone for the calculations and, more importantly, relies complete trust of the node operator, which hinders the decentralisation of the network. The RFC requests the design and implementation of a new mechanism to achieve functionality that is similar to the Cosmos chains or Cardano, where the rewards are not accessible to the node operators, and the delegators can check and claim the rewards any time. Some scenarios and requirements are outlined below for discussion. + +## Introduction + +A big pain point for all node operators on Mina is how delegation rewards are distributed. Currently, all block rewards go to operators' wallet, and it relies on the operators to calculate the amounts and send them to the delegators. The calcualtion is not trivial and can lead to mistakes, especially when one receives delegations from both locked and unlocked accounts and only the latter is eligible for supercharged rewards (to be removed in hardfork). Moreover, this entire process is voluntary and there has been one or two cases right after mainnet launch in 2021, where the operator ran away with the foundation delegation rewards, and nobody could do anything about it. + +Two major issues come with this relatively rudimentary design: one is the congestions of the network at the end of each epoch when the snapshot of ledger is taken, which resulting in most operators choosing to send transaction during such times. The other is that the Mina holders will only delegate to the operators who they can completely trust, to avoid risking loss of rewards, which hurts the decentralisation of the protocol and results in the funds being concentrated to a small number of reputable operators, instead of having a long tail distribution of decent-sized operators and enthusiasts. + +## Objectives + +A redesign of the mechanism and achieve one that is similar to the Cosmos chains or Cardano, where the rewards are not accessible to the node operators, and the delegators can check and claim the rewards any time. + +This will help resolve both issues mentioned above: the reward claim transactions can be much evenly distributed in time during each epoch (instead of congestion towards the end/beginning), and the necessity to trust a node operator is removed. + +Ideally, we could go further in reducing system complexity from the end-user's experience, e.g. for a user staking MINA in a wallet. We could reduce the necessity for that user to be concerned with the "claim" transaction at all; rewards should always be directly distributed to their wallet and can be used for things like paying transaction fees (reducing two transactions into one -- one claim, one spend -> one spend). + +## Motivation and Rationale + +As mentioned in the Introduction section. + +## Scenarios and Use Cases + +### Example Scenario 1: [User delegates and claims rewards from wallet/explorer] + +| Aspect | Description | +|------------------|-------------| +| **Description** | Node operators set the delegation charge (e.g. 5 percents) onchain, which is viewable on wallet/explorer interface to inform users when choosing who to delegate to. For claiming the rewards, a section shows 'Claimable staking reward: $amount' and a button 'Claim all' in the wallet and explorer UI, with $amount calculated from the delegation charge and the proportion of total reward. Under the hood, the node client exposes an API for calculating the claimable amount for display, and when the user hits 'Claim all' button, the wallet/explorer submit a transaction onchain to claim the rewards. | +| **Requirements** | _Protocol redesign to allow the new reward distribution mechanism, node client implementation to expose relevant API endpoints, wallet and explorer integration._ | +| **Expected Outcome** | _as described above._ | +| **Impact Analysis** | _A much smoother UX for general Mina users; more evenly distributed and less congested transactions on L1, remove uncessary trust in the delegation process._ | + +## Open Issues and Discussion Points + +Community member and MinaExplorer operator, garethdavies, has conducted some research and given an example of doing pool payouts with a zkApp: [1]. https://hackmd.io/@garethtdavies/BJH3xMpFs. To quote him: 'there are numerous issues with this, not least the reliance on an oracle for block history and currently no way to bind the coinbase receiver to the zkApp.' + +We mentioned that the user ideally should not be concerned with the 'claim' action at all. An edge scenario where a wallet user would need to be aware of a "claim" transaction is if there were constraints around the distribution of rewards, notably, this was a large topic in 2023 in the Cardano ecosystem; [contingent staking](https://forum.cardano.org/t/personal-thoughts-on-contingent-staking/114912). There needs to be discussions if the Mina ecosystem believes a requirement for this feature would be to enable constraints on the spending (i.e. claiming) of staking rewards, in essence, to give those accounts programmable logic. + +## Conclusion + +This RFC seeks a solution to the current rudimentary distribution mechanism of delegation rewards on Mina. An automatic claim mechanism, similar to what is employed on Cosmos chains or Cardano, would reduce congestions on L1, remove unncessary trust requirements, and considerably improve the user experiences on Mina. + + +## References + +[1]. https://hackmd.io/@garethtdavies/BJH3xMpFs.