Round 9 - GMC Call for Bounty Applications - Deadline is February 11

This thread is for applications for Rocket Pool’s January 14, 2024 - February 11, 2024 bounties. Please only post bounty applications in this thread. If you would like to discuss and/or ask questions about any applications you see in this thread, we ask that you do so in this separate forum thread which has been established for all community discussions related to this round of applications. Only those grant applications that are posted in this thread and timestamped by February 11, 2024 at 23:59 (11:59 PM) UTC will be considered. Any bounties posted after that deadline will be carried over to the next award period.

This is the expected schedule for round 9:

  • Application Period (January 14th - February 11th)
  • Application Selection (February 11th - February 14th)
  • Application Discussion Meetings - one for each subcommittee (February 15th - February 19th)
  • Scoring Deadline (February 20th)
  • Final Voting Amendments, Discussion and Finalization (February 20th - February 24th)
  • Award Announcement (February 25th)
Differences Between Grants and Bounties Grants are intended to be applied for by those who are wishing to carry out the work themselves. Bounties are open-ended goals that could be met by anyone, including those other than the proposing party. In other words, if I believed that Rocket Pool needed a fifty-foot paper mache orange rocket for publicity purposes and I wanted to be the one to built it, I would apply for a grant. If I instead thought Rocket Pool needed a fifty-foot paper mache orange rocket for publicity purposes but I wanted it to be open to whoever built it first to claim the reward (similar to a prize), then I’d apply for a bounty.

To guide you in your application, the GMC has established the following goals and the following scoring rubric:

GMC Goals

Grants, bounties, and retrospective awards should make it easier and/or more attractive to do one or more of the following:

  • become a node operator

  • operate a node, mint rETH

  • hold or use rETH

  • improve the quality of life for the protocol and its community.

Bounties Rubric

When evaluating grant applications, the GMC takes into account the following goals:

  • If the bounty is completed successfully, to what extent does it further the GMC goals?

  • To what extent is it likely that the bounty can be feasibly claimed/completed successfully?

  • If the bounty is successfully completed, how large is the benefit to the protocol relative to the size of the proposed costs?

Bounty Application Template

Please copy paste the template below into a reply. Answer the questions there, feel free to remove or add sections based on relevance.

# Name of Bounty

## General Information

### What is the nature of the proposed bounty?

### Why are you writing this bounty proposal?



## Benefit

<please enter N/A where appropriate>

| Group | Benefits |
|---|---|
| Potential rETH holders | If the bounty is successfully completed, how does this help people looking to stake ETH for rETH? |
| rETH holders | If the bounty is successfully completed, how does this help rETH holders? |
| Potential NOs |  If the bounty is successfully completed, how does this help people looking to run a Rocket Pool node for the first time? |
| NOs | If the bounty is successfully completed, how does this help people already running a Rocket Pool node? |
| Community |  If the bounty is successfully completed, how does this help the Rocket Pool community? |
| RPL holders |  If the bounty is successfully completed, how does this help RPL holders? |

### Which other non-RPL protocols, DAOs, projects, or individuals would stand to benefit from the bounty being successfully completed?



## Work

### What steps would be entailed in completing the bounty? Do successful examples of such work exist elsewhere? What skillsets or knowledge will be required?

### What advice would you give a bounty hunter working on this bounty?

### Should the output of this bounty be available under an open source license?



## Costs

### How much do you think the completion of this bounty worth to Rocket Pool (in USD)?

### How much work will be needed to verify this bounty has been completed? What skillsets or knowledge will be required?



## Structure

### How would you structure this bounty, and why? 
* A single payout to single team on completion? 
* Divided into milestones? 
* Multiple payouts to multiple teams? 
* Should this be written up as multiple bounty definitions?
* Something else?

### Is this bounty repeatable?

### Are there any reasonable circumstances under which this bounty should be withdrawn? Should it expire?



## Conflicts of Interest

### Does the person or persons proposing the bounty have any conflicts of interest to disclose? (Please disclose here if you are a member of the GMC or if any member of the GMC would benefit directly financially from the successful completion of the bounty).

### Will the applicant, or any protocol or project in which the applicant has a vested interest (other than Rocket Pool), benefit financially if the bounty is successfully completed?

SSV Node - The Rocket Pool SSV Integration

What is the nature of the proposed bounty?

The proposed bounty aims to integrate SSV Network with Rocket Pool. This integration involves several key components: incorporating the SSV node docker, integrating the SSV Operator Secret Key (SK) Generator, and enabling the generation of these keys from Node Operator (NO) seeds. It also includes the development of functionalities to register and remove operators within the platform, along with implementing features for checking and retrieving SSV balances in the smart node. Another critical aspect is the implementation of a system to track the number of validators managed by each operator. To ensure smooth adoption and usage, comprehensive documentation will be developed, covering all these new integrations and features. This bounty aims to significantly enhance Rocket Pool’s infrastructure, making it more secure, efficient, and user-friendly for its stakeholders in the Ethereum staking ecosystem.

Must the results of this project be entirely open source (MIT, GPL, Apache, CC BY license or similar)? If not, which parts will not be, why, and under what license will they be published?

Yes, it will be fully open source.

Benefits - enter N/A where appropriate

Group Benefits
Potential rETH Holders Enhanced security and efficiency through DVT, leading to increased demand for node operators and potentially stabilizing rETH.
rETH Holders Access to a more diversified and secure staking environment within the Rocket Pool ecosystem, leveraging the benefits of DVT for improved trust and reliability in staking processes.
Potential NOs (Node Operators) Attraction of new stakers due to the advanced features of SSV, offering a more secure and decentralized staking experience, especially appealing for those interested in DVT.
NOs (Node Operators) Opportunity to leverage DVT for enhanced security and efficiency in their staking operations, potentially leading to new revenue streams and a more robust staking platform within Rocket Pool.
Community Benefits the entire Rocket Pool community by promoting a more redundant, secure, and efficient staking ecosystem, enhancing trust and participation. Boosting geolocation availability and diversity.
RPL Holders The adoption of DVT in conjunction with SSV could increase the Total Value Locked (TVL) in Rocket Pool, positively impacting the value of RPL tokens due to the enhanced security and efficiency of the platform.

What other non-RPL protocols, DAOs, projects, or individuals would stand to benefit from the bounty being successfully completed?

The successful integration of SSV with Rocket Pool could have extensive benefits that reach beyond the immediate RPL ecosystem, notably enhancing the ETH staking landscape. This integration widens the use case and applicability of SSV, which is crucial for the infrastructure needed in the broader staking ecosystem. It promotes adoption across the Ethereum network at large. This advancement is not only advantageous for the SSV core development team but also extends to a diverse range of dapps, DAOs, and staking configurations. These entities could greatly benefit from the advanced staking capabilities offered by the combination of SSV and DVT. With SSV’s full compatibility with EigenLayer and the implementation of Rocket Pool node operators running on a DVT setup, the security and stability of EigenLayer and its higher-level stack are further enhanced. This includes Rocket Layer, which was proposed by Jasper.

Will the results of the completed bounty be open source?

Yes.

Work and Verification

What steps would be entailed in completing the bounty? Do successful examples of such work exist elsewhere?

Design:

The design phase involves conceptualizing and planning the integration of SSV Network with the Rocket Pool ecosystem. This phase will focus on ensuring compatibility and efficiency in the integration process. The design elements include:

  • Architectural planning for integrating SSV node docker with Rocket Pool.
  • Designing a seamless process for incorporating the SSV Operator Secret Key (SK) Generator.
  • Creating a blueprint for the generation of SK from Node Operator (NO) seeds.
  • Outlining the procedures and safeguards for implementing registerOperator() and removeOperator() functions.
  • Conceptualizing the mechanism for SSV balance checking/retrieval in the smart node.
  • Planning the implementation of a system to count and manage the number of validators.

Work:

Stage 1: Build

  • Developing and coding the integration of SSV node docker with Rocket Pool.
  • Integrating the SSV Operator SK Generator into the Rocket Pool’s framework.
  • Establishing a system to generate SK from NO seeds, ensuring security and uniqueness.
  • Coding and integrating the registerOperator() and removeOperator() functions into the Rocket Pool stack.
  • Implementing the SSV balance checking/retrieval system in the smart node.
  • Developing a feature to track and manage the number of validators in the Rocket Pool network.

Stage 2: Audit Cycle

  • Conducting a comprehensive audit of the newly integrated systems to ensure security, efficiency, and compatibility.
  • Partnering with reputable auditors to review the integration and provide feedback for improvements.
  • Implementing the audit feedback to refine and optimize the integration.

Stage 3: UX/Presentation

  • Designing user-friendly interfaces and experiences for the integrated features, focusing on simplicity and ease of use.
  • Creating comprehensive documentation to guide users through the new features and integrations. This includes detailed instructions, use cases, and troubleshooting tips.

How long is the proposed bounty available for? Is it awarded to the first team to successfully claim it, or is it in some way divided among all such successful claims in the proposed availability period?

The bounty for integrating SSV technology with Rocket Pool will be open for a duration of two months. Within this time frame, we welcome submissions from any number of teams or individuals who are prepared to present an MVP focused on SSV integration. We encourage early submissions to foster a collaborative environment. As soon as we receive the first qualifying MVP submission, a subsequent period of two weeks will commence, during which other participants can still submit their versions of the MVP for consideration. Following this two-week window, one team will be selected and awarded one-third of the total bounty prize. This chosen team will then have the exclusive option to undertake the complete project, thereby claiming the remaining portion of the bounty. This approach ensures a competitive yet collaborative atmosphere, driving innovation while maintaining a focus on delivering a high-quality, functional integration of SSV with Rocket Pool.

Who will test any products submitted for claiming the bounty?

For the bounty concerning the integration of SSV and Rocket Pool, it is imperative that all submitted works are rigorously tested by the applicants themselves before they are assessed by the core teams of SSV and Rocket Pool. Additionally, it is essential to enlist a well-respected third-party auditing firm coordinated jointly by the GMC and the bounty participant. The financial responsibility for this audit will be borne by the GMC.

What are the acceptance criteria for awarding the bounty?

The acceptance criteria for awarding the bounty related to integrating SSV with Rocket Pool are defined as a multi-step process, each with its specific requirements.

  1. Build Phase
    Develop the necessary infrastructure to facilitate the integration of SSV node docker with Rocket Pool. This includes ensuring that Node Operators can effectively utilize SSV technology within the Rocket Pool ecosystem. The build solution must be validated by a core member of the Rocket Pool team, preferably someone with expertise in SSV integration, to confirm its viability and effectiveness.

  2. Feedback and Coordination Phase
    After the initial build, the solution will undergo an extensive audit. The project team is expected to incorporate feedback from this audit and collaborate closely with both the SSV and Rocket Pool teams. The goal in this phase is to refine the integration, ensuring it aligns with both SSV standards and Rocket Pool’s operational requirements. Following these refinements, the integration should be ready for public deployment.

  3. User Interface and Documentation Phase
    Develop and implement user-friendly front-end components tailored to the integrated SSV functionalities within the Rocket Pool platform. Alongside this, comprehensive documentation should be created detailing the usage, features, and benefits of the integration. This documentation should be clear, concise, and accessible, aimed at ensuring a smooth user experience for both new and existing users of the platform.

Payment

How much USD ($) is the applicant requesting for successful completion of the bounty?

$20k to $30k.

Milestone Amount Percentage
Testnet Integration $ 30%
Mainnet Integration + Audit $ 70%
Total $ 100%

Conflict of Interest

Will the applicant, or any protocol or project in which the applicant has a vested interest (other than Rocket Pool), benefit financially if the bounty is successfully completed?

No.

1 Like

Work Patches is Keen to Delegate

General Information

This bounty is comprised by a few github issues I’ve filed over the last many months for small but meaningful changes to smartnode. I am too lazy to write a bounty for each one. The GMC should feel free to cherry-pick.

What is the nature of the proposed bounty?

Complete tasks from the list to Patches’ satisfaction, passing review from the team, and getting merged into smartnode, and claim the payout.

Why are you writing this bounty proposal?

Filing issues on github has not lead to work completion.

Benefit

<please enter N/A where appropriate>

Group Benefits
Potential rETH holders N/A
rETH holders N/A
Potential NOs N/A
NOs A variety of improvements to the node operator experience.
Community Small tasks help onboard new contributors.
RPL holders N/A

Which other non-RPL protocols, DAOs, projects, or individuals would stand to benefit from the bounty being successfully completed?

N/A

Work

What steps would be entailed in completing the bounty? Do successful examples of such work exist elsewhere? What skillsets or knowledge will be required?

What advice would you give a bounty hunter working on this bounty?

Check in with Patches first to discuss the solutions.

Should the output of this bounty be available under an open source license?

Yes, smartnode is open source

Costs

How much do you think the completion of this bounty worth to Rocket Pool (in USD)?

How much work will be needed to verify this bounty has been completed? What skillsets or knowledge will be required?

I anticipate modest review times for these. Testing is larger, and due to the lack of a test framework, is duplicated, as the contributor has to test the code, and the team has to test it again before merging it.

Structure

How would you structure this bounty, and why?

This… should be self-evident :slight_smile:

Is this bounty repeatable?

No

Are there any reasonable circumstances under which this bounty should be withdrawn? Should it expire?

Anything already completed in smartnode V2 should be stricken.

Conflicts of Interest

Does the person or persons proposing the bounty have any conflicts of interest to disclose? (Please disclose here if you are a member of the GMC or if any member of the GMC would benefit directly financially from the successful completion of the bounty).

No

Will the applicant, or any protocol or project in which the applicant has a vested interest (other than Rocket Pool), benefit financially if the bounty is successfully completed?

No

Name of Bounty

Slashing Mitigator

General Information

What is the nature of the proposed bounty?

Incorporate an optional background process into the rocket pool smart node that detects if any of the loaded validators have been slashed and if so stops the VC until a NO override.

Why are you writing this bounty proposal?

I’m a node operator, I think this is a good risk mitigation idea, mostly for peace of mind.

The most common type of slashing is isolated- usually someone setting up a backup incorrect or that kind of thing. For a solo validator, this penalizes APPROXIMATELY 3.5%; for EB 16- 7%; LEB 8- 14%; LEB 4- 28%; LEB 2- 56% of stake. While no one should put themselves in this position, it would be nice to have a guardrail in place.

For correlated slashing, a 10% client with a widespread double attestation error would slash ~33% of a solo validator, but 100% of the stake of a LEB 8, eating into rETH.

Risks:

  1. if RP ever becomes a larger share of staking, then an intermittent client bug could lead to shutting down a sizable portion of the network. However, i would think if the RP validators were getting frequently slashed then they probably would not be appropriately participating anyhow. Also we can cross this bridge when we get past 15%.

Benefit

<please enter N/A where appropriate>

Group Benefits
Potential rETH holders n/a
rETH holders in the very unlikely event of a correlated slashing, LEB 8 NOs, even with a minority client, still carry some risk to rETH holders- which this bounty would highly mitigate
Potential NOs LEBs leverage works by sub-exponentially increasing rewards, while exponentially increasing penalties from slashing. With LEBs, the average number of validators run per NO will also rise, meaning more benefit for stopping after the first slashing. This bounty intends to limit the number of slashing events to one validator, which will give reassurance to become a NO. It is also mildly anti-sybil
NOs See above
Community n/a
RPL holders n/a

Which other non-RPL protocols, DAOs, projects, or individuals would stand to benefit from the bounty being successfully completed?

none

Work

What steps would be entailed in completing the bounty? Do successful examples of such work exist elsewhere? What skillsets or knowledge will be required?

  1. Milestone 1: Write code that can be incorporated into the smart node that:
    a) is opt-in, and has no effect on smart node when opted-out
    b) stops the VC if any loaded validator is detected to be slashed
    c) requires the NO to give some specific command to restart the VC
    d) keeps a whitelist of previously slashed validators so these don’t interfere with restarting the VC
    e) is open source
    f) low use of system resources
    g) demonstrated effectiveness on testnet

  2. Milestone 2: The program doing the above is incorporated into the smart node (will require liasing with the team). If the team does not want to incorporate this idea, this milestone can be fulfilled by having a complementary program for NOs downloadable separately from smart node.

What advice would you give a bounty hunter working on this bounty?

none

Should the output of this bounty be available under an open source license?

Yes

Costs

How much do you think the completion of this bounty worth to Rocket Pool (in USD)?

  1. Milestone 1: 1000$
  2. Milestone 2: 500$

How much work will be needed to verify this bounty has been completed? What skillsets or knowledge will be required?

The work will need to be verified by the RP team prior to incorporating into smart node

Structure

How would you structure this bounty, and why?

Two milestones- the first is for the bulk of the work; the second is to guarantee follow-through and that any concerns from the team are addressed. This cost is less than a single saved slashing event.

Is this bounty repeatable?

No

Are there any reasonable circumstances under which this bounty should be withdrawn? Should it expire?

This bounty should expire after 3 months if not claimed

Conflicts of Interest

Does the person or persons proposing the bounty have any conflicts of interest to disclose? (Please disclose here if you are a member of the GMC or if any member of the GMC would benefit directly financially from the successful completion of the bounty).

I am on the GMC. I am incapable of claiming this bounty because of lack of knowledge.

Will the applicant, or any protocol or project in which the applicant has a vested interest (other than Rocket Pool), benefit financially if the bounty is successfully completed?

No.

1 Like

Notice: This message marks the closing of the ninth round of Rocket Pool bounty award applications. Any applications submitted after this will not be considered for this round. The GMC will announce the award recipients in a new thread here on the forums around February 25th. The community will then have two weeks to issue any challenges before funds are disbursed. Thank you to all who applied and thank you to everyone who has followed along. Anyone who would like to comment on existing applications is encouraged to do so in this thread.