This thread is for applications for Rocket Pool’s August 7, 2026 - September 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 September 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 40:
Application Period (August 7 - September 7)
Scoring Deadline (September 22)
Final Voting Amendments, Discussion and Finalization (September 23 - September 26)
Award Announcement (September 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?
RocketPool Copilot: MCP Server and Guarded AI Agent for Node Operators
What is the work being proposed?
I’m proposing to build an MCP (Model Context Protocol) server for Rocket Pool node operators. MCP is the open standard that lets AI assistants like Claude connect to real data and take real actions through defined tools, instead of just talking about them.
Right now, checking on a Rocket Pool node means reading the Smart Node CLI output, cross-referencing a Grafana dashboard, and knowing what RPL collateral ratios and penalty thresholds actually mean. That’s a real barrier. The Node Operator Experience section of this forum has said as much directly: people find node operation intimidating and full of unknowns, and that stops them from trying.
RocketPool Copilot turns that into a conversation. A node operator, or someone thinking about becoming one, could ask things like “why is my minipool at risk,” “what’s my current RPL collateral ratio,” or “walk me through creating a minipool,” and get a straight answer pulled from live node and chain data. For a defined set of safe actions such as claiming rewards or topping up RPL, the agent can also execute them directly, but only through a policy engine that blocks anything outside a strict allow-list: no unknown contracts, no unsafe calls, spend caps enforced before anything is broadcast. Every decision the agent makes, allow or deny, gets written to an audit log so nothing happens silently.
Is there any related work this builds off of?
Yes. I built and shipped the same kind of system for Rootstock: an MCP server with five tools (protocol data, swap simulation, intent execution, position health, wallet balances) sitting behind a policy engine that blocks zero-address transfers, selfdestruct calls, oversized single transactions, and non-whitelisted contracts, with every allow or deny decision logged. It’s live on Rootstock mainnet today, repo is Rootstock-Agentic-DeFi-Framework under my GitHub: soloking1412 (Maheswaran Velmurugan) · GitHub
RocketPool Copilot is that same architecture, rebuilt against Rocket Pool’s own data sources (Smart Node API, Beacon chain, rETH and RPL contracts) instead of Rootstock’s. I’m not starting from a blank page on the hardest part, which is the safety layer.
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, MIT license, published on GitHub from day one of development, not just at the end.
Benefit
Group
Benefits
Potential rETH holders
N/A, this tool is aimed at the node side of the protocol, not rETH holders directly
rETH holders
Indirectly benefits from a healthier, better-monitored node operator base, since minipool health affects rETH’s backing
Potential NOs
Lowers the barrier to becoming a node operator by replacing dashboard-reading and CLI familiarity with plain-language diagnostics and guided onboarding
NOs
Gives existing operators a faster way to check collateral ratios, penalty risk, and rewards status, and to safely automate routine actions like claiming rewards or topping up RPL
Community
Adds a genuinely new piece of open source tooling to the ecosystem that didn’t exist before, and one that’s reusable by anyone building on Rocket Pool data
RPL holders
Better collateral monitoring means fewer operators getting caught under-collateralized, which is good for RPL’s role as the collateral asset
Which other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?
The MCP server pattern itself is reusable. Any team building AI-agent tooling on top of liquid staking or validator infrastructure could fork the policy engine approach. I’ve already proven that by taking it from Rootstock to here.
Work
Who is doing the work?
Me, solo. I’m Maheswaran Velmurugan (Soloking), a full stack and blockchain developer based in Tamil Nadu, India. My GitHub is linked above. Telegram: @maheswar1412.
What is the background of the person(s) doing the work? What experience do they have with such projects in the past?
I’m a Polkadot Blockchain Academy graduate and a Polkadot Technical Fellow. I build end to end, from Solidity and Clarity contracts to Python SDKs to TypeScript CLI tools, and I ship as a solo developer without a team.
I’ve completed grant-funded projects for both the Arbitrum Foundation and the Stacks Foundation:
Stylus-Toolkit (Arbitrum Foundation grant, completed): a CLI development environment for Arbitrum Stylus contracts. Both milestones delivered and closed out. Live on NPM with over 200 downloads, with a benchmark suite showing 32.6% average gas savings over equivalent Solidity.
satoshi-yield (Stacks Foundation grant, completed): a non-custodial sBTC yield optimizer on Stacks, comparing live APY across five protocols with one-call rebalancing.
And directly relevant to this proposal, two projects rewarded through Rootstock’s Hacktivator marketplace:
Rootstock Agentic DeFi Framework: the MCP server and policy engine this proposal is modeled on, live on Rootstock mainnet, rewarded via Hacktivator
Rootstock Python SDK: published on PyPI, wallet management, ERC-20, RNS resolution, also rewarded via Hacktivator
All of these are visible on my GitHub linked above. Plus security research: confirmed findings across Sherlock, Code4rena, and Immunefi, including high-severity findings on protocols like Threshold Network and SuperDCA.
Both the Arbitrum and Stacks grants ran through to full milestone completion, and both Rootstock submissions were reviewed and rewarded on their own merits. That’s a track record of finishing what I propose, across four separate ecosystems. The security research matters specifically here too, since this proposal’s core piece is a policy engine that has to correctly refuse unsafe actions, and that’s the same class of bug I’ve spent real time hunting in other people’s contracts.
What is the breakdown of the proposed work, in terms of milestones and/or deadlines?
Milestone 1 (3 weeks): Read-only diagnostics core
MCP server scaffold connecting to Smart Node API and Beacon chain data
How is the work being tested? Is testing included in the schedule?
Yes, testing is part of both milestones, not an afterthought. Read-only tools get tested against real mainnet data during milestone 1. Guarded actions get tested against Hoodi testnet in milestone 2 before anything touches mainnet, with specific test cases for the policy engine’s refusal paths (the unsafe actions it’s supposed to block), not just the happy path.
How will the work be maintained after delivery?
I maintain all of my grant-funded projects after delivery. Stylus-Toolkit is still live and maintained a year after its Arbitrum grant closed. I’ll do the same here, keeping the tool working as Smart Node’s API evolves.
Costs
What is the acceptance criteria?
Milestone 1: a working MCP server that answers real diagnostic queries against live Rocket Pool data, open sourced with setup documentation.
Milestone 2: guarded write actions working end to end on Hoodi testnet with a demonstrable, logged policy engine, plus final documentation.
What is the proposed payment schedule for the grant? How much USD $ and over what period of time is the applicant requesting?
$8,000 total, split as $4,000 on delivery of Milestone 1 and $4,000 on delivery of Milestone 2, over roughly 6 weeks.
Who will directly receive the payment? (Required — the GMC can only send grants directly to a recipient address and cannot accept invoices.)
0x2be8023cB03428e988Fa3Ad4079fcf23673c2595
How will the GMC verify that the work delivered matches the proposed cadence?
Each milestone ships as a public commit history on GitHub, so progress is visible throughout, not just at handoff. I’ll also post a short update in the discussion thread at each milestone with what’s working and a way to try it.
What alternatives or options have been considered in order to save costs for the proposed project?
I considered scoping this down to read-only diagnostics only and dropping the guarded actions milestone, which would cut the ask roughly in half. I kept both in because the guarded actions are what actually reduces friction for operators day to day, not just informs them, and the policy engine reuse from Rootstock keeps that milestone’s cost down since I’m not designing that part from scratch.
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? (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’m not a member of the GMC and have no prior relationship with Rocket Pool.
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?
Proof-of-rETH — independent verification and live proof-of-backing for rETH
What is the work being proposed?
Every conversation that grows rETH — a treasury allocation, an institutional due-diligence review, a risk-team assessment, a new integration — eventually hits the same question: “prove the backing and the accounting are correct, continuously, without asking us to trust you.” Today that artifact does not exist for rETH — or, in production, for any LST. Exchanges publish proof-of-reserves for custodial holdings; dashboards display validator balances; ZK-proven balance oracles are a research direction, not a running service. No liquid staking token operates a continuous, independently-recomputed, reproducible proof-of-backing attestation service in production today — and the decentralized LST is the one whose story it fits best.
I propose to build Proof-of-rETH: an open-source trust engine with four layers.
The attestation feed. On a fixed cadence, independently recompute rETH’s full backing from first principles — execution-layer state plus beacon-chain balances of every megapool and legacy-minipool validator — and publish a signed attestation: backing ratio, slot, method version, and a one-command reproduction recipe. Signed receipts that any third party can replay and verify are a primitive I have already shipped in open source (Ed25519 receipt verification in clawshield-core); here they become rETH’s standing answer to “prove it.”
The verification engine underneath. Saturn 1 (live February 18, 2026) rebuilt Rocket Pool’s money flows — megapools, 4 ETH bonds, and the UARS revenue split. The engine independently verifies them: every UARS distribution since launch recomputed against the pDAO-set parameters (a public historical audit — “every distribution since launch, verified”), and every oDAO balance submission behind the rETH exchange rate recomputed from chain data, then checked continuously as a self-hostable watchdog. Rocketwatch and the Dune dashboards track these events excellently; nothing recomputes their correctness in a form anyone can re-run. Six months post-Saturn is exactly the window when accounting edge cases surface — and exactly when “verified correct since launch” is still cheap to establish.
The integration pack. A machine-readable risk API and diligence dossier shaped around what integration gatekeepers actually consume — backing-ratio history, submission-deviation record, UARS verification status, validator-set health, exit-queue exposure. Risk vendors model rETH from data they assemble privately and sell; every new reviewer today rebuilds the same ground truth from scratch. This makes the ground truth public, reproducible, and free — cutting the bespoke diligence cost that sits in front of every allocation decision, which is the demand-side payoff.
The public trust page. A live page — “rETH, verified: backing recomputed at slot X, all checks green, reproduce it yourself” — that the community, the team, and every marketing effort can point at. The GMC already invests heavily in telling the decentralization story ($150k education, $40k podcast, per the RPIP-29 ledger); this makes the story checkable, which is the version competitors cannot copy with content spend.
Everything ships with the discipline the work demands: pinned data sources with hash-refusal (tools will not run against unpinned inputs), per-check citations to the RPIPs/specs that define expected behavior, and one-command reproducibility from a clean clone.
Measured against the GMC’s published rubric: this furthers all four GMC goals — primarily hold or use rETH (a live, reproducible proof of backing is the strongest holding-and-integration argument the token can have, and no LST operates one), plus operate a node / mint rETH and become a node operator (audited, not projected, UARS earnings ground truth) and quality of life (a self-hostable watchdog plus a conformance corpus that becomes the community’s regression net for Saturn 2). Feasibility risk is carried by me, not the committee — the method already runs in public on a harder target (below), the request is staged, and Milestone 1 publishes before the first payment claim. And on benefit relative to cost: today’s decision is $5,000 for a deliverable in the same class the committee valued at $15,000 (the MEV Theft and Loss Report), plus reusable tooling that compounds with every attestation issued.
Is there any related work this builds off of?
Yes — this is the second deployment of a verification-lab pattern I already run in public, plus a signed-receipt primitive I already shipped:
P2MR Assurance Lab: independent verification of Bitcoin’s BIP 360 draft — byte-for-byte conformance against official vectors, a differential harness against the official reference implementation (full agreement on 16 vectors and 2,000 randomized cases), and an adversarial corpus where every case cites the spec text defining its outcome. The differential work surfaced two real conformance/robustness gaps in the official reference implementation, graded honestly in FINDINGS.md and handled through coordinated disclosure. Clone it and run four commands; zero dependencies.
clawshield-core: deterministic policy engine with Ed25519-signed receipts that a third party can replay and verify without trusting the operator — the exact attestation primitive layer 1 reuses.
Prior art, named honestly — and what this adds. The committee should not have to raise “isn’t this just X?” — here is X:
Rocketwatch and the Dune oDAO dashboards track and display submissions and events. They do not recompute whether those submissions are correct, reproducibly.
beaconcha.in and rated.network display validator balances and performance. They do not tie them to rETH’s accounting or attest to the result.
The official odaotool serves oDAO members making submissions. It is not independent, community-side verification of them.
Risk vendors (Gauntlet/Chaos-class) sell proprietary LST risk modeling to clients. They do not publish reproducible ground truth anyone can re-run.
ZK balance-oracle research aims to prove balances in-protocol — eventually. It does not exist as a running service. And critically: you cannot ZK-prove a computation that has never been independently specified and tested. This engine is that executable specification — the reference computation and test corpus any future trustless oracle must implement — delivering verified-correct attestations now, until in-protocol proofs ship.
RPIP-61’s balance-submission guardrail discussion shows the community already values this direction. I’ll coordinate with existing maintainers so alerts complement rather than duplicate, and the engine is built explicitly as an input to — not a competitor of — any future oDAO-reduction work.
Will the results of this project be entirely open source?
Yes — MIT, public on GitHub from the first week. Attestation datasets and the historical audits are published CC BY. The attestation service is self-hostable by design: a proof you can’t run yourself just relocates trust, and the point is to remove it.
Benefit
Group
Benefits
Potential rETH holders
The onboarding answer no other LST can give: “don’t trust us — here is the live, independently recomputed proof of backing, and here is the command to check it yourself.” Directly converts the decentralization story into a purchase reason.
rETH holders
Continuous independent verification of the balance submissions that set the rETH rate and the revenue split that funds it. If anything ever diverges, holders learn it from a public alert with receipts — not from a post-mortem.
Potential NOs
Verified UARS history gives prospective operators exact, checkable answers to “what will I actually earn?” — grounded in audited distributions, not projections.
NOs
Operators can verify their own megapool distributions against the protocol split, and the conformance corpus becomes the regression net that protects their accounting through Saturn 2’s changes.
Community
A citable trust artifact no LST currently operates (“every distribution and every balance submission since Saturn 1, independently verified”) plus a live trust page — marketing with teeth, produced by verification rather than content spend.
RPL holders
The fee switch is now RPL’s core value mechanism; its independent verification is load-bearing for the post-inflation story. And everything that grows rETH demand — which the integration pack exists to do — flows to RPL under UARS.
Which other non-RPL protocols, DAOs, projects, or individuals would stand to benefit from this grant?
DeFi protocols and risk teams evaluating rETH get a neutral, self-verifiable data source instead of bespoke diligence. More broadly, every oracle-rate LST faces this verification gap; the method and beacon-chain tooling are forkable — but the first-mover credibility of “the LST that proved it first” stays with Rocket Pool.
Work
Who is doing the work?
Me, solo — Ashwin Goyal, an open-source web3 engineer based in Bhopal, India. GitHub: let-the-dreamers-rise. Forum/Discord: letthedreamersrise.
What is the background of the person(s) doing the work?
Stated plainly so the GMC never has to discount for unstated gaps: I am a B.Tech computer science undergraduate with ~90 public repositories and no previously completed DAO grants. What I have is a live, verifiable record of exactly this class of work: the P2MR Assurance Lab above is public, reproducible in minutes, and its differential testing found two real gaps in the official reference implementation of Bitcoin’s leading quantum-resistance proposal — done unpaid, before asking anyone for funding, because in verification work shipped verification is the only credential that matters. This proposal is structured so the GMC never pays ahead of visible work: public repo from week one, every payment on delivery, and the first milestone’s historical audit publishes before I claim the first payment.
What is the breakdown of the proposed work?
M1 (weeks 1–3) — UARS historical audit + attestation core (EL side). Recompute every megapool distribution since Saturn 1 launch against the pDAO-set split; publish the audited dataset with one-command re-runs; first signed attestations over execution-layer-derivable state. Public before the first payment claim.
M2 (weeks 4–8) — full backing recomputation + live feed. First-principles recomputation of rETH backing across execution state plus beacon-chain balances for the full validator set; every oDAO balance submission since Saturn 1 verified; the signed attestation feed goes live on a fixed cadence with a self-hostable watchdog and alerting. Infrastructure-heaviest milestone; carries the largest share.
M3 (weeks 9–12) — integration pack + conformance corpus + the report. Machine-readable risk API and the integration dossier; citation-per-case conformance corpus for Saturn-era accounting; the public trust page; and a written report in the tradition of the GMC-funded MEV Theft and Loss Report — “Proof-of-rETH: Saturn 1’s money flows, independently verified”.
M4 (months 4–9) — operated service + Saturn 2 tracking. Six months operating the attestation feed, trust page, and watchdog; pin updates as parameters change; corpus and verifiers tracking Saturn 2’s specifications as they land, so the next migration is checkable on day one.
How will the work be tested?
Testing is the deliverable, and the verifier itself is tested the way my P2MR lab is: pinned fixtures with hash-refusal, known-good historical cases as regressions, adversarial cases for the checker’s own refusal paths (a verifier that cannot say “wrong” is decoration), and clean-clone reproducibility runs on Linux/macOS/Windows at every milestone. The attestation feed additionally publishes its own method version and inputs so any third party can re-derive any attestation ever issued.
How will the work be maintained after delivery?
Maintenance is not an afterthought — it is Milestone 4: six months of operated service, explicitly priced and delivery-gated (the Rescue Node’s ongoing-operation grants are the GMC’s own precedent for funding verification infrastructure as a service). Beyond M4, if the community finds the service valuable, I’d return with a small maintenance or retrospective ask rather than pad this one.
Costs
What is the acceptance criteria?
M1: public repo (MIT); full UARS distribution audit since launch published with re-run commands; a GMC member reproduces a sampled check end-to-end from the README in under fifteen minutes.
M2: every balance submission since Saturn 1 verified with published methodology; live signed attestation feed on cadence; watchdog deployable by a third party from docs; refusal-path tests green.
M3: risk API serving documented endpoints; integration dossier complete; corpus with per-case RPIP/spec citations; trust page live; the report delivered and reproducible end-to-end.
M4: feed and page demonstrably live across the period (public uptime evidence); Saturn 2 spec-tracking notes published as specifications land; quarterly one-paragraph status posts in this thread.
What is the proposed payment schedule for the grant?
This application requests $5,000 — Milestone 1, paid on delivery.
The full program is documented above so the committee can see exactly where this leads: four milestones, $28,000 total ($5,000 M1, $10,000 M2, $7,000 M3, $6,000 M4 operated service, paid $3,000 per quarter in arrears). I structure grant engagements in stages as a matter of discipline, not caution: every payment sits behind delivered work, every commitment decision stays small, and each subsequent stage is proposed in this thread only after the previous one is delivered and accepted. M1’s historical audit publishes before the first payment claim — the committee’s first decision is made looking at finished work, not a promise.
Roadmap sizing is anchored to the GMC’s own ledger (RPIP-29), so the committee never has to guess whether the numbers are calibrated:
The MEV Theft and Loss Report — a one-time measurement report — was awarded $15,000. M1–M3 deliver that class of report plus the reusable verification engine plus a live attestation product, at $22,000 against that anchor.
Treegen Testing Support established the precedent of paying for independent verification of oDAO-produced outputs; this extends the same principle to Saturn’s new value flows.
The Rescue Node’s ongoing grants are the precedent for M4’s operated-service model ($1,000/month here).
For scale: the full program is under a fifth of the Cyfrin education grant ($150,000) and — unlike content — produces an artifact that compounds: every attestation issued makes the “verifiably safe LST” claim older, deeper, and harder for any competitor to match.
Who will directly receive the payment?
0x1b25e18b373a86a59a5decdd8f9b68216ff63a6b
How will the GMC verify that the work delivered matches the proposed cadence?
Public commit history from week one; a short update in this thread at each milestone with a runnable “try it yourself” command; acceptance criteria above are checkable by any GMC member in under fifteen minutes per milestone — by design, since making verification cheap is literally the product.
What alternatives or options have been considered in order to save costs?
Four considered:
Requesting the full $28,000 program in a single decision — rejected in favor of the staged structure above.
Tracking submissions without recomputing them — rejected: tracking exists (Rocketwatch, Dune) and adds no new trust reduction.
A hosted-only service — rejected: a proof you can’t self-host relocates trust instead of removing it.
Dropping M4 from the roadmap — rejected: an unmaintained verifier decays into false confidence, and Saturn 2 is precisely when these checks are needed again.
Infrastructure costs are contained via public archive/beacon endpoints where rate limits allow; paid API access, if needed in M2/M4, is absorbed within the ask.
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?
None. I am not a GMC member and have no prior relationship with Rocket Pool or 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?
Juggervault – rETH Collateral Integration for Tokenized Energy Assets
What is the work being proposed?
We propose to integrate Rocket Pool’s rETH as a collateral option and yield-bearing asset within Juggervault’s tokenization platform. This would allow project developers and investors to use rETH as collateral for tokenized energy assets, and enable rETH holders to earn additional yield by providing liquidity to Juggervault’s asset pools. The work includes smart contract development, integration with Rocket Pool’s oracle system, and a pilot deployment with a Nigerian energy project.
Is there any related work this builds off of?
This builds off Juggervault’s existing MVP on testnet, our regulatory engagement with the Nigerian SEC and CBN, and our ongoing pilot negotiations with a solar developer and the Abia State Government. It also builds on Rocket Pool’s existing rETH liquid staking infrastructure and oracle system.
Will the results of this project be entirely open source?
Yes. The integration smart contracts will be published under an MIT license. Any modifications to Juggervault’s core platform to support rETH integration will also be open-sourced.
Benefit
Group
Benefits
Potential rETH holders
They gain a new use case for rETH as collateral for real-world infrastructure assets, potentially earning additional yield beyond staking rewards.
rETH holders
Existing rETH holders can earn additional yield by providing liquidity to Juggervault’s asset pools, creating a new revenue stream from African energy infrastructure.
Potential NOs
Node operators can diversify their rETH usage and potentially earn fees from Juggervault’s platform.
NOs
Existing node operators gain access to a new, regulated RWA tokenization platform that can utilize rETH, expanding the utility of their holdings.
Community
Rocket Pool gains visibility in the African RWA tokenization market, expanding its global footprint and demonstrating rETH’s utility beyond traditional DeFi.
RPL holders
Increased utility and demand for rETH could indirectly benefit RPL holders through increased protocol adoption and liquidity.
Which other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?
Nigerian energy project developers who gain access to new financing mechanisms.
The Abia State Government and other state-level partners.
The broader African RWA tokenization ecosystem.
Work
Who is doing the work?
The work will be led by Henry Onyebuchi (Founder & CTO, Juggervault) and Kingsley (Lead Developer), with support from the Juggervault team. We will also engage external auditors for security reviews.
What is the background of the person(s) doing the work?
Henry Onyebuchi has over 8 years of experience as a blockchain engineer, having built and scaled a decentralized exchange with 5,000+ users and a non-custodial wallet startup in Nigeria that grew to profitability within 18 months. Kingsley has deep expertise in EVM/Solidity/Rust and a proven track record of delivering robust smart contract solutions. Our entire team has a combined 22 years of experience in blockchain, finance, and African markets.
What is the breakdown of the proposed work, in terms of milestones and/or deadlines?
Month 1: Smart contract design for rETH collateral integration.
Month 2: Development and testnet deployment.
Month 3: Security audit and integration with Rocket Pool oracle.
Month 4: Pilot deployment with a Nigerian energy asset.
How is the work being tested? Is testing included in the schedule?
Testing is included at each milestone. Unit tests and integration tests will be conducted on testnet. A comprehensive security audit by a third-party firm will be completed before mainnet deployment.
How will the work be maintained after delivery?
Juggervault will maintain the integration as part of its core platform. We will monitor performance, respond to issues, and upgrade the contracts as needed.
Costs
What is the acceptance criteria?
Smart contracts for rETH collateral integration are deployed and functional on testnet.
Successful integration with Rocket Pool’s oracle system.
Security audit completed with no critical findings.
Pilot deployment with a Nigerian energy asset using rETH as collateral.
What is the proposed payment schedule for the grant? How much USD $ and over what period of time is the applicant requesting?
We are requesting $30,000, paid in three tranches:
$5,000 upon approval (for development start).
$5,000 upon testnet deployment (milestone 2).
$5,000 upon mainnet deployment and pilot launch (milestone 4).
Who will directly receive the payment?
Henry Onyebuchi (Founder, Juggervault) – wallet address to be provided upon approval.
How will the GMC verify that the work delivered matches the proposed cadence?
We will provide bi-weekly progress reports, including code commits, testnet transactions, and audit results. The GMC will have access to our public GitHub repository and can verify milestones through testnet interactions.
What alternatives or options have been considered in order to save costs for the proposed project?
We considered using a simpler integration that would not require full oracle integration, but determined that full integration would provide the most value to the Rocket Pool community and ensure security. We also plan to reuse existing Juggervault infrastructure to minimize new development costs.
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?
No. We are not members of the GMC and have no direct financial interest in Rocket Pool beyond this proposed integration.
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?
Juggervault will benefit from the successful integration by gaining a new collateral option for its platform. However, this benefit is aligned with the interests of Rocket Pool, as it expands rETH’s utility and adoption. No other protocols or projects in which the recipient has a vested interest will benefit directly.
I’d like to add a read-only preflight mode to the Smart Node updater:
rocketpool update --check
The goal is to let node operators check whether their current setup is ready for the target Smart Node release before the CLI is replaced, services are stopped, or configuration changes are applied.
The command would reuse existing Smart Node upgrade and config logic and return a simple result:
PASS
WARN
BLOCK
Example:
Current version: vX.Y.Z
Target version: vX.Y+1.Z
PASS Platform supported
PASS Configuration can be migrated
PASS Docker requirements satisfied
WARN Setting X is deprecated
Result: READY WITH WARNINGS
No files, services, or configuration were changed.
The first version would focus only on checks Smart Node can determine reliably from the local environment, such as:
OS / architecture support
loading the existing config
testing config migration without saving it
deprecated or invalid settings
Docker / Compose requirements
release-specific prerequisites where available
This is not intended to be another monitoring tool, dashboard, validator health checker, or alerting system.
Related work
This builds directly on existing Smart Node upgrade code.
The updater already downloads and verifies the target binary, detects the target version, replaces the CLI, stops services, installs the new Smart Node stack, and restarts it.
The installer also backs up and migrates configuration.
The missing piece is a simple way to run the important compatibility checks before committing to the upgrade.
Open source
Yes.
The work will be open source and designed to fit the existing Smart Node codebase and license.
Benefit
The main benefit is for node operators.
It gives them a clear answer before an upgrade starts and can catch problems earlier, instead of discovering them after services have already been stopped or the installation has changed.
It should also reduce avoidable support issues around upgrades and make future Smart Node releases easier to operate safely.
Work
Who is doing the work?
Akira Nakao.
I’m a senior software engineer / software architect with 10+ years of experience in backend systems, infrastructure, Docker, Kubernetes, AWS, CI/CD, Go, Python, TypeScript, and Web3 development.
My recent work has included production automation, distributed services, deployment systems, observability, and reliability-focused engineering.
Milestones
Milestone 1 — Core preflight
Weeks 1–2
add rocketpool update --check
detect current and target versions
download and verify the target binary without replacing the current CLI
load the existing config
test migration/default updates without saving changes
add PASS / WARN / BLOCK results
add initial tests
verify that services and persistent config are not modified
Milestone 2 — Prerequisites and polish
Weeks 3–4
add relevant local release prerequisite checks
improve operator-facing error messages
add final READY / READY WITH WARNINGS / NOT READY result
add regression and non-mutation tests
add documentation
prepare the implementation for upstream review
Testing
Testing is included in both milestones.
The most important requirement is that --check must be safe to run.
Tests will cover:
successful upgrades
configuration migration failures
warnings
blocking conditions
target-version handling
download / verification failures
confirmation that the installed CLI, config, containers, and services are unchanged
Maintenance
The feature should reuse existing Smart Node logic instead of maintaining a separate compatibility database.
Release-specific checks should live with the Smart Node release that needs them so they stay close to the actual upgrade code.
Costs
Acceptance criteria
The work is complete when:
rocketpool update --check works against a target Smart Node release
it runs without modifying the active installation
it can test config migration without saving changes
it returns PASS / WARN / BLOCK results
it reports a clear overall upgrade-readiness result
tests cover failure and non-mutation cases
documentation is included
the implementation is ready for Smart Node maintainer review
Upstream merge itself would not be a dependency, since the final merge decision belongs to Rocket Pool maintainers.
Payment
Total request: $5,000 USD over approximately four weeks.
OVH has recently warned us of a price hike effective November 1st.
Whereas previously the GMC awarded us enough to cover the $771.25 monthly bill, the new price for our existing hardware will be $941.25.
This leaves us a few options for how to proceed:
1. GMC awards an additional $170 monthly to cover the price increase
This option is fairly straightforward, and the least amount of work for me, so I’m open to it, but understand if we’re pushing beyond the pale.
2. GMC awards an additional $800 total for the course of the grant
This option would mean I have to go to OVH and lease 5 new baremetals at around the same cost to ethcoordinate as we are already paying, but one-time setup fees and an overlap in leases would be incurred.
I would then be able to downsize the rescue node hosts from 4 TB volumes to 2 TB volumes and rely on rolling expiry to keep our (supernode) services within provisioned limits
Though this may work out to be slightly more costly than option 1, subsequent grant renewals will be less expensive.
3. GMC awards no additional funding
This option would essentially mean downsizing the deployment. Right now we have 5 baremetals, and removing one of them would roughly cover the shortfall. I could, for example, shut down our lighthouse node and redirect its traffic to our lodestar node. This would come with some risk of degraded services to lighthouse users, as lighthouse’s validator client may not be interoperable with lodestar when it comes to doppelganger detection.
Rescue Node documentation would then be updated to indicate that lighthouse users may have to disable doppelganger detection before connecting.
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?
Benefit
Please refer to previous application
Which other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?
Please refer to previous application
Work
Who is doing the work?
Me, on behalf of ethcoordinate
What is the background of the person(s) doing the work? What experience do they have with such projects in the past?
Please refer to previous application
What is the breakdown of the proposed work, in terms of milestones and/or deadlines?
Please refer to previous application
How is the work being tested? Is testing included in the schedule?
Please refer to previous application
How will the work be maintained after delivery?
Please refer to previous application
Costs
What is the acceptance criteria?
N/A
What is the proposed payment schedule for the grant? How much USD $ and over what period of time is the applicant requesting?
N/A
Who will directly receive the payment? (Required — the GMC can only send grants directly to a recipient address and cannot accept invoices.)
ethcoordinate (fka ethstaker)
How will the GMC verify that the work delivered matches the proposed cadence?
N/A
What alternatives or options have been considered in order to save costs for the proposed project?
N/A
Have you already been compensated by the RP protocol in any way for this work?
N/A
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).
I can make a full list of my engagements in the ethereum / crypto ecosystems available to the GMC, but I have none to disclose that would impact my ability to work on the Rescue Node.
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?
Node Readiness Evidence Toolkit: A Reproducible Pre-Onboarding Assessment for Prospective Rocket Pool Node Operators
What is the work being proposed?
I propose to build rp-readiness, a standalone, open-source Go command-line tool that helps prospective Rocket Pool node operators assess a candidate Linux host before production onboarding.
The goal is not to create a hardware “score” or promise validator performance. Instead, the tool would produce a transparent, source-linked readiness report showing:
what was measured;
which Rocket Pool guidance or requirement the measurement relates to;
whether the observation appears to meet that guidance;
what remains uncertain or unverified and
what the prospective operator should investigate next.
The first release would support one clearly documented Rocket Pool onboarding baseline. It would remain a standalone tool and would not claim to be an official Smartnode command or require changes to the Smartnode codebase.
The proposed scope has four main parts.
1. Passive host assessment by default
rp-readiness would inspect relevant host properties without changing system configuration or services, including:
CPU architecture and available processor information;
system memory and swap;
operating-system/runtime characteristics;
disk capacity and relevant storage information and
prerequisites relevant to the documented onboarding baseline.
2. Explicitly opt-in active measurements
Where static inspection is insufficient, the user could explicitly authorize bounded measurements such as:
temporary file-based disk I/O measurements and
outbound network/connectivity measurements.
Active tests would clearly disclose their expected duration, temporary storage use and load before execution.
They would be intended for candidate, non-production machines, not for stress-testing active validators.
3. Evidence-oriented reporting
The tool would provide both human-readable and JSON output.
Results would distinguish among states such as:
MEETS GUIDANCE
REVIEW
UNVERIFIED
A missing or inconclusive measurement would never silently become a passing result.
Reports would contain the actual observations, the applicable versioned guidance, source references and relevant limitations.
4. A safe-to-share support report
A separate allowlisted output schema would omit common identifiers such as usernames, hostnames, IP addresses and local filesystem paths.
This is intended to make community troubleshooting easier while reducing accidental information disclosure. It would not claim to provide guaranteed anonymity and users would still be instructed to review reports before sharing them.
The tool would not:
access validator keys;
sign transactions;
submit transactions;
automatically modify system configuration;
automatically tune a host;
write directly to raw block devices;
scan external networks or
claim that a machine is guaranteed to perform successfully as a Rocket Pool validator.
Temporary writes used by an explicitly authorized disk test would be bounded, disclosed beforehand and tested for cleanup.
Similarly, successful outbound connectivity measurements would not be represented as proof of inbound reachability, long-term network quality or future validator performance.
Is there any related work this builds off of?
Yes.
Rocket Pool already publishes documentation for preparing node hardware and describes the system requirements prospective operators should consider. The documentation also points operators toward established measurement tools where appropriate.
The proposed contribution is therefore not another hardware-requirements document and not a replacement for existing tools.
Instead, rp-readiness would combine existing guidance and measurements into a reproducible workflow with:
a versioned guidance profile;
standardized collection of relevant host evidence;
explicit UNVERIFIED states;
machine-readable output;
reproducible test behavior and
a consistent support-report format.
There is also a Round 40 proposal titled “Smart Node Upgrade Preflight - rocketpool update --check.” That proposal addresses software upgrade readiness for existing Smartnode installations.
This proposal addresses a different stage of the operator lifecycle: evaluating a candidate machine before onboarding it as a Rocket Pool node.
I would actively seek community feedback if reviewers identify overlap between the projects. No Smartnode integration or approval from Rocket Pool maintainers is assumed as part of this grant.
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.
I propose to publish the code, automated tests, documentation, example reports and guidance-profile definitions under the GPL-3.0 license.
A new public repository would be created for the work after award.
Third-party dependencies would retain their respective licenses. No confidential, employer-owned or university-owned code would be incorporated without the appropriate authorization.
Benefit
Group
Benefits
Potential rETH holders
Indirect benefit. A clearer onboarding process for prospective node operators can reduce uncertainty around participating in Rocket Pool’s operator ecosystem. This proposal does not claim that the tool will directly increase rETH adoption or returns.
rETH holders
Indirect benefit. Better pre-onboarding visibility into candidate-host constraints may help operators identify obvious infrastructure issues before production use. The project does not promise improved validator reliability or financial performance.
Potential NOs
Primary beneficiary. Prospective node operators would receive a repeatable assessment of a candidate host, with measurable evidence, source-linked guidance, clearly identified unknowns and actionable diagnostics before committing the machine to production onboarding.
NOs
Existing operators could use the passive portions when evaluating replacement or additional hardware. Active measurements would not be recommended on live validator systems.
Community
The project would provide a consistent and reproducible support-report format that could make hardware-readiness discussions easier to interpret and reproduce.
RPL holders
Indirect ecosystem benefit. If useful in practice, lowering uncertainty for prospective operators could support the broader Rocket Pool node-operator ecosystem. No token-price or financial-performance claim is made.
Which other non-RPL protocols, DAOs, projects or individuals would stand to benefit from this grant?
Some of the generic measurement and reporting components could also be useful to Ethereum home stakers and execution/consensus-client communities.
Rocket Pool-specific guidance would remain a separately versioned profile rather than being presented as universal Ethereum requirements.
There is no exclusive commercial beneficiary built into the proposed design.
Work
Who is doing the work?
I, Alireza, would implement, test, document and maintain the proposed first release.
I am an incoming M.Sc. student at the University of Alberta Blockchain Lab, with research interests in blockchain, distributed systems and distributed algorithms.
My academic affiliation is provided as background. This application does not represent an endorsement, financial commitment, resource commitment or grant-administration commitment by the University of Alberta.
I would confirm any applicable university, funding or academic obligations before accepting an award.
What is the background of the person(s) doing the work? What experience do they have with such projects in the past?
My background is primarily in distributed systems, backend infrastructure, cloud systems and Go/Python software engineering.
Relevant experience includes:
KubeHarvest research: work involving Go, Kubernetes, cgroups, NRI and resource forecasting for cloud resource management;
DeterSL: work involving WebAssembly execution and locality-aware scheduling;
Broker: a distributed message-broker project implemented in Go using Raft-style distributed-systems concepts.
This project is deliberately scoped around the areas where that background is most applicable: system inspection, controlled measurements, reproducibility, failure handling, distributed-systems operational concerns, structured reporting and Go-based tooling.
What is the breakdown of the proposed work, in terms of milestones and/or deadlines?
I propose a six-week delivery period from scope agreement, with three acceptance-based milestones.
The estimated workload is approximately 18 implementation/testing/documentation hours per week for six weeks, plus 12 hours reserved for post-delivery maintenance, for a total planned effort of approximately 120 hours.
Milestone
Schedule
Deliverables
Proposed Payment
M1 — Baseline and passive assessment
Weeks 1–2
Safety policy; source-linked onboarding baseline; versioned result schema; passive host probes; unit tests; reproducible sample report
Tagged public release; end-to-end evaluation; installation and usage documentation; limitations report; maintenance/update notes; maintainer handover documentation
$1,500
Academic commitments and any relevant institutional obligations would be confirmed before accepting an award.
How is the work being tested? Is testing included in the schedule?
Yes. Testing is included throughout all three milestones rather than being deferred until the end.
Unit testing would cover areas including:
result and guidance parsing;
unsupported environments;
malformed or incomplete input;
guidance evaluation;
report generation and
handling of UNVERIFIED states.
Integration testing would include failure and safety cases such as:
insufficient permissions;
interrupted measurements;
command/network timeouts;
inadequate temporary disk space;
temporary-file cleanup;
unexpected probe failures and
confirmation that Smartnode services and configuration are not modified.
The active-test workflow would require explicit acknowledgment that it is intended for a non-production candidate host. This acknowledgment is a safety mechanism; it would not be presented as technical proof that no validator is running.
I propose evaluation on at least three documented Linux configurations:
one physical amd64 host suitable for active storage measurements and
two virtualized configurations used for resource, compatibility and failure-path testing.
Results obtained from virtualized systems would not be presented as evidence of native hardware performance.
ARM64 builds may be checked through CI, but native ARM64 performance support would not be claimed unless suitable physical ARM64 hardware is actually tested.
External Rocket Pool operator testing would be welcome, but successful delivery would not depend on assuming that community testers can be recruited.
The release would include:
reproducible test commands;
machine-readable sample output;
documented test environments;
documented failure cases and
an explicit limitations section distinguishing current measurements from evidence of long-term reliability.
How will the work be maintained after delivery?
The proposal includes 30 days of in-scope defect maintenance following final acceptance, with approximately 12 hours reserved for that work within the requested budget.
The versioned Rocket Pool guidance profile would be separated from the underlying measurement implementation as much as practical. This is intended to make changes to documented requirements easier to review without unnecessarily changing measurement code.
The handover documentation would explain:
how guidance sources are updated;
how guidance/profile changes are versioned;
how test fixtures are added;
how release validation is reproduced and
the known boundaries of the first release.
The included maintenance period covers defects within the accepted scope.
New features, new operating-system/platform support, substantial changes caused by future onboarding requirements, long-term support or official Smartnode integration would require separate discussion rather than being implicitly included in this grant.
Costs
What is the acceptance criteria?
The grant would be considered complete when all of the following have been delivered and accepted:
Public release
A publicly accessible, appropriately licensed release builds and runs using documented steps on the agreed Linux baseline.
Passive assessment
The agreed passive system-inspection functionality operates without modifying Smartnode services or host configuration.
Controlled active measurements
Any active disk or network tests require explicit opt-in and clearly disclose and bound their temporary writes, expected duration and system load.
Evidence-oriented output
Both readable and JSON output provide measured evidence, applicable versioned guidance and clear UNVERIFIED states where sufficient evidence is unavailable.
Shareable reporting
The shareable report schema excludes the identifier fields defined by the project’s safety policy, including usernames, hostnames, IP addresses and local paths.
Automated testing
Automated tests cover the agreed probes, report generation, failure paths, timeouts, temporary-file cleanup and relevant safety properties.
Documented evaluation
The tool is evaluated on the three agreed documented configurations, with test commands, environment descriptions, results and known limitations published.
Documentation and handover
Installation instructions, usage examples, maintenance/update instructions, a support-report example and a limitations document are included.
A standalone public release is sufficient for acceptance. An upstream Smartnode merge or official Rocket Pool integration is not promised by this application.
What is the proposed payment schedule for the grant? How much USD $ and over what period of time is the applicant requesting?
I am requesting USD $5,000 total over approximately six weeks, payable only after acceptance of each milestone:
Milestone 1: $1,500
Milestone 2: $2,000
Milestone 3: $1,500
No upfront payment is requested.
The proposed cost basis is:
approximately 108 hours of implementation, testing and documentation at an effective rate of $40/hour = $4,320;
12 hours of included post-delivery maintenance at $40/hour = $480 and
up to $200 for test infrastructure.
Total requested: $5,000.
This is my proposed project budget and is not intended to imply a published or predetermined Rocket Pool award amount.
Who will directly receive the payment?
Alireza will directly receive the grant payment if the application is approved.
Payment details can be provided directly to the GMC if the grant is approved.
How will the GMC verify that the work delivered matches the proposed cadence?
Development would take place in a public repository with milestone-tagged issues and visible commit history.
For each milestone, I would post an update containing:
the relevant release/commit tag;
the milestone deliverables;
test results;
reproducible commands or examples;
known limitations or deviations, if any and
the artifacts being presented for acceptance.
Reviewers would be able to reproduce the passive checks on a suitable Linux test host.
Active measurements could also be reproduced, but only after the reviewer explicitly authorizes the disclosed temporary writes and system/network load.
Payment requests would therefore reference accepted artifacts and reproducible milestone evidence, rather than merely reporting hours spent.
What alternatives or options have been considered in order to save costs for the proposed project?
I considered three levels of scope.
1. Documentation-only checklist
This would be less expensive, but it would largely reproduce information that already exists and would not generate standardized, machine-readable evidence.
2. Standalone readiness tool — proposed scope
This provides automated evidence collection and reporting while keeping the implementation bounded and avoiding changes to Rocket Pool’s production Smartnode code.
3. Full Smartnode integration, GUI or continuous monitoring service
These approaches would require substantially more implementation, integration, review and long-term maintenance.
I therefore selected the standalone tool as the smallest scope that provides meaningful automation and reproducibility while limiting cost and integration risk.
The implementation would also reuse established operating-system interfaces and existing measurement utilities where appropriate instead of rebuilding mature functionality unnecessarily.
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? (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).
I am not a member of the GMC and I am not aware of any conflict of interest relevant to this application.
The approved grant recipient would, naturally, receive the grant payment if this application is successful.
My academic affiliation is provided as background only. This proposal does not commit the University of Alberta to supervision of the grant, provision of resources, endorsement of the application or administration of the payment.
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.
The intended software deliverables will be public and open source. I do not intend to use the grant to subsidize a proprietary product or another protocol in which I have a financial interest.
Any overlap with other funded work would be disclosed before accepting an award and the same work would not be billed to multiple funding sources.
Creatives Onchain proposes to complete and harden Rocket Pool Upgrade Effects Gate (rsg), an open-source verification tool for checking whether a Rocket Pool protocol upgrade produces the declared typed RocketStorage effects and no unaccounted-for effects within a clearly defined observation boundary.
For a pinned pre-upgrade state and upgrade payload, the completed tool will:
replay the upgrade payload against the pinned Ethereum pre-state;
capture RocketStorage’s public typed mutator calls;
record each mutation’s caller, type, raw key, semantic path, old value, new value, and execution order;
decode opaque bytes32 keys into Rocket Pool-specific meanings;
compare observed effects against a source-anchored expected-effects manifest;
validate direct outbound calls from the upgrade contract by target, selector, ETH value, and multiplicity;
return PASS, FAIL, or UNKNOWN, failing closed when an effect cannot be safely interpreted; and
produce reproducible JSON and Markdown proof artifacts.
The initial golden fixture is the executed Rocket Pool v1.4 / Saturn 1 mainnet upgrade, using:
We built the MVP before applying to demonstrate feasibility. It currently captures the executed Saturn 1 transaction, semantically decodes its RocketStorage effects, compares them against a source-anchored manifest, runs adversarial fixtures, and produces a PASS attestation for the current historical fixture.
The MVP is not being presented as completion of this grant. The funded work is the remaining acceptance-grade hardening: pinned replay, full fail-closed capture semantics, correct per-call typed state handling, manifest/review hardening, deterministic proof guarantees, adversarial validation, and reproducible release packaging.
A PASS will mean only that the payload conforms to the manifest within the documented observation boundary. It will not mean the upgrade has been audited or proven universally safe.
Is there any related work this builds off of?
Yes.
Rocket Pool’s existing v1.4 verification work checks that published source/deployed contracts correspond to the intended release. Upgrade Effects Gate checks a different invariant: what the upgrade execution actually changes in RocketStorage.
This distinction is supported by the public Saturn 1 verification record, where the independent verifier confirmed the deployed contracts while explicitly stating that the protocol parameters set by the upgrade contract were not checked.
The project also reuses existing Ethereum RPC and tracing/execution infrastructure rather than building a new EVM.
The Rocket Pool-specific work is the semantic key model, expected-effects manifest, complete/fail-closed effect reconciliation, outbound-call checks, adversarial fixtures, and reproducible attestation format.
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.
Code, manifests, fixtures, key catalogues, tests, proof artifacts, CI, and documentation will be public under MIT OR Apache-2.0. No proprietary API, private dataset, or hosted service is required for acceptance.
Benefit
Group
Benefits
Potential rETH holders
N/A as a direct staking/onboarding benefit. Indirectly, the tool adds another independently reproducible check around protocol upgrades affecting Rocket Pool’s persistent control state.
rETH holders
Indirect benefit from stronger verification of protocol-transition effects. It does not directly change rETH yield, liquidity, or UX.
Potential NOs
N/A as a direct node-operator onboarding tool.
NOs
Indirect benefit from stronger verification of protocol upgrades that can change protocol settings, permissions, and contract registrations. It does not modify Smartnode or node operations directly.
Community
Primary direct benefit. Security contributors, delegates, reviewers, and release engineers gain a reproducible way to inspect and attest what a Rocket Pool upgrade changed in RocketStorage.
RPL holders
Governance participants gain inspectable execution evidence for protocol upgrades affecting persistent governance and protocol settings.
Which other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?
No other protocol is a direct funded beneficiary.
Security researchers and other upgradeable EVM projects may find the general manifest/conformance approach reusable, but the funded semantic catalogue, fixture, and verification rules are specifically for Rocket Pool.
Work
Who is doing the work?
The work will be delivered by Creatives Onchain, with Micheal Dean as the technical lead.
Micheal Dean — Lead Engineer
Responsibilities include:
EVM replay and trace handling;
RocketStorage mutation capture;
semantic decoding;
manifest integration;
conformance and fail-closed logic;
external-call verification;
proof-bundle generation;
adversarial testing;
CI; and
release reproducibility.
Akeem Adelanke — Project Manager / Delivery & Documentation
Responsible for milestone coordination, acceptance tracking, public progress updates, reproducibility documentation, reviewer instructions, and ensuring each deliverable can be independently verified by the GMC from the public repository
What is the background of the person(s) doing the work? What experience do they have with such projects in the past?
Micheal Dean is the technical lead for Creatives Onchain on this grant.
The strongest project-specific evidence of feasibility is the working Rocket Storage Gate MVP itself. Before funding, the team has already demonstrated:
Rust-based Ethereum trace handling;
typed RocketStorage mutation extraction;
semantic key decoding;
source-anchored manifest comparison;
PASS / FAIL / UNKNOWN verdict logic;
external-call checking;
deterministic normalized evidence;
adversarial fixtures; and
automated CI.
The grant therefore does not depend on an untested architecture. Funding is for completing and hardening the original scope to the acceptance standard below.
What is the breakdown of the proposed work, in terms of milestones and/or deadlines?
Milestone 1 — Replay and Capture Hardening
End of Week 2
complete the pinned pre-state replay path;
verify chain, block hash, upgrade payload, upgrade contract, RocketStorage address, and source commit before execution;
complete correct handling of RocketStorage’s public typed mutator surface;
ensure correct per-call old/new values, including ordered and arithmetic mutations;
make unknown or unsupported RocketStorage calls fail closed instead of being silently skipped; and
finalize frozen offline fixtures.
Milestone 2 — Conformance Gate and Golden Proof
End of Week 4
harden the expected-vs-observed comparator;
finalize semantic manifest and review-record workflow;
enforce type, value, deletion, multiplicity, and undeclared-write checks;
validate declared outbound calls by target, selector, ETH value, and multiplicity;
produce the complete Saturn 1 golden attestation; and
complete the adversarial corruption suite.
Milestone 3 — Reproducible Release
End of Week 5
clean Linux/container reproducibility;
final CI and acceptance commands;
deterministic proof-bundle checks;
usage and trust-model documentation;
manifest-authoring guide;
tagged open-source release; and
60-day defect-fix period after acceptance.
The existing MVP is feasibility work and is not being billed retroactively.
How is the work being tested? Is testing included in the schedule?
Yes.
Testing is part of every milestone. The final suite will verify at least:
undeclared RocketStorage writes;
wrong expected values;
missing required deletions;
swapped implementation addresses;
duplicate or incorrect mutation multiplicity;
type drift;
unknown/unsupported RocketStorage calls;
unexpected external targets or selectors;
incorrect external-call multiplicity;
incorrect chain/block/storage anchors; and
stable normalized output when manifest declaration order changes.
Core tests will run offline from frozen fixtures. A separate integration path will support a reviewer-supplied archive RPC.
How will the work be maintained after delivery?
The Saturn 1 fixture, manifest, and attestation will be version-pinned and reproducible without a hosted service.
Creatives Onchain will provide 60 days of defect fixes after final acceptance.
Documentation will explain how a later upgrade manifest can be added. Authoring or maintaining future Saturn 2 or later manifests is outside this grant unless separately scoped.
Costs
What is the acceptance criteria?
The grant is complete when a reviewer can verify that:
A documented command replays the pinned Saturn 1 upgrade payload against the pinned pre-upgrade state and produces the expected attestation.
RocketStorage’s public typed mutator calls are captured with correct per-call caller, operation, key, semantic path, old value, new value, and ordering.
Unknown selectors, undecodable keys, incomplete traces, or unsupported effect shapes cannot silently disappear or result in PASS.
Every required manifest effect matches the expected type, value, deletion semantics, and multiplicity, and undeclared effects cannot pass.
Direct outbound calls from the upgrade contract are checked against the declared target, selector, ETH value, and multiplicity.
automatic Saturn 2 support before its upgrade payload is stable.
Frozen fixtures also allow normal testing and acceptance without requiring a grantee-operated archive RPC.
Have you already been compensated by the RP protocol in any way for this work?
No.
The existing MVP was self-funded as feasibility evidence. This grant requests payment only for the future completion and hardening work described above.
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.
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 direct financial benefit to another protocol or project is expected.
The deliverable is open-source and Rocket Pool-specific. Creatives Onchain may gain experience and reputation from completing the work, but no other protocol, token, or proprietary product is part of the funded scope.
Smartnode Safe Recovery Planner and Per-Key Diagnosis
What is the work being proposed?
Validator recovery is one of the worst times for a node operator to be unsure about what Smartnode has actually changed.
Today, Smartnode can write validator keys as they are found before it knows whether the rest of the validator set can also be recovered. On a node with mnemonic-derived and imported/custom keys, recovery can write several keys and then fail when a later key cannot be derived or loaded. The command has failed, but the node has already been modified, leaving the operator to work out what was recovered and what still needs attention.
The consequences are not theoretical. Issue #440 records an operator interpreting a test-recovery failure as evidence that their seed was wrong and exiting double-digit pools, only to later confirm that the seed was valid.
We propose to complete and upstream a plan-before-write recovery flow for:
wallet recover
wallet rebuild
wallet test-recovery
Smartnode will first discover and validate every in-scope validator key without touching the live keystore. Only after the recovery plan is complete will writes begin.
By default, if any required key is unresolved, invalid, or conflicting, no validator-key writes will occur. An operator who intentionally wants a partial recovery can explicitly opt in with --allow-partial-recover, which will write only validated keys and clearly report what happened for each pubkey.
The work also includes:
per-key discovery and write results;
the inactive-validator filtering fix;
legacy minipool and megapool coverage;
safe/idempotent reruns;
human-readable and JSON/API output;
recovery documentation for imported keys and solo migrations.
This does not attempt transactional rollback across validator clients or claim to recover an imported key that has already been lost. The guarantee is narrower: Smartnode determines the recovery state before live keystore mutation begins.
Is there any related work this builds off of?
Yes. This work addresses Smartnode issues #407 and #572. Issue #440 provides operator-impact context.
Before applying, we asked whether #407 and #572 were still wanted and whether anyone was already working on them. Sma@0xforna@0xforna@0xfornaxtnode maintainer @0xfornax confirmed that they are still wanted and that they are not aware of anyone currently working on them:
We have also opened an unfunded feasibility prototype against current Smartnode master:
The prototype demonstrates the recovery-plan model, plan/commit separation, inactive-validator filtering, per-key outcomes, and a writer-spy test showing zero writes when default recovery contains an unresolved key.
It is not the completed grant deliverable. Full integration into the recovery commands, CLI/API behavior, production writer adapters, broader failure testing, documentation, and maintainer-requested revisions remain to be completed.
The prototype work is not being billed retroactively.
Will the results of this project be entirely open source?
Yes. All Smartnode code, tests, fixtures, and documentation produced under the grant will be public and contributed under the repository’s existing license.
Benefit
Group
Benefit
Potential rETH holders
More reliable node-operator recovery reduces avoidable operational risk.
rETH holders
Fewer recovery mistakes and avoidable validator downtime.
Potential NOs
A clearer and safer disaster-recovery path.
NOs
Direct benefit: recovery fails safely by default and reports what happened for each validator key.
Community
Fewer ambiguous recovery cases and clearer information when helping operators troubleshoot.
RPL holders
Indirect benefit through better operator reliability and confidence.
Which non-Rocket Pool groups benefit?
The implementation is Rocket Pool-specific. The general plan-before-write pattern may be useful to other validator tooling projects, but no external protocol or commercial product is needed for the work to be useful.
Olamide will lead implementation, testing, and technical revisions. Ifedemiji will manage milestones, documentation, coordination, and delivery.
What is the background of the team?
Crackdevs works on open-source protocol tooling and testing infrastructure.
Our most relevant execution evidence is the Smartnode feasibility PR itself. Before requesting funding, we traced the current recovery path, implemented the recovery-plan model in Go, separated read-only planning from writes, added per-key results, and built failure-focused tests around the zero-write requirement.
The team has also worked on protocol testing and failure-recovery tooling across projects including Zcash and Mina.
Milestones and deadlines
Duration: 5 weeks
Milestone
Deliverables
Payment
M1 — Production integration foundation
Incorporate maintainer feedback, confirm validator-state handling, adapt the prototype to current Smartnode abstractions, and integrate the shared planner into the recovery flows.
$2,000
M2 — Recovery behavior and testing
Complete recover/rebuild/test-recovery integration, fail-closed default behavior, partial recovery, CLI/API results, production writer adapters, inactive-filter fix, failure handling, and rerun tests.
The main safety test is straightforward: if default recovery cannot resolve or validate every required key, the writer must record zero live keystore writes.
Coverage will include:
mnemonic-only recovery;
mixed mnemonic/custom keys;
missing custom key material;
invalid or mismatched key material;
derivation-limit failure;
already-installed and conflicting keys;
inactive/exited validators;
explicit partial recovery;
injected write failure;
safe reruns;
deterministic, secret-free CLI/API results.
Also, no operator mnemonic, private key, password, or keystore will be requested for testing.
How will the work be maintained?
We will provide a 90-day defect-fix period for issues within the delivered scope.
The implementation will live directly in Smartnode rather than as a separate service that Rocket Pool needs to operate.
Costs
Acceptance criteria
The grant is complete when:
The shared recovery planner is integrated into recover, rebuild, and test-recovery.
An unresolved, invalid, or conflicting required key produces zero live writes by default.
Partial recovery requires explicit opt-in and reports every relevant pubkey.
Write failures clearly report written, failed, and not-attempted results, with safe reruns.
Minipool/megapool state handling and inactive-validator filtering are covered by tests.
Human-readable and JSON/API output is deterministic and does not expose secret key material.
Tests, documentation, and reproduction instructions are complete.
A production-ready upstream PR is submitted and in-scope maintainer review feedback is addressed.
Final merge timing is controlled by Smartnode maintainers and is not part of the five-week acceptance requirement.
Proposed payment schedule
Total request: $5,800 over five weeks.
M1: $2,000
M2: $2,800
M3: $1,000
No upfront payment is requested.
The existing feasibility prototype is not included as paid work.
Work will remain public through the Smartnode PR and working branches.
Each milestone will include the relevant commits, completed acceptance items, test results, and short reproduction instructions. The zero-write requirement will be verified through automated tests.
What cost-saving alternatives were considered?
The work reuses Smartnode’s existing wallet, beacon-state discovery, custom-key handling, and validator-client infrastructure.
The grant does not include a separate service, dashboard, new cryptography, key custody, recovery of already-lost keys, cross-client transactional rollback, or a full live-node matrix across every validator client.
Have you already been compensated by Rocket Pool for this work?
No.
Conflict of Interest
Any conflicts of interest to disclose?
No.
Will another vested project benefit financially?
Other than Crackdevs receiving the stated compensation for completing the grant, no external protocol or project in which we have a vested interest will directly benefit financially.
I propose to complete and harden an open-source regression harness that tests the actual published Rocket Pool Smartnode release artifact in a clean, isolated Linux environment.
MVP repository:
The key distinction is that the harness begins where source-level CI ends: with the release artifact and generated stack that a node operator would actually use.
For a selected Smartnode release, the harness will:
download and verify the official Linux-amd64 release artifact;
confirm that the installed binary reports the requested Smartnode version;
configure Smartnode headlessly against Hoodi;
generate and validate the resulting Docker Compose stack;
start selected execution- and consensus-client profiles;
check execution and consensus endpoint readiness and chain identity;
check Engine API/JWT authentication;
detect persistent crash loops while allowing legitimate temporary startup restarts;
exercise stop/start recovery;
record the actual container image identities used;
inject defined JWT failure conditions; and
produce Markdown, JSON, JUnit, and sanitized diagnostic output with reproduction instructions.
The existing MVP was completed before this application and is not being billed retroactively. It establishes feasibility for the artifact-verification, headless configuration, Geth + Lighthouse, Besu + Teku, JWT-fixture, readiness, reporting, and CI portions of the architecture.
The funded Phase 1 will extend that work to four representative paths:
Geth + Lighthouse — baseline managed-client path and the primary live zero-byte JWT risk path identified during feasibility testing.
Besu + Teku — repaired control path for empty-JWT handling.
Nethermind + Teku — a separate managed execution-client JWT path.
The JWT suite will cover absent, zero-byte, malformed hexadecimal, incorrect-length, 0x-prefixed, bare-hex, read-only, and restart-persistence conditions.
Valid JWT material will accept both formats observed during testing:
^(0x)?[0-9a-fA-F]{64}$
The project is intentionally a bounded published-artifact regression harness. It is not a certification that Smartnode is defect-free, and I will not present it as an official Rocket Pool release gate unless Rocket Pool maintainers independently decide to adopt the supplied workflow.
During pre-submission feasibility testing, I ran 11 experiments against the signed Smartnode v1.23.0 release artifact. That work surfaced six installation, automation, or client-startup issues while following the proposed test path.
Most relevant to this grant, the testing confirmed materially different zero-byte JWT behavior across execution-client paths and reproduced a deterministic failure condition.
The technical investigation also traced the historical Besu zero-byte JWT problem to the period between v1.18.8 and its correction in v1.20.8, while showing that the same empty-file failure class remains reachable in different form on the current Geth and Nethermind paths.
The purpose of the harness is therefore not to encode one known bug. It is to test the broader class of release-artifact, generated-configuration, container-startup, and authentication failures that can escape source-level tests.
Phase 1 explicitly does not cover:
Rocket Pool contract correctness;
node registration;
minipool or megapool creation;
validator deposits or duties;
rewards;
withdrawals or exits;
Saturn 2 protocol behavior;
Ethereum fork-transition testing;
every possible EL/CL combination;
mainnet transactions; or
production wallets, mnemonics, validator keys, or operator data.
Is there any related work this builds off of?
Yes.
The project builds on Smartnode’s existing release artifacts, Docker deployment model, headless configuration support, Hoodi support, and networks-extra.yml.
Smartnode already has public workflows for building, linting, commit checks, and Go unit testing. In the v1.23.0 public workflow set I reviewed during feasibility testing, I did not find a workflow that starts from the published Linux release artifact and exercises the generated operator-facing Docker stack.
This project adds that separate black-box testing boundary. It does not replace Smartnode’s existing CI.
The project also does not duplicate the Round 40 Smart Node Upgrade Preflight — rocketpool update --check proposal.
The distinction is:
Upgrade Preflight
Published-Artifact Regression Harness
Evaluates an existing operator installation before an upgrade
Evaluates a published Smartnode release in a clean test environment
Checks local configuration and prerequisites
Performs installation/configuration and starts the generated stack
Operator-machine specific
Release-artifact specific
Runs before changing an operator’s machine
Exercises the release independently of an operator machine
Does not need a client test matrix
Runs defined managed and external client profiles
The original MVP design considered creating a private Ethereum network with Kurtosis. Feasibility testing showed that this was unnecessary for the Phase 1 checks and incompatible with the relevant v1.23.0 Lighthouse custom-network startup path.
Phase 1 therefore uses Hoodi with an explicit checkpoint-sync provider, reducing implementation complexity and avoiding a dependency that is not required for the intended checks.
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.
All grant-funded source code, tests, fixtures, client profiles, workflow files, reports, and documentation will be public under GPL-3.0.
No proprietary backend, paid API, private dataset, hosted-only component, or closed-source component is required for acceptance.
Benefit
Group
Benefits
Potential rETH holders
N/A as a direct staking or rETH-acquisition feature. There is an indirect reliability benefit from detecting defined node-software regressions before wider operator exposure.
rETH holders
Indirect benefit through better node-operator software reliability. I do not claim that this project directly increases rETH yield, liquidity, or demand.
Potential NOs
Fresh installs are particularly exposed to packaging and secret-generation problems because they do not have previously generated files to mask them. Public release-specific test evidence can identify these problems earlier.
NOs
Provides reproducible evidence for tested client paths and standardized diagnostics for distinguishing a release-level problem from a host-specific problem. It does not guarantee compatibility with every operator environment.
Community
Gives Smartnode contributors and support volunteers repeatable reproduction commands, structured failure classifications, sanitized diagnostics, and machine-readable results for release investigations.
RPL holders
Indirect operational-reliability benefit only. No RPL price or demand claim is made.
Which other non-RPL protocols, DAOs, projects, or individuals would stand to benefit from this grant?
Ethereum execution- and consensus-client maintainers may benefit when a failing profile produces a small, reproducible client-specific case.
The general artifact-first testing approach may also be useful to other staking-software projects.
However, the funded profiles, configuration logic, fixtures, assertions, reports, and workflow are specifically designed for Rocket Pool Smartnode. No external protocol or partner is required for the grant to succeed.
Work
Who is doing the work?
I am Gospel Ifeadi, the owner of the project, lead engineer, and primary implementer.
I will be responsible for:
project architecture;
Smartnode release-artifact verification;
client-profile implementation;
Docker and process orchestration;
JWT fixtures and assertions;
readiness and lifecycle testing;
reporting and diagnostics;
CI integration;
automated testing;
documentation; and
milestone delivery.
What is the background of the person(s) doing the work? What experience do they have with such projects in the past?
I work on blockchain backend infrastructure and developer tooling, including Docker-based environments, CI automation, failure-focused testing, and protocol tooling.
The strongest directly relevant evidence for this proposal is the completed MVP:
Before requesting funding, I have already demonstrated the core architecture against the published Smartnode v1.23.0 artifact, including:
release-artifact verification;
unattended Smartnode configuration;
Hoodi-based stack startup;
Geth + Lighthouse and Besu + Teku test profiles;
JWT failure injection;
readiness-aware health checks;
structured result classification;
sanitized diagnostics; and
machine-readable reporting.
I also performed direct inspection of Smartnode v1.23.0 source and release behavior and ran 11 experiments against the published artifact and generated Docker stack.
The grant therefore funds extension, hardening, and release-workflow integration of demonstrated work, rather than an untested architecture.
What is the breakdown of the proposed work, in terms of milestones and/or deadlines?
Total duration: 4 weeks
Milestone 1 — Client-Matrix Expansion
Weeks 1–2
I will:
harden the existing Geth + Lighthouse and Besu + Teku profiles;
add Nethermind + Teku;
add External Geth + Lighthouse;
verify the exact requested Smartnode artifact and version;
resolve and check the container image identities actually used;
enforce bounded startup deadlines and process cleanup; and
publish profile-level tests and normal-run reports.
Milestone 2 — JWT and Lifecycle Regression Suite
Week 3
I will add defined tests for:
absent JWT;
zero-byte JWT;
malformed hexadecimal JWT;
too-short JWT;
too-long JWT;
bare 64-character hexadecimal JWT;
0x-prefixed 64-character hexadecimal JWT;
read-only JWT; and
JWT persistence across restart.
I will also add:
stop/start recovery checks;
configuration-persistence checks;
restart stabilization logic;
EL/CL readiness checks;
Engine API authentication checks;
product/infrastructure/harness/timeout failure classification; and
secret-redaction tests.
Milestone 3 — Release Workflow and Handoff
Week 4
I will:
finalize the reusable CI workflow;
support manual execution against a selected release tag;
support execution after required release assets are available;
test the workflow from a public fork or documented runner;
submit an upstream Smartnode pull request or PR-ready patch;
publish the final four-profile v1.23.0 results;
publish a tagged GPL-3.0 release; and
complete local-run, contributor, profile-extension, and limitations documentation.
Rocket Pool maintainers control whether and when an upstream workflow is merged. Upstream merge is not an acceptance condition.
How is the work being tested? Is testing included in the schedule?
Yes. Testing is part of every milestone.
The final project will include:
unit tests for artifact verification, profile configuration, JWT validation, report generation, redaction, timeout handling, and result classification;
black-box runs against the published Smartnode release artifact;
The harness will not treat every container restart as a failure.
Feasibility testing showed that some Smartnode services may legitimately restart during initialization. A persistent crash loop will instead be determined by whether restart counts continue increasing and whether the relevant service fails to become ready before the configured deadline.
A known issue may be attached as metadata to a product failure; it will not be converted into a PASS.
Full Docker/client runs may use a documented self-hosted CI runner if standard hosted runners do not provide sufficient storage or execution time. The source code, workflow definition, commands, and result artifacts will remain public.
How will the work be maintained after delivery?
I will provide a 30-day in-scope defect-fix period after final acceptance.
This covers defects that prevent the delivered profiles, assertions, reporting, or workflow from meeting the agreed acceptance criteria.
Where practical, the harness will read client selections from the target Smartnode release rather than maintaining a separate long-lived client-version database.
Indefinite release operations, additional operating systems, new client profiles, future protocol workflows, or substantial changes required by later Smartnode architecture are outside this grant and would require separate scoping.
Costs
What is the acceptance criteria?
The grant will be complete when a reviewer can verify the following:
A tagged GPL-3.0 release of the harness is publicly available.
The harness can select and verify an exact Smartnode Linux-amd64 release artifact, including its SHA-256 identity, detached signature where provided, independently pinned signing-key fingerprint, and reported Smartnode version.
The following four profiles are implemented:
Geth + Lighthouse;
Besu + Teku;
Nethermind + Teku; and
External Geth + Lighthouse.
Each profile can be run through a documented command and produces a deterministic PASS or classified FAIL result instead of hanging indefinitely.
The JWT suite covers:
absent secret;
zero-byte secret;
malformed hexadecimal secret;
too-short secret;
too-long secret;
bare 64-character hexadecimal secret;
0x-prefixed 64-character hexadecimal secret;
read-only secret; and
restart persistence.
The Geth zero-byte fixture deterministically detects the invalid-secret condition.
The Besu zero-byte fixture demonstrates the repaired behavior expected from the current Smartnode path.
Valid bare and 0x-prefixed 32-byte hexadecimal JWT formats are accepted without exposing the secret value.
The harness checks execution/consensus readiness, Hoodi chain identity, and EL/CL authentication for applicable profiles.
Stop/start recovery, configuration persistence, bounded timeouts, output caps, cleanup, and restart stabilization are covered by tests.
Each completed run produces:
report.md
report.json
results.xml
diagnostics/
Reports include the selected Smartnode release, artifact identity, client profile, relevant image identities, outcome, failure classification, and reproduction command.
Published diagnostics are tested to avoid exposing JWT values, private keys, mnemonics, wallet passwords, or equivalent secrets.
A reusable CI workflow is public and demonstrated.
An upstream Smartnode pull request or PR-ready patch for the release-regression workflow is submitted.
Final documentation covers local execution, adding a future profile, reproducing failures, and the explicit limits of what Phase 1 proves.
If a normal profile is prevented from becoming healthy by a reproducible Smartnode defect discovered during funded work, I will not be required to patch Smartnode outside the scope of this grant.
Instead, I will:
reproduce the problem consistently;
classify it as a product failure;
preserve the relevant sanitized evidence;
provide a reproduction command; and
report the issue upstream.
Infrastructure or harness failures will not be presented as Smartnode product failures.
What is the proposed payment schedule for the grant? How much USD $ and over what period of time is the applicant requesting?
Total request: $4,800 USD over 4 weeks.
I am not requesting an upfront payment.
Milestone
Timing
Payment
M1 — Client-Matrix Expansion
End of Week 2
$2,000
M2 — JWT and Lifecycle Regression Suite
End of Week 3
$1,800
M3 — Release Workflow and Handoff
End of Week 4
$1,000
Total
4 weeks
$4,800
The completed MVP and pre-submission feasibility investigation are not included as paid work.
I will request each payment only after the corresponding public deliverables and verification evidence are available.
Who will directly receive the payment? (Required — the GMC can only send grants directly to a recipient address and cannot accept invoices.)
The normal run command returns non-zero for unexpected failures.
A fixture command succeeds only when the expected fixture behavior is observed. If the harness fails to detect the expected condition, the fixture command itself fails.
The GMC will not require access to a private repository, production Rocket Pool node, operator wallet, mnemonic, validator key, or private cloud account to verify delivery.
What alternatives or options have been considered in order to save costs for the proposed project?
Several larger or less useful approaches were considered and rejected:
1. Full 5 × 5 client matrix
Rocket Pool supports multiple execution and consensus clients, but a full Cartesian matrix would significantly increase runtime and maintenance cost.
Phase 1 instead funds four representative paths covering two existing MVP profiles, an additional managed execution-client path, and external execution-client mode.
2. Kurtosis/private-chain deployment
The original design considered a custom local Ethereum network.
Feasibility testing showed that Phase 1 does not require a controlled chain and that the relevant v1.23.0 Lighthouse path does not support the required custom-genesis configuration through the published Smartnode stack.
Hoodi provides the startup, chain-identity, authentication, and lifecycle surface needed for this phase at lower complexity.
3. A single hard-coded check for the historical Besu bug
A small check could detect one already-known dependency problem.
That would not test the broader failure class.
The proposed JWT suite instead verifies absent, empty, malformed, incorrectly sized, permission-constrained, and restart-related behavior across materially different execution-client paths.
4. Hosted monitoring or a dashboard
No hosted service or ongoing monitoring infrastructure is required.
The deliverable is a standalone CLI/CI tool with reproducible reports.
5. Rebuilding Smartnode or Ethereum client orchestration
The project reuses Smartnode’s own published release artifacts, generated configuration, Docker stack, Hoodi, and existing client images rather than maintaining parallel infrastructure.
Have you already been compensated by the RP protocol in any way for this work?
No.
I completed the MVP and technical feasibility work before this application without Rocket Pool compensation.This request covers only the remaining Phase 1 work described above.
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.
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?
Dapps over Apps proposes to build an open-source source-analysis tool for Rocket Pool’s shared RocketStorage keyspace.
Rocket Pool stores persistent protocol state through typed mappings in RocketStorage, while the keys used to access that state are constructed across multiple contracts using hashes, namespaces, literals, runtime values, raw keys, and offset-based patterns.
This creates a review challenge. Solidity can type-check an individual storage call, but it does not provide a system-wide view showing:
how a shared storage key is constructed;
which RocketStorage value type it uses;
where it is read or written;
whether its namespace or ordered key components changed between revisions;
whether a new reader or writer appeared; or
whether a previously understood key expression became unresolved.
This gap has historical relevance in Rocket Pool. Sigma Prime previously identified the distributed storage-key namespace as an open issue and recommended a centralized registry of namespaces and responsible readers/writers. ConsenSys Diligence later documented settings-key collision and delimiter-related issues in Rocket Pool contract reviews.
The proposed tool turns that implicit keyspace into a deterministic, reviewable source artifact.
The CLI will consume Solidity compiler build information generated by Rocket Pool’s existing Hardhat build and produce the following:
1. Repository-wide RocketStorage access inventory
The tool will identify relevant RocketStorage access candidates across the configured contract source and give each candidate an explicit disposition rather than silently ignoring unsupported cases.
2. Scoped generated key registry
For the initial grant, deeper symbolic normalization will be deliberately bounded to six representative source files:
RocketBase.sol
RocketDAOProtocolSettings.sol
RocketDAOProtocolSettingsNetwork.sol
RocketDAOProtocolSettingsRewards.sol
RocketMegapoolManager.sol
RocketDepositPool.sol
For supported key families, the registry will record:
normalized key-construction recipe;
RocketStorage value type;
observed read/write operation;
contract and function;
source location;
ordered key components; and
analysis status.
3. Structural source diff
The tool will compare two generated registries and identify review-relevant structural changes such as:
Unsupported or only partially understood expressions will be emitted as PARTIAL or OPAQUE, together with their source location and reason.
They will not silently disappear from the reported coverage.
5. Historical overlap regression
The project will include a bounded regression fixture for the class of settings-key overlap previously documented in Rocket Pool’s Atlas review.
For the supported fixture, the tool will demonstrate when two distinct symbolic recipes can produce identical key-preimage bytes and therefore identical hashes under the documented input assumptions, together with a non-overlapping control case.
This check will be presented as a structural overlap result only. It will not be described as proof of exploitability or as proof that the historical issue remains present in the current deployment.
6. Deterministic review artifacts
Canonical JSON will be the machine-readable output, with Markdown generated from that JSON for reviewers.
Repeated analysis of identical inputs must produce identical semantic output.
Explicit non-goals
This grant does not propose:
a universal Solidity symbolic executor;
formal verification;
a runtime/mainnet security monitor;
Smartnode cross-language analysis;
a hosted dashboard or service;
automatic contract repair;
deployed-mainnet verification; or
proof that Rocket Pool’s business rules or governance intent are semantically correct.
The purpose of the project is narrower: make supported RocketStorage structure visible and make structural drift reviewable.
MVP / Current Development Status
An MVP for the RocketStorage Key Registry and Structural Diff is already under active development.
Implementation began before submission to reduce execution risk around the proposed architecture and validate the initial build-info and RocketStorage analysis workflow.
MVP / project repository:
The MVP is being developed to demonstrate the core workflow of:
consuming Rocket Pool Solidity/Hardhat build information;
identifying relevant RocketStorage access sites;
extracting supported symbolic key recipes;
generating an initial machine-readable registry;
comparing structural changes between source revisions; and
surfacing unsupported expressions explicitly instead of silently skipping them.
The same repository will be used for the funded implementation, fixtures, sample outputs, regression tests, milestone evidence, documentation, and release artifacts.
Is there any related work this builds off of?
Yes.
The project builds on Rocket Pool’s existing Solidity and Hardhat build system rather than implementing another Solidity parser.
Hardhat and solc provide compiler AST and build metadata. The funded work is the Rocket Pool-specific analysis layer that resolves shared-storage access, normalizes supported key recipes, generates the registry, and compares those structures across revisions.
The proposal is also informed by prior Rocket Pool security work.
Sigma Prime previously recommended a centralized registry for the distributed RocketStorage namespace and responsible reader/writer contracts. Later ConsenSys Diligence reviews documented concrete namespace-related issues, including settings-key collision and delimiter problems.
The proposed deliverable is not intended to replace an audit. It provides a repeatable structural review artifact around the same architectural surface.
Relationship to existing Rocket Pool tooling
The project is distinct from:
general-purpose Solidity analysis such as Slither, which does not provide the proposed RocketStorage-specific generated registry and structural comparison;
source/deployment verification tools, which answer different questions about deployed artifacts;
fuzzing focused on unrelated protocol behavior; and
runtime upgrade replay.
Will the results of this project be entirely open source?
Yes.
The implementation, rule definitions, fixtures, tests, generated registries, comparison examples, CI workflow, documentation, and release artifacts produced under the grant will be public under the Apache-2.0 license.
No private repository, proprietary dataset, API key, paid service, wallet, hosted database, or closed infrastructure is required for acceptance.
Benefit
Group
Benefit
Potential rETH holders
No direct onboarding benefit. Indirect benefit comes from improved reviewability of persistent protocol-state changes.
rETH holders
Indirect benefit from an additional review tool around protocol settings, registries, validator-related state, and accounting structures stored through RocketStorage.
Potential NOs
No direct node-operator onboarding benefit.
Node Operators
Indirect benefit from stronger review of contract-state structures relied upon by the protocol. The project does not modify Smartnode or operator workflows.
Community
Primary direct benefit. Contract contributors, reviewers, auditors, security researchers, and delegates receive a generated view of supported RocketStorage structures instead of reconstructing them manually across multiple contracts.
RPL holders
Governance participants gain additional evidence when reviewing protocol changes that alter shared persistent state.
Which other non-RPL protocols, DAOs, projects, or individuals would stand to benefit?
The funded implementation is specifically designed for Rocket Pool’s RocketStorage architecture.
The general approach may be useful to security researchers and other upgradeable EVM protocols using shared or eternal-storage patterns, but no outside protocol or commercial product is required for the grant to provide value.
Rocket Pool remains the direct funded beneficiary.
Work
Who is doing the work?
The work will be delivered by Dapps over Apps.
Abdulkareem Oyeneye — Lead Developer
Abdulkareem will lead:
compiler build-info ingestion;
RocketStorage access resolution;
supported symbolic key normalization;
registry generation;
structural-diff implementation;
coverage accounting;
overlap regression;
fixture and test development;
deterministic artifact generation;
CI; and
final release and reproducibility.
Dapps over Apps will also handle public documentation, milestone reporting, and acceptance evidence.
What is the background of the person doing the work?
Dapps over Apps focuses on developer tooling, protocol-specific test infrastructure, compatibility tooling, and reproducible development workflows.
Relevant prior public work includes:
Arbitrum Local Development Compatibility Project
Repository:Supercoolkayy/Ox-rollup
This project provides Arbitrum-specific local development and testing support for Hardhat and Foundry/Anvil.
Its public work includes:
a Hardhat compatibility plugin;
Arbitrum precompile support/emulation;
protocol-specific local test probes;
compatibility analysis;
TypeScript implementation;
Rust-side tooling/specification work; and
reproducible development/test workflows.
This experience is relevant because the RocketStorage project similarly requires translating protocol-specific architecture into bounded, reproducible developer tooling rather than building a hosted application.
Current RocketStorage MVP
Implementation of the RocketStorage Key Registry and Structural Diff MVP has also begun before submission.
The purpose of this early work is to validate the compiler/build-info ingestion and initial registry architecture before the funded milestones are completed.
Repository:
What is the breakdown of the proposed work?
We request a maximum of $6,800 over approximately six weeks, with payment in arrears after milestone acceptance.
Milestone 1 — Source Inventory and Feasibility Baseline
End of Week 2 — $1,500
Deliverables:
pin the Rocket Pool source revision and compiler/build inputs;
establish the RocketStorage access candidate census;
implement initial compiler-resolved extraction across the six scoped files;
produce the first normalized registry;
publish per-file and aggregate normalization coverage;
publish unresolved/unsupported sites with explicit reasons;
define the mandatory key groups used for acceptance; and
select and document six public Rocket Pool source comparisons for later regression testing.
Continuation criteria
Milestones 2 and 3 proceed only if M1 demonstrates:
at least 90% fully normalized eligible callsites across the six-file analysis boundary;
at least 80% fully normalized eligible callsites in each non-empty scoped file;
100% resolution of the specifically named mandatory key groups; and
zero unmatched source-access candidates without a documented disposition.
PARTIAL and OPAQUE results remain in the denominator.
If the criteria cannot be met without broad manual registry entries or materially expanding the analyzer beyond the proposed scope, the project will stop after M1 rather than silently expanding the grant.
Milestone 2 — Registry, Structural Diff, and Regression Tests
End of Week 5 — $3,500
Deliverables:
complete the scoped generated key registry;
implement base/head structural comparison;
identify supported recipe, type, component, reader, and writer changes;
implement explicit acknowledgments for reviewed intentional differences;
implement the bounded historical overlap fixture;
complete the required positive and negative synthetic regression suite;
run the six documented real-source comparisons; and
publish deterministic JSON and Markdown evidence.
Milestone 3 — Reproducible Release
End of Week 6 — $1,800
Deliverables:
clean-clone acceptance workflow;
final CI;
deterministic-output verification;
final coverage and uncertainty report;
architecture documentation;
rule-semantics documentation;
threat model and non-goals;
usage and comparison examples;
tagged Apache-2.0 release; and
start of the included 60-day defect-fix period.
How is the work being tested?
Testing is included throughout the implementation.
The final acceptance corpus will contain 18 structural scenarios.
11 scenarios must produce either a review finding or explicit analysis refusal
Examples include:
storage-value type change;
namespace/literal change;
key-component addition or removal;
key-component reordering;
hash/raw/offset recipe change;
added observed writer;
removed required observed reader;
introduction of an unsupported expression;
resolved-to-opaque regression; and
a supported overlapping-prefix construction.
7 scenarios must remain non-blocking
Examples include:
comment-only changes;
unrelated source declaration reordering;
harmless local-variable renaming;
equivalent supported aliasing; and
documented intentional legacy storage patterns.
The purpose is not simply to make the tool report every source change. It must distinguish supported structural changes from irrelevant refactoring.
The implementation will also be tested against six real public Rocket Pool source comparisons, with expected outcomes documented from the underlying source differences.
Additional quality checks include:
deterministic repeated runs;
reconciliation between source candidate census and compiler-resolved inventory;
explicit reasons for every PARTIAL and OPAQUE result;
positive and negative overlap fixtures; and
clean-clone reproducibility.
How will the work be maintained after delivery?
The final release, pinned baseline, fixtures, tests, and generated schemas will remain reproducible without a hosted service.
Dapps over Apps will provide 60 days of defect fixes after final acceptance.
The maintenance commitment covers defects in the accepted implementation and documentation.
Material support for substantially new Rocket Pool compiler/key-construction patterns, Smartnode cross-language analysis, UI development, or new protocol-specific rule families is outside this grant and would require separate scope.
Costs
What is the acceptance criteria?
The GMC should be able to independently verify the following:
The tool verifies the expected source/compiler inputs and rejects mismatched build inputs instead of silently analyzing the wrong build.
A repository-wide RocketStorage access inventory is produced with each identified candidate given an explicit disposition.
The six-file deep-analysis boundary meets the stated coverage requirements.
Every supported registry entry includes:
normalized key recipe;
RocketStorage storage type;
operation;
contract/function;
source location; and
analysis status.
PARTIAL and OPAQUE results remain visible with explicit reasons.
Structural diff identifies the agreed supported classes of recipe, type, component-order, reader, and writer changes.
The historical overlap fixture demonstrates a concrete equal-preimage/equal-hash case under its documented assumptions, while the negative control does not.
All 18 positive/negative regression scenarios produce their documented expected results.
The six real-source comparisons produce results consistent with their documented source changes.
Identical inputs produce deterministic canonical JSON and semantically equivalent Markdown.
A clean clone can run the documented acceptance workflow without:
Ethereum RPC access;
wallet credentials;
API keys;
private repositories; or
hosted services.
Documentation clearly states the project’s limitations and does not describe a clean result as:
a security audit;
proof of collision freedom;
proof of exploitability; or
proof that Rocket Pool’s business rules or governance intent are correct.
What is the proposed payment schedule?
We request a maximum of $6,800 over approximately six weeks.
All payments are requested after the applicable milestone has been accepted.
Milestone
Timing
Payment
M1 — Source Inventory and Feasibility Baseline
End of Week 2
$1,500
M2 — Registry, Structural Diff, and Regression Tests
End of Week 5
$3,500
M3 — Reproducible Release
End of Week 6
$1,800
Total
6 weeks
$6,800
M2 and M3 do not proceed unless the M1 continuation criteria are met.
How will the GMC verify that the work delivered matches the proposed cadence?
All work and milestone evidence will remain public in the project repository.
For each milestone, Dapps over Apps will provide:
the relevant commit or release tag;
exact reproduction commands;
test results;
generated JSON/Markdown artifacts;
coverage results;
unresolved-case ledger;
documented limitations; and
the specific acceptance items being presented for payment.
The GMC can verify the deliverables from a clean clone without relying on a private demo or testimonial.
What alternatives have been considered to save costs?
Regex-only or Semgrep-style linting
Rejected because it would not provide reliable declaration-resolved source accounting or the proposed typed key registry.
Universal Solidity dataflow/symbolic analysis
Rejected because it would materially exceed the scope and budget required for this Rocket Pool-specific problem.
Full repository semantic normalization in the initial grant
Rejected to keep technical risk bounded.
The grant instead provides repository-wide inventory while guaranteeing deeper modeling only for the six-file initial boundary.
Runtime/mainnet verification
Excluded because it would add chain-state and infrastructure requirements that are not needed for this source-analysis deliverable.
Smartnode cross-language analysis
Deferred because it materially expands the project beyond Solidity shared-storage structure.
Dashboard or hosted monitoring service
Excluded because it would introduce hosting, operations, and long-term service dependencies without being necessary for the core deliverable.
Automatic remediation
Excluded because the tool is intended to report structural facts and differences, not rewrite Rocket Pool contracts.
UI/SARIF integrations
Deferred from the initial grant. Canonical JSON and generated Markdown are sufficient for the first version and keep the requested budget focused on the core analysis.
Have you already been compensated by the Rocket Pool protocol in any way for this work?
No.
The proposal does not request retroactive compensation for pre-submission research, repository setup, or MVP work already started.
Grant compensation applies only to the future milestone work described in this application.
Conflict of Interest
None.
Does the person or persons proposing the grant have any conflicts of interest to disclose?
Notice: This message marks the closing of the fortieth (40) round of Rocket Pool grant applications. Any applications submitted after this will not be considered for this round.