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?
No.