Round 40 - GMC Call for Grant Applications - Deadline is September 7

Grants / Bounties
,
7

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 $1,500
M2 — Controlled measurements and reporting Weeks 3–4 Explicitly opt-in bounded disk/network measurements; JSON and human-readable reporting; timeout/failure handling; cleanup tests; shareable-report schema tests $2,000
M3 — Validation, documentation and release Weeks 5–6 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:

  1. one physical amd64 host suitable for active storage measurements and

  2. 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:

  1. Public release

    A publicly accessible, appropriately licensed release builds and runs using documented steps on the agreed Linux baseline.

  2. Passive assessment

    The agreed passive system-inspection functionality operates without modifying Smartnode services or host configuration.

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

  4. Evidence-oriented output

    Both readable and JSON output provide measured evidence, applicable versioned guidance and clear UNVERIFIED states where sufficient evidence is unavailable.

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

  6. Automated testing

    Automated tests cover the agreed probes, report generation, failure paths, timeouts, temporary-file cleanup and relevant safety properties.

  7. Documented evaluation

    The tool is evaluated on the three agreed documented configurations, with test commands, environment descriptions, results and known limitations published.

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

Round 40 (August 7 - September 7) Grants / Bounties Retrospective Awards Results