Round 39 - GMC Call for Bounty Applications - Deadline is August 7

Grants / Bounties
,
1

This thread is for applications for Rocket Pool’s July 7, 2026 - August 7, 2026 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 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 August 7, 2026 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 39:

  • Application Period (July 7 - August 7)
  • Scoring Deadline (August 25)
  • Final Voting Amendments, Discussion and Finalization (August 26 - August 29)
  • Award Announcement (August 30)
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 build 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 Proposal Template

Guidelines

  • The goals of the Bounty Proposal are:
  • to communicate your bounty idea clearly, in general terms, such that the GMC can decide if it’s worth pursuing.
  • to estimate the benefits and costs attached to your proposal.
  • to disclose any relevant conflicts of interest.
  • Answers to the template questions do not need to be highly detailed. Estimates or ranges are acceptable. Brief answers are also fine.

Template

# Bounty Name

## 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 is 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 a 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?

Bounty Definition Template

Guidelines

  • When a single bounty proposal has parts that must be completed by different groups, it should become multiple definitions.
  • Where reasonably possible, bounty definitions should limit the number of distinct skillsets required for completion of the bounty.
  • Bounties should be defined in terms of the smallest worthwhile unit of work. IE: $25 to add/update a single relevant FAQ question rather than $5,000 to update the FAQ.
  • Include any information or resources that might reasonably help a bounty hunter complete the bounty.
  • Think carefully about which tasks are required, and which can be optional.
  • Clearly list any dependencies, if the bounty cannot be completed in all circumstances.
  • Only include multiple milestones for large bounties with natural points of division.

Template

# Bounty Name

## Data

* Repeatable?
* Expiring?
* Skillsets for completion? (See existing bounties and reuse where possible, new skillsets are recommended if sufficiently distinct)
* Relevant tags? (See existing bounties and reuse where possible, new tags are recommended if sufficiently distinct)
* Min reward (USD)?
* Max reward (USD)?
* Any linked definitions? (e.g. if a single bounty proposal becomes multiple definitions.)
* Any dependencies?

## Summary

Short 1-3 sentences describing the bounty.

## Dependencies

Is there anything that must happen (outside of a bounty hunter's control) before it is possible to complete this bounty? This may be other bounties that must be completed first, an upcoming event or change, or a regular occurrence that triggers a valid bounty. This section is optional. It may later be removed from the definition if the dependency becomes permanently met.

## Required Milestones

What must be completed for a bounty hunter to claim some amount of bounty. Described per milestone.

### Milestone A - <Name of Milestone>

**Payout:** <payout amount>

Clear bulleted list or subheadings covering the items that must be completed and/or adhered to for this milestone to be valid.

### Milestone B - <Name of Milestone>

**Payout:** <payout amount>

Clear bulleted list or subheadings covering the items that must be completed and/or adhered to for this milestone to be valid.

### Milestone C - <Name of Milestone>

## Optional Milestones

What tasks may be completed for a bounty hunter to earn extra bounty rewards. Described per milestone. This section is optional.

Optional milestones may be less strictly defined than required milestones. You may aggregate multiple minor considerations that would contribute to a payout.

### Milestone D - <Name of Milestone>

**Maximum Payout:** <maximum payout amount>

Clear bulleted list of the items that would contribute to payout for this milestone.

### Milestone E - <Name of Milestone>

## Further Notes

Anything you think would be beneficial for a bounty hunter to know when working on this bounty. May be divided into subsections as needed.

## Resources

Links to repositories, web pages, forum discussions, etc. Anything that the bounty hunter may be able to use to do a better job on the bounty work.

## Contacts

Individuals that have agreed to act as contacts for this bounty. Include usernames + contact details for any platform on which the contact is willing to respond to requests. Any contacts are expected to fully understand the bounty definition. This section is optional.

Contacts:

* MAY be eligible for incentives.
* SHOULD NOT assist the bounty hunter directly with the bounty work.
* SHOULD assist bounty hunters via feedback, direction, and oversight upon request.

## Verification

Who is expected to verify that the work delivered meets the relevant milestones? This person or group must have agreed to do this in advance of this definition being published. This person or group should have any relevant skillsets needed to properly verify the bounty work.
2

Validator Performance Data Feed

General Information

What is the nature of the proposed bounty?

A small, open-source tool that pulls raw per-minipool validator performance data (attestation effectiveness, missed proposals, sync committee participation) from the beacon chain and publishes it as a structured, queryable JSON/API feed. This is a narrow, well-bounded data-pipeline task — not analysis or alerting, just clean, reusable data export.

Why are you writing this bounty proposal?

The Saturn 2 scoping discussion identified protecting rETH yield from underperforming validators as a current community priority. A clean, public performance data feed is a small but genuinely useful building block toward that goal — usable by dashboards, alerting tools, researchers, or individual node operators, regardless of who builds it. I am separately proposing a related grant this round (rETH Yield Guard) for the analysis/alerting layer, but this bounty is independently useful and not dependent on that grant being funded.

Benefit

Group Benefits
Potential rETH holders Supports the broader goal of protecting rETH yield by enabling better visibility into validator performance network-wide.
rETH holders Indirectly benefits from any tooling built on top of this data that helps catch yield-eroding underperformance sooner.
Potential NOs Public performance benchmarks give new operators a clear reference point.
NOs Can self-check their own minipool performance against network data without building custom tooling.
Community A reusable, open data feed lowers the barrier for anyone building future monitoring/analysis tools.
RPL holders N/A — indirect benefit only via broader rETH yield protection.

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

Any developer or researcher studying Ethereum validator performance broadly could reuse the data pipeline pattern.

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?

Steps: query beacon chain data (via a public beacon API or existing indexer) for all Rocket Pool minipool validators, compute standard performance metrics (attestation effectiveness, proposal success rate, sync committee participation), and publish as a structured JSON feed with a simple query interface. Similar validator performance dashboards exist for the broader Ethereum network (e.g. beaconcha.in), but none are scoped specifically to Rocket Pool minipools as an open, reusable data feed. Requires familiarity with beacon chain APIs/data structures and basic API/data-service development in any language.

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

Reuse an existing beacon chain indexer or public API where possible rather than building chain-indexing infrastructure from scratch — the value here is in the Rocket Pool-specific aggregation and clean export format, not in re-implementing indexing.

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

Yes, MIT or similar permissive license.

Costs

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

$1,200 — reflects a small, well-scoped data pipeline task achievable in roughly 3-5 days of focused work by a developer with beacon chain API familiarity.

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

Straightforward — spot-check the feed’s output against a handful of known minipools’ actual on-chain performance data. Requires basic familiarity with beacon chain data to sanity-check; roughly 30-60 minutes of review.

Structure

How would you structure this bounty, and why?

A single payout to a single team/individual on completion. The scope is small enough that milestones would add overhead without meaningful benefit.

Is this bounty repeatable?

No — a single canonical data feed is the goal. Ongoing maintenance/hosting could be proposed separately later if the feed proves useful and needs long-term support.

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

Yes — if no submission is received within roughly 2 months, or if an existing tool is identified that already adequately serves this need, the bounty should be withdrawn or reconsidered.

Conflicts of Interest

Does the person or persons proposing the bounty have any conflicts of interest to disclose?

I (Mahmud Bello, GitHub: mahmudsudo) am proposing this bounty and may also attempt to claim it myself. I am also proposing a related but independently-scoped grant this round (rETH Yield Guard). I am not a member of the GMC.

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?

Only insofar as I may claim the bounty payout myself if I complete the work, consistent with the open, first-to-complete nature of the bounty structure.

3

Notice: This message marks the closing of the thirty-ninth (39) round of Rocket Pool bounty applications. Any applications submitted after this will not be considered for this round.