Dear Kleros Community,
The purpose of this proposal is to present a strategy for boosting developer engagement and expediting bug resolution in the Kleros protocol, especially with the arrival of v2.
We propose to integrate FEATURE, a protocol to incentive developers to contribute to Open Source projects with crypto-rewards, see docs. We believe that the adoption of this rewards-driven protocol will foster increased participation, accelerate bug detection and rectification, and ultimately enhance the overall efficiency of our ecosystem.
We propose the following three-phase plan for the integration of the FEATURE protocol into the Kleros ecosystem:
- Phase One - Integration and Reward Setup: This involves initiating the integration process and setting up a reward system with our native token. Different rewards are assigned based on task difficulty, with special considerations in place for salaried core team members to prevent “double spending” (see PS for the set up of the rewards).
- Phase Two - Testing and Stability Evaluation: Upon successful integration, a three-month testing phase will be conducted to assess the stability of the application and the effectiveness of the reward system in increasing contributions.
- Phase Three - Monitoring and Continuous Improvement: In this phase, we will monitor the effectiveness of the integration, making necessary improvements based on feedback and performance data. Upon successful testing, we aim to extend the use of the protocol to other partnerships.
While considering this proposal, it’s important to keep in mind potential disadvantages. Some studies suggest that external rewards may demotivate individuals. However, we argue that economic incentives are necessary for long-term commitment.
Also, the division of our native token among various bug bounty protocols could be seen as a downside, but we ensure that the reserve is sufficient and that rewards are automatically reimbursed after the claim delay.
Given these considerations, we’ve compiled a summary table highlighting the pros and cons of this proposal:
|Increased Developer Participation||Potential Demotivation from External Rewards|
|Enhanced Bug Detection and Resolution||Our native token being split among multiple bug bounty protocols|
|Boosted System Efficiency and Evolution|
|Empowering Builders with More Governance Power|
|System Accommodates for Salaried Team Members|
We invite the community to provide their valuable feedback on this proposal.
Upon positive reception, we look forward to transitioning this proposal to a snapshot vote for final approval.
Task difficulty determines the reward size, using a scale based on the Fibonacci sequence, a commonly used sizing strategy in Scrum methodology. This sequence provides a set of standardized difficulties that reflect the complexity and time required to complete a task.
The PNK rewards corresponding to each size are as follows:
- Size 1 (700 PNK, approx. $15)
- Size 2 (1400 PNK, approx. $30)
- Size 3 (2100 PNK, approx. $45)
- Size 5 (3500 PNK, approx. $75)
- Size 8 (5600 PNK, approx. $120)
- Size 13 (9100 PNK, approx. $195)
- Size 21 (14700 PNK, approx. $315)
For the double escrow system, see double escrow.