Name of Grant
RocketStorage Key Registry and Structural Diff
What is the work being proposed?
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.solRocketDAOProtocolSettings.solRocketDAOProtocolSettingsNetwork.solRocketDAOProtocolSettingsRewards.solRocketMegapoolManager.solRocketDepositPool.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:
- namespace or literal changes;
- key-component addition, removal, or reordering;
- hash/raw/offset recipe changes;
- typed-storage changes;
- newly observed or removed readers/writers; and
- previously resolved expressions becoming unresolved.
4. Explicit uncertainty
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
PARTIALandOPAQUEresult; - 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.
PARTIALandOPAQUEresults 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.
Who will directly receive the payment?
Recipient: Abdulkareem Oyeneye / Dapps over Apps
EVM Address:
[0x98A4Fb2E4ecc1497874ca648Ac46E583227C1dDf]
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?
No