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

Grants / Bounties
,
8

Name of Grant:

Rocket Pool Upgrade Effects Gate

What is the work being proposed?

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:

  • chain ID: 1

  • pre-upgrade block: 24,479,993

  • execution block: 24,479,994

  • upgrade transaction: 0x2fc10aad3c1b00bdfa9b6fddab79e0f2688609848f8f7a1a6449ab42da38530c

  • upgrade contract: 0x5b3B5C76391662e56d0ff72F31B89C409316c8Ba

  • RocketStorage: 0x1d8f8f00cfa6758d7bE78336684788Fb0ee0Fa46

  • Rocket Pool source commit: fb7d9c428dc3dddc3fbd3e634e3cb365655df89e

Feasibility MVP:

Demo Video : https://drive.google.com/file/d/1dIQ4gjeyw9JZSGn6ubkLm-dBXlEelTfU/view?usp=drivesdk

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:

  1. A documented command replays the pinned Saturn 1 upgrade payload against the pinned pre-upgrade state and produces the expected attestation.

  2. RocketStorage’s public typed mutator calls are captured with correct per-call caller, operation, key, semantic path, old value, new value, and ordering.

  3. Unknown selectors, undecodable keys, incomplete traces, or unsupported effect shapes cannot silently disappear or result in PASS.

  4. Every required manifest effect matches the expected type, value, deletion semantics, and multiplicity, and undeclared effects cannot pass.

  5. Direct outbound calls from the upgrade contract are checked against the declared target, selector, ETH value, and multiplicity.

  6. Incorrect chain, block hash, transaction/payload, upgrade contract, RocketStorage address, or source anchor prevents PASS.

  7. The proof bundle binds the normalized evidence to the pinned execution inputs, source commit, manifest, review record, and tool version.

  8. Repeated runs produce the same canonical evidence hashes; wall-clock metadata is excluded from the deterministic hash boundary.

  9. The Saturn 1 golden fixture passes and the adversarial fixtures produce the expected non-zero FAIL or UNKNOWN outcomes.

  10. Offline tests pass in CI and a clean Linux/container environment can reproduce the documented acceptance workflow.

  11. Documentation clearly states that PASS means effects conformance within the stated boundary, not an audit or universal security guarantee.

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

$7,480 USD total over five weeks, paid only after milestone acceptance.

Milestone Timing Payment
Replay and Capture Hardening End of Week 2 $2,550
Conformance Gate and Golden Proof End of Week 4 $3,400
Reproducible Release End of Week 5 $1,530
Total 5 weeks $7,480

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

Creatives Onchain

EVM address: [0x1C9b94ef19bce5CAB6CC7Fd458C30d09D431022B]

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

All work will remain public.

At each milestone, we will provide:

  • the relevant commit or release tag;

  • exact reproduction commands;

  • CI/test results; and

  • the generated acceptance artifacts.

Final acceptance will not depend on an upstream merge, private demo, or testimonial.

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

The scope intentionally reuses existing Ethereum tooling and excludes:

  • a custom EVM;

  • a dashboard or hosted service;

  • Smartnode integration;

  • continuous monitoring;

  • universal arbitrary-contract storage interpretation;

  • automatic natural-language RPIP parsing; and

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

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