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

Grants / Bounties
,
1

This thread is for applications for Rocket Pool’s July 7, 2026 - August 7, 2026 grants. Please only post grant 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 grants 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.

Grants Rubric

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

  • If the application is successful, to what extent does it further the GMC goals?

  • To what extent can the application be feasibly carried out by the person(s) proposed to complete it?

  • If the application is successful, how large is the benefit to the protocol relative to the size of the proposed costs?

Grant 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 Grant

### What is the work being proposed?

### Is there any related work this builds off of?

### Will the results of this project be entirely open source ([MIT](https://opensource.org/licenses/MIT), [GPL](https://www.gnu.org/licenses/gpl-3.0.en.html), [Apache](https://www.apache.org/licenses/LICENSE-2.0), [CC BY](https://creativecommons.org/licenses/by/4.0/) license or similar)? If not, which parts will not be, why, and under what license will they be published?



## Benefit

<please enter N/A where appropriate>

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

### Which other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?



## Work

### Who is doing the work?

### What is the background of the person(s) doing the work? What experience do they have with such projects in the past?

### What is the breakdown of the proposed work, in terms of milestones and/or deadlines?

### How is the work being tested? Is testing included in the schedule?

### How will the work be maintained after delivery?



## Costs

### What is the acceptance criteria?

### What is the proposed payment schedule for the grant? How much USD $ and over what period of time is the applicant requesting?

### Who will directly receive the payment? (Required — the GMC can only send grants directly to a recipient address and cannot accept invoices.)

### How will the GMC verify that the work delivered matches the proposed cadence?

### What alternatives or options have been considered in order to save costs for the proposed project?

### Have you already been compensated by the RP protocol in any way for this work?



## Conflict of Interest

### Does the person or persons proposing the grant 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 grant).

### Will the recipient of the grant, or any protocol or project in which the recipient has a vested interest (other than Rocket Pool), benefit financially if the grant is successful?
2

rETH Yield Guard: Validator Underperformance Monitor

What is the work being proposed?

A lightweight, open-source Rust monitoring service that continuously tracks validator performance across Rocket Pool’s minipool set ; attestation effectiveness, missed proposals, sync committee participation and flags validators trending toward underperformance before they meaningfully erode rETH APR. Results are published via a public dashboard and pushed as alerts to affected node operators, giving them a chance to fix issues before yield is lost.

This directly implements the priority the community and GMC have already identified in the Saturn 2 scoping discussion: protecting rETH yield by shielding it from underperforming validators. It complements Rescue Node (funded in Round 38 specifically for its impact on validator uptime and rETH APR) by addressing the detection side of the same problem rather than duplicating its fallback-connectivity function.

Deliberately kept simple and rule-based this round ,no AI/agent layer , in response to feedback on a prior proposal.

Is there any related work this builds off of?

Yes. The daemon architecture builds on my published crate daemon_rs (long-running daemon process management, already in production use), and alerting/threshold logic reuses patterns from my circuit_breaker crate.

Will the results of this project be entirely open source?

Yes, MIT license.

Benefit

Group Benefits
Potential rETH holders Directly supports the stated Saturn 2 priority of protecting rETH yield, making rETH more attractive to hold by reducing APR erosion from undetected underperformance.
rETH holders Improves confidence that yield-eroding validator issues are caught and addressed quickly across the network.
Potential NOs A public dashboard showing performance benchmarks gives new operators a clear standard to aim for.
NOs Direct alerts let operators catch and fix underperformance issues before they cost meaningful rewards.
Community Adds transparency — network-wide validator performance becomes publicly visible rather than siloed per-operator.
RPL holders Protecting rETH APR supports rETH demand and overall protocol health, which supports RPL value.

Which other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?

Other liquid staking protocols facing similar validator-performance-to-yield linkage could adapt the monitoring architecture.

Work

Who is doing the work?

Mahmud Bello (GitHub: mahmudsudo), a Lagos-based systems engineer with 6+ years of production Rust and C++ experience.

What is the background of the person(s) doing the work? What experience do they have with such projects in the past?

6+ years of production experience in distributed systems, protocol-level infrastructure, cryptography, and developer tooling. Former CTO at StreamLivr (rebuilt failing async architecture, scaled to 5,000+ users). Published Rust crates: daemon_rs, circuit_breaker, rate_rs, cargomon. Open-source contributions to Paradigm’s Solar compiler, Ithacaxyz’s Odyssey execution layer, ingonyama-zk’s Blaze, and Pluto Labs’ Ronkathon.

What is the breakdown of the proposed work, in terms of milestones and/or deadlines?

  • Week 1: Core data collection — pull per-minipool attestation/proposal/sync-committee performance from beacon chain data.
  • Week 2: Underperformance detection logic (threshold-based, benchmarked against network-wide averages) and alerting integration (Discord/Telegram/webhook).
  • Week 3: Public dashboard, testing against live network data, documentation, public release.

How is the work being tested? Is testing included in the schedule?

Yes — unit tests throughout, plus validation against live network data in week 3 to confirm flagged validators match manually-verified underperformance cases before public release.

How will the work be maintained after delivery?

Published on GitHub under my existing account (mahmudsudo). I will address community-reported issues and accept contributions post-delivery.

Costs

What is the acceptance criteria?

A working, tested, documented release (published to GitHub), with a live public dashboard, verified against real network data, and alerting confirmed functional across at least one notification channel.

What is the proposed payment schedule for the grant? How much USD $ and over what period of time is the applicant requesting?

$4,950 total, paid as three milestone-based installments of $1,650 each, released upon delivery of each weekly milestone (weeks 1-3 as outlined above).

Who will directly receive the payment?

0xa8B78566b11e865C290410420c1f30C4982077CF

How will the GMC verify that the work delivered matches the proposed cadence?

Each weekly milestone delivered as a public GitHub commit/release with documentation, allowing real-time progress verification.

What alternatives or options have been considered in order to save costs for the proposed project?

Deliberately scoped to detection and alerting only (no AI layer, no accompanying tooling suite) to keep this round’s ask small and directly tied to the stated Saturn 2 priority, rather than bundling in adjacent features.

Have you already been compensated by the RP protocol in any way for this work?

No.

Conflict of Interest

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

I am also proposing a related but distinct bounty this round (“Validator Performance Data Feed”) for raw data export tooling. The two are complementary but independently useful and separately scoped, this grant does not depend on that bounty being completed, and vice versa. I am not a member of the GMC.

Will the recipient of the grant, or any protocol or project in which the recipient has a vested interest (other than Rocket Pool), benefit financially if the grant is successful?

No.

3

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