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.