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

Grants / Bounties
,
5

Smart Node Upgrade Preflight — rocketpool update --check

What is the work being proposed?

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.

  • Milestone 1: $3,000

  • Milestone 2: $2,000

No upfront payment requested.

Payment recipient

Akira Nakao

EVM address: 0x185BA5372009dB50Ff062C6dbdc56B03c7ab5e41

Verification

All work will be public.

Each milestone will include the relevant commits, tests, build instructions, and a short demo so the GMC can verify the implementation directly.

Cost-saving choices

I intentionally kept the scope small.

I am not proposing:

  • a new dashboard

  • validator monitoring

  • EL / CL monitoring

  • a hosted service

  • AI features

  • automatic rollback

  • a separate compatibility database

The grant is focused on one feature only: checking upgrade readiness before the upgrade changes anything.

Previous Rocket Pool compensation

None.

Conflict of Interest

I have no conflicts of interest to disclose.

I am not a GMC member, and I do not have another protocol or commercial product that would financially benefit from this work.

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