Round 43 - GMC Call for Grant Applications - Deadline is December 7

Grants / Bounties
,
1

This thread is for applications for Rocket Pool’s November 7, 2026 - December 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 December 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 43:

  • Application Period (November 7 - December 7)
  • Scoring Deadline (December 22)
  • Final Voting Amendments, Discussion and Finalization (December 23 - December 26)
  • Award Announcement (December 27)
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?

Join the Conversation

We encourage prospective applicants to introduce themselves and discuss their ideas in the Rocket Pool Discord, particularly in the GMC public discussion channel, before submitting an application.

Engaging with the community is a great way to receive feedback, understand the protocol’s current priorities, and determine whether your proposal aligns with the GMC’s funding goals.

While not required, we welcome the opportunity to connect with applicants and discuss ideas before the formal review process.

2

Name of Grant

rp-claimcheck — Offline Merkle rewards proof verifier + claim dry-run CLI for Rocket Pool node operators (Go)

What is the work being proposed?

I propose building rp-claimcheck, a small, MIT-licensed Go CLI that helps Rocket Pool node operators (and anyone auditing a claim) independently verify rewards-interval Merkle data and dry-run a claim before broadcasting.

Smartnode already lets operators view and claim rewards. This grant does not replace Smartnode. It adds a focused, standalone companion for the failure modes that hurt operators most around claim time:

  1. Tree vs chain root check — download (or load a local) rewards-tree JSON for an interval, compute/parse its Merkle root, and compare it to the root stored on-chain for that interval (via contracts resolved through RocketStorage). Fail loudly if they disagree.
  2. Offline Merkle proof verification — given a node address + interval(s), extract the node’s leaf (collateral RPL / oDAO RPL / smoothing-pool ETH as applicable) and verify the Merkle proof against the verified root without sending a transaction.
  3. Claim-status bitmap read — report which intervals are already claimed vs still claimable for the node (same bitmap model Smartnode uses in RocketStorage), so operators do not waste gas on already-claimed intervals.
  4. Claim dry-run — build the same claim / claimAndStake call arguments Smartnode would use, then eth_call / estimate gas. Default is read-only. Broadcast is opt-in behind an explicit --broadcast flag (keys never leave the operator’s machine; the tool never requests a seed phrase).
  5. Megapool + minipool aware status dump — read-only summary of the node’s registration, minipool/megapool presence, smoothing-pool membership, and pending claimable intervals, aimed at Saturn-era operators (not minipool-only).
  6. Optional rETH holder helper (secondary) — reth rate / short exchange-rate snapshot export (CSV) from public RPC for holders who want a dated local record. This is a small add-on, not the main deliverable.

Delivered as a single static Go binary + docker image, with fixture-based tests, a short README, and a clean-room install recording.

Out of scope (deliberate): hosted SaaS, on-box EL/CL health monitoring, Alertmanager rules, public reliability dashboards, Smartnode config preflight, Discord bots, or rewriting official docs. Round 42 already has monitoring/preflight-style applications; this grant stays in the settlement / claim-correctness niche.

Is there any related work this builds off of?

  • Rocket Pool Smartnode (rocketpool node claim-rewards, rewards tree download, Merkle distributor claim path) — primary operator UX today. rp-claimcheck reuses the same public protocol concepts (RocketStorage address resolution, rewards interval events, Merkle distributor) as an independent verifier, not a fork of Smartnode.
  • Official docs — Claiming Node Operator Rewards.
  • Public Smartnode Go bindings / rewards utilities — as reference for claim-status bitmaps and interval info; this project ships its own small library surface under MIT rather than vendoring Smartnode as a product dependency.
  • Round 42 applications such as RP Node Pulse / NodeGuard — complementary problem spaces (live monitoring / install preflight). rp-claimcheck does not duplicate those; it targets claim-time proof verification and dry-run.
  • Earlier declined monitoring / ledger-style ideas on the forum show GMC prefers narrowly scoped, RP-specific tools with clear verification. This proposal is scoped accordingly.

I am a new Rocket Pool grant applicant and do not claim prior Smartnode maintainer status or a production mainnet RP node portfolio. Feasibility rests on Go + go-ethereum experience, fixture-driven tests against recorded mainnet/Hoodi responses, and milestone-gated delivery.

Will 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 — 100% MIT for all original code, fixtures (where redistribution is allowed), docs, and deployment manifests from Milestone 1 onward. Third-party dependencies keep their own licenses. No proprietary hosted component is required for the tool to work.

Benefit

Group Benefits
Potential rETH holders Indirect: healthier operator claim hygiene and fewer botched/mis-verified claims support a more reliable NO set securing the ETH behind rETH. Optional reth rate export helps newcomers keep a dated personal record.
rETH holders Indirect reliability benefit from operators catching bad trees / wrong proofs before broadcasting. Optional exchange-rate CSV is a small QoL for personal records (not tax advice).
Potential NOs A small, installable verifier demystifies the rewards Merkle step before they rely on a single UI path; docs explain the claim flow with links back to official docs.
NOs Direct: independently check tree root vs chain, verify proofs offline, see claim bitmaps, and dry-run gas/eth_call before --broadcast. Megapool-aware status dump. Useful when Smartnode tree download fails, when auditing a friend’s claim args, or when scripting claim readiness.
Community Reusable MIT Go library + CLI; fixture tests others can extend; reduces “did I just claim the wrong thing?” support friction.
RPL holders Safer claim paths and clearer operator tooling around RPL/ETH reward distribution support protocol QoL without speculative APY claims.

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

Solo stakers and researchers who want a small Go example of RocketStorage + Merkle claim verification may reuse pieces. No other protocol is promised delivery, promotion, or exclusivity. The CLI is Rocket Pool–first.

Work

Who is doing the work?

Vincent L. (solo). All design, Go implementation, tests, docs, and milestone forum updates will be done by me. Unpaid community review is welcome; no subcontractors are budgeted.

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

Backend engineer with ~15 years of backend experience and ~5 years focused on Go. Recent work (described without employer brand names): Go microservices for digital-asset exchange systems; correctness-first patterns (idempotency, conservation-of-funds style invariants, transactional outbox); EVM integration in Go with go-ethereum (ABI calls, signing, EIP-712); Solidity + Foundry unit/invariant tests on personal open-source payment-policy work.

Honest limitations: I am not claiming an existing Rocket Pool Smartnode production ops track record or prior GMC awards. To keep delivery credible, scope is a read-mostly CLI + verifier with fixture tests and optional Hoodi soak — not a hosted fleet product and not a Smartnode rewrite.

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

Award expected ~2026-12-27. Dates below are from award.

Milestone Timing Deliverables Payment
M1 — Foundations Award + ~3 weeks Public MIT repo; RocketStorage-based contract address resolver (mainnet + Hoodi); rewards-tree load (local file + documented download path); on-chain Merkle root comparison; CLI skeleton (rp-claimcheck version/root-check); CI with unit tests on fixtures $1,600
M2 — Verify + dry-run Award + ~6 weeks Per-node Merkle proof verify; claim-status bitmap report; build claim / claimAndStake calldata; eth_call dry-run + gas estimate; default deny-broadcast; JSON + human output $1,800
M3 — Megapool-aware polish + handoff Award + ~9–10 weeks Read-only node/minipool/megapool/smoothing summary; optional reth rate CSV snapshot; README + troubleshooting; clean-room install note; tagged v1.0; short forum delivery post; 3 months light maintenance plan activated $1,400

Total: $4,800 USD over ~9–10 weeks after award.

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

Yes — testing is inside every milestone:

  • Unit tests for Merkle proof verification against recorded fixtures (golden roots / proofs).
  • Integration tests that replay recorded RPC responses (no dependency on my personal mainnet node for CI).
  • Manual Hoodi or mainnet-read checks documented in each milestone report (read-only RPC).
  • Explicit tests that --broadcast is off by default and that sensitive inputs are not logged.

No claim of audited smart contracts (this grant ships no new protocol contracts).

How will the work be maintained after delivery?

Included in the ask: 3 months of light maintenance after M3 (fix fixes for broken claim paths within 14 days of a reproducible report; bump fixtures if a documented rewards-tree format change lands). After that, MIT code remains public for forks; MAINTENANCE.md describes how the community can take over. No paid hosting is required for core CLI use (operator-supplied RPC).

Costs

What is the acceptance criteria?

  • Public MIT repo from M1; tagged releases for M1/M2/M3.
  • M1: root-check passes against at least one documented historical interval fixture and fails when the root is deliberately mutated in tests.
  • M2: For a documented sample node+interval fixture, proof verification returns pass; claim-status matches expected claimed/unclaimed bits in the fixture; dry-run produces calldata + gas estimate without broadcasting.
  • M3: Megapool/minipool-aware status command documented; reth rate optional command works against public RPC; README enables a stranger to run root-check + verify without asking me; forum delivery post links tags + evidence.
  • Global: no seed-phrase collection; no guaranteed APY/returns language; no paid third-party lock-in.

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

$4,800 USD total, milestone-gated:

  • M1: $1,600
  • M2: $1,800
  • M3: $1,400

Payable in USDC / USDT on an EVM network the GMC uses, or RPL equivalent at payment time if the GMC prefers. No invoices.

Budget rationale (brief): Solo Go engineer, ~9–10 weeks, no venue/events/SaaS. Comparable Round 42 solo tooling asks were roughly $900–$7,500; this sits in the mid-modest band because scope is a verifier CLI, not a hosted monitoring stack.

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

Vincent L. — EVM address: 0xb987eA76A944fEbA87B898397091cf675aD21B7D
(I can sign a verification message from this address on request. Prefer USDC on the network GMC specifies (USDT acceptable if GMC requires).)

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

  • Public GitHub commits/tags from M1 onward.
  • Each milestone: a short reply in the Round 43 community discussion thread (or delivery note) linking the tag, listing commands to run, and attaching/pass-linking test output.
  • Acceptance = public artifacts matching the criteria above — not vanity metrics.

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

  • Full Smartnode fork / UI — rejected; too large and duplicative.
  • Hosted claim API — rejected; keys/trust surface and ongoing infra cost.
  • Another EL/CL monitoring agent — rejected; Round 42 already covers that niche; GMC has previously declined overlapping monitors.
  • Tax/accounting suite for rETH — deferred; prior ledger-style ideas were low priority; only a tiny rate snapshot helper remains as optional.
  • Fixture-first tests + operator-supplied RPC keep recurring cost near zero.

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

No. No prior GMC grants, bounties, retrospective awards, or oDAO compensation.

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).

None. I am not a GMC member and have no financial relationship with any GMC member.

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 beyond the grant payment itself for delivering this MIT public-good CLI. No other protocol, token, or project of mine receives revenue, referrals, or exclusivity from this work.

3

Name of Grant: Rocket Pool Scorecard: Saturn 1 content refresh

Work

What is being proposed?

I’d like to bring the Rocket Pool Scorecard up to date for Saturn 1. (Edited 11 Nov: I first posted this as a claim on bounty BA062304. ShfRyn confirmed that bounty closed in May 2025, so this is now a regular grant application.)

The Rocket Pool Scorecard (rocketpool-scorecard.vercel.app) was built in early 2024 by Anthias Labs under bounty BA062304, modelled on the Lido Scorecard. The content milestone was never delivered, the bounty has since closed, and the repo (rocket-pool/RocketPool-Scorecard) hasn’t changed since February 2024. The page is still live and still describes the protocol before Saturn 1, so anyone who finds it today gets out-of-date answers.

All of the content is in one file, assets/tableInfo.json (19 items). Reading it against the current RPIPs and docs, the main problems are:

  • The entry item tells new operators they can “create a Minipool”. Minipool deposits were closed under RPIP-74 and new operators now create 4 ETH megapool validators.
  • “Withdrawal request automatically fulfilled” mixes node operator exits with rETH holders redeeming, which depends on deposit pool liquidity and is what RPIP-71 in Saturn 2 is about. These should be two items, rated separately.
  • “Client Diversity” has a comment about geography, not clients.
  • Figures like “over 3,488 unique operators”, “top node operator has 1.6% of total stake” and “859,040 ETH staked across 136 regions” have no date or source.
  • Three comments (“More info”, “Estimate earnings here”, “See here”) lost their links, and the delegation link points to an old docs path.
  • Three items have been “INPUT NEEDED” since launch: resistance to malicious governance capture, smart contract security, and infra/cloud provider distribution.
    What I will do:
  1. Rewrite all 19 items for Saturn 1, keeping the existing JSON schema and the good / okay / needs-improvement grid so nothing changes in code and the Lido comparison still works. Fill the three INPUT NEEDED items, or say clearly what data would settle them if I can’t source it properly.
  2. Add the items the page doesn’t cover today: redemption liquidity for rETH holders, the oDAO’s remaining trust surface, the 4 ETH bond as the entry cost, the express queue, how RPL works now (no minimum since Saturn 0; staked RPL earns a revenue share), and the Security Council’s powers and limits (e.g. its upgrade veto under RPIP-60).
  3. Apply the content feedback from the January 2024 community feedback thread (forum topic 2673, “Request for Community Feedback: Rocket Pool Scorecard by Anthias Labs”), which was deferred to this milestone and never used: Allnodes’ share, a sourced client diversity rating, audits and the Immunefi programme for contract security, dual-house governance as a check on capture, and a source for the regional data.
  4. Give every number an “as of” date and a source link (contract read, RPIP, docs or rocketscan). Saturn 2 RPIPs are mentioned only where an item will change, and labelled as proposed, not live.
    I’ll open the PR with a preview deployment and run a one-week feedback thread on the forum before the round closes, and I’ll edit this post with the links as they go up.

Is there any related work you are aware of?

The Lido Scorecard (lido.fi/scorecard), which this page follows by design; the original Anthias Labs build and its feedback thread; and the docs, RPIPs and rocketscan as sources. I’m not aware of any other attempt to update the content.

Will the work be open source?

Yes. The scorecard repo is public; my changes are content and are offered under the repo’s license, or CC BY 4.0 if the GMC prefers a content license.

Benefit

Group Benefit
Potential rETH holders A current, sourced answer to “how safe and decentralised is Rocket Pool after Saturn 1”, in a format they may already know from Lido. Redemption liquidity is rated on its own instead of hidden under one “GOOD”.
rETH holders Clear items on remaining oDAO trust, Security Council limits and redemption liquidity, each linked to its source.
Potential NOs The entry items describe what they will actually face today: a 4 ETH bond, megapools, and the queues.
NOs Outdated minipool-era claims are removed, so the page stops contradicting what they experience.
Community A page the community can point to that is no longer almost three years stale, with dated numbers so it’s obvious when an update is due.
RPL holders An accurate public decentralisation record supports the protocol’s main selling point, and RPL’s current role is described correctly.

Work

Who is doing the work? Timilehin Olowu, independent engineer, Lagos, Nigeria. GitHub: Timi16

What is your background?

I built ZecKit, an open-source Zcash wallet infrastructure project funded by the Zcash Foundation (GitHub - zecdev/ZecKit: Dev tooling for Zcash ecosystem · GitHub). On the EVM side I’ve deployed self-hosted ERC-4337 bundler and paymaster infrastructure and work in Solidity and TypeScript, so reading contracts and RPIPs directly is normal for me.

I’m new to Rocket Pool and don’t run a Rocket Pool node. I make up for that in the method: every item is checked against the contracts, RPIPs and docs, and every claim links to its source, so no line depends on trusting my judgement. If an operator tells me an item doesn’t match their experience, I’ll change it or mark it as disputed.

Milestones

# Deliverable Target date Amount
1 All 19 existing items rewritten for Saturn 1; the 3 INPUT NEEDED items filled or explained; every figure dated and sourced; PR and preview deployment open 21 Nov 2026 $500
2 New items added (redemption liquidity, oDAO trust surface, 4 ETH bond, express queue, RPL’s current role, Security Council); one-week public feedback thread with every comment answered in the PR 5 Dec 2026 $460

Not charged: applying a reviewer’s corrections within two weeks of the review, and updating the affected items within 30 days of Saturn 2 reaching mainnet.

How will the work be tested?

Every figure and claim has a source link and date, so a reviewer can check any line in a minute or two. The JSON keeps its schema and the preview shows it renders unchanged. The GMC can pick any reviewer to check factual accuracy, and I won’t review my own work.

How will the work be maintained?

Dated figures make staleness obvious, and anyone can open a PR against the same file. I’ll do the Saturn 2 update myself, unpaid, as above.

Costs

Acceptance criteria and payment schedule: $960 total, paid in RPL at the GMC’s usual rate, per milestone once the GMC has verified it (Milestone 1: $500; Milestone 2: $460). Acceptance means all 19 items are updated or deliberately kept with a reason, the INPUT NEEDED items are filled or explained, every figure has a date and source, the PR builds, and the feedback thread comments are addressed. I’m happy for the GMC to set a different amount.

Payment recipient: 0x45884Be0855D7dCcceB51aC151FE0DAD7128041c

Verification: through the linked PR, preview deployment and feedback thread, then a factual-accuracy review by a reviewer of the GMC’s choosing.

Alternatives considered: A new “Saturn dashboard” would overlap RocketDash, rocketscan and existing community dashboards and need hosting, so I didn’t propose one. I also left out an auto-refresh script: the page needs a few figures updated at each upgrade, and dated sources handle that without extra code to maintain.

Prior compensation: None from Rocket Pool, the GMC or the pDAO.

Conflict of Interest

None. I have no relationship with Anthias Labs, the core team, or any project the scorecard rates.