Round 41 - GMC Call for Grant Applications - Deadline is October 7

[ShfRyn]

This thread is for applications for Rocket Pool’s September 7, 2026 - October 7, 2026 grants. Please only post grant applications in this thread. If you would like to discuss and/or ask questions about any applications you see in this thread, we ask that you do so in this forum thread, which has been established for all community discussions related to this round of applications. Only those grant applications that are posted in this thread and timestamped by October 7, 2026 at 23:59 (11:59 PM) UTC will be considered. Any grants posted after that deadline will be carried over to the next award period.

This is the expected schedule for round 41:

• Application Period (September 7 - October 7)
• Scoring Deadline (October 20)
• Final Voting Amendments, Discussion and Finalization (October 21 - October 24)
• Award Announcement (October 25)

Differences Between Grants and Bounties

Grants are intended to be applied for by those who are wishing to carry out the work themselves. Bounties are open-ended goals that could be met by anyone, including those other than the proposing party. In other words, if I believed that Rocket Pool needed a fifty-foot paper mache orange rocket for publicity purposes and I wanted to be the one to build it, I would apply for a grant. If I instead thought Rocket Pool needed a fifty-foot paper mache orange rocket for publicity purposes but I wanted it to be open to whoever built it first to claim the reward (similar to a prize), then I’d apply for a bounty.

To guide you in your application, the GMC has established the following goals and the following scoring rubric:

GMC Goals

Grants, bounties, and retrospective awards should make it easier and/or more attractive to do one or more of the following:

• become a node operator

• operate a node, mint rETH

• hold or use rETH

• improve the quality of life for the protocol and its community.

Grants Rubric

When evaluating grant applications, the GMC takes into account the following goals:

• If the application is successful, to what extent does it further the GMC goals?

• To what extent can the application be feasibly carried out by the person(s) proposed to complete it?

• If the application is successful, how large is the benefit to the protocol relative to the size of the proposed costs?

Grant Application Template

Please copy paste the template below into a reply. Answer the questions there, feel free to remove or add sections based on relevance.

## Name of Grant

### What is the work being proposed?

### Is there any related work this builds off of?

### Will the results of this project be entirely open source ([MIT](https://opensource.org/licenses/MIT), [GPL](https://www.gnu.org/licenses/gpl-3.0.en.html), [Apache](https://www.apache.org/licenses/LICENSE-2.0), [CC BY](https://creativecommons.org/licenses/by/4.0/) license or similar)? If not, which parts will not be, why, and under what license will they be published?



## Benefit

<please enter N/A where appropriate>

| Group | Benefits |
|---|---|
| Potential rETH holders | If the grant is successfully completed, how does this help people looking to stake ETH for rETH? |
| rETH holders | If the grant is successfully completed, how does this help rETH holders? |
| Potential NOs |  If the grant is successfully completed, how does this help people looking to run a Rocket Pool node for the first time? |
| NOs | If the grant is successfully completed, how does this help people already running a Rocket Pool node? |
| Community |  If the grant is successfully completed, how does this help the Rocket Pool community? |
| RPL holders |  If the grant is successfully completed, how does this help RPL holders? |

### Which other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?



## Work

### Who is doing the work?

### What is the background of the person(s) doing the work? What experience do they have with such projects in the past?

### What is the breakdown of the proposed work, in terms of milestones and/or deadlines?

### How is the work being tested? Is testing included in the schedule?

### How will the work be maintained after delivery?



## Costs

### What is the acceptance criteria?

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

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

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

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

### Have you already been compensated by the RP protocol in any way for this work?



## 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).

### 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?

[machinamachinery]

## Name of Grant

GMC Receipt Reconciler — tested batch accounting and maintainer handoff

### What is the work being proposed?

A small offline tool for checking GMC treasury transfers against an explicit
allocation list. A working prototype is already public:
https://github.com/machine-of-earn/gmc-receipt-reconciler

It produces JSON and Markdown with matched, missing, short, excess, and unallocated
recipient totals, backed by transaction and log references. It separates declared
grant/bounty/operations/swap labels from observed outgoing transfers.

The first example covers the actual September 14 GMC batch at Ethereum block
25,978,769: 21 transfers to 16 recipients, totalling 8,656.4631073446384 RPL and
2,100 USDC. Every recipient remains unclassified unless an allocation manifest is
supplied. This example demonstrates transfer accounting, not a claim that the
whole batch represents grants or that the tool has existing GMC users.

The proposed remaining work is one maintainer handoff: reproduce the example,
reconcile one GMC-supplied approved allocation list, document any discrepancies,
and handle corrections to this scope for 30 days after acceptance.

### Is there any related work this builds off of?

The GMC's public treasury reporting and Ethereum Blockscout's transaction transfer
API. This tool complements those records with reproducible arithmetic and explicit
allocation matching. It does not replace treasury reporting, the Safe interface,
or the GMC's award decisions.

### Will the results be entirely open source?

Yes. MIT-licensed Python source, tests, example evidence and generated reports are
in the repository. Only Python's standard library is required.

## Benefit

| Group | Benefits |
|---|---|
| Potential rETH holders | N/A — no staking or onboarding claim. |
| rETH holders | Indirect: reproducible visibility into community treasury payments. |
| Potential NOs | N/A — no node setup feature. |
| NOs | Indirect: the community can inspect allocation arithmetic without running a node. |
| Community | Check monthly payment lists against transfer evidence; preserve log references and distinguish unallocated transfers. |
| RPL holders | Review the exact RPL outflow and its declared purpose without conflating swaps with awards. |

### Which other projects would benefit?

Other Ethereum treasury operators could reuse the accounting logic, but this
request is scoped to the GMC Safe and its RPL/USDC payment batches.

## Work

### Who is doing the work?

The `machine-of-earn` open-source project, maintained through the repository.

### What experience does the contributor have?

Public work includes tested crypto tooling and the released RigoBlock findings
repository at https://github.com/machine-of-earn/rigoblock-v4-findings . The
reconciler's source, tests and real-batch example can be assessed directly. No
Rocket Pool team affiliation or prior GMC award is claimed.

### Milestones and deadlines

1. Already delivered: offline CLI, exact integer accounting, RPL/USDC allowlist,
   input integrity checks, JSON/Markdown reports, 23 tests, and September example.
2. Within 14 days of approval and receipt of one approved allocation list: publish
   its reproducible reconciliation and address defects affecting this scope.
3. For 30 days following acceptance: respond to reproducible defects and keep the
   example and documentation usable. No ongoing service or paid infrastructure.

### Testing

`python3 -m unittest discover -s tests -v` runs the suite. Coverage includes the
real batch, one-smallest-unit short/excess amounts, duplicate and conflicting
logs, wrong token contracts, incoming/self transfers, incomplete pagination,
wrong chain/Safe, absent payments, mixed classifications, and report provenance.

### Maintenance after delivery

Issues and fixes are handled in the public repository within the stated support
window. Future features or ongoing operational support would require a separate
scope; no recurring payment is requested.

## Costs

### Acceptance criteria

- The supplied September example and test suite run using Python 3.10+ without installing dependencies.
- One GMC-supplied allocation manifest is reconciled with a complete transfer snapshot.
- Every discrepancy remains visible; no transfer is automatically described as an approved grant.
- Source, instructions and evidence references remain public under MIT.

### Requested payment

**$250 total, requested only after the handoff is accepted.** This is the
applicant's proposal, not a published bounty amount or a claim to an existing award.
No upfront payment or expense reimbursement is requested.

### Who directly receives payment?

Ethereum receiving address: `0x07Ef03C65f19e61E0dc7746A13063d09028A1Fbf`.
RPL or USDC under the GMC's normal payment process. No invoice.

### How can delivery be verified?

Run the documented commands against the pinned release and compare the output
with the supplied allocation list and transaction logs. Reproduction is offline;
the reviewer controls the evidence and can independently check the explorer/RPC.

### Cost-saving alternatives

Manual explorer and spreadsheet reconciliation remains viable. This tool is a
small reusable check for repeated payments and evidence handling. It avoids a
hosted service, database, API subscription, and recurring infrastructure costs.

### Already compensated by Rocket Pool for this work?

No.

## Conflict of Interest

No GMC member participated in development of this tool, and no Rocket Pool
affiliation is claimed. The applicant would benefit from the requested $250 if
approved. The tool is open source and carries no fee or token. This application
does not make representations about the token holdings of individual users or
reviewers.

[ilelabs]

Name of Grant

Megapool Cross-Layer Checker

What is the work being proposed?

ILE Labs proposes to complete and publish an open-source, read-only evidence tool for Rocket Pool Megapool operators.

The tool compares execution-layer Megapool contract state with consensus-layer Beacon Chain validator state and produces structured reports showing:

• validator identity;
• Megapool contract state;
• Beacon Chain validator state;
• withdrawal credentials;
• validator lifecycle status;
• supporting evidence and block references;
• whether operator review may be required;
• whether the result is healthy, actionable, or inconclusive.

The current MVP already performs live Hoodi reads, correlates validator pubkeys across both layers, verifies withdrawal credentials, handles incomplete data conservatively, and produces replayable evidence reports.

The grant would fund the completion of the operator-facing CLI, additional lifecycle coverage, batch reconciliation, evidence capture, testing, and documentation.

Is there any related work this builds off of?

Yes. The project builds on Rocket Pool Megapool contract interfaces, Beacon Chain validator APIs, current Megapool deployment data, and the existing open-source MVP.

Repository: [ REPOSITORY URL]

The current MVP includes live Hoodi captures covering:

• an active validator with matching Megapool and Beacon state;
• a completed-withdrawal state correctly classified as inconclusive where the available contract data is insufficient to prove final accounting.

Will the results of this project be entirely open source?

Yes.

The source code will be published under the repository’s existing Apache-2.0 license.

Benefit

Group	Benefits
Potential rETH holders	Better operator diagnostics can support reliable node operation and the infrastructure underlying rETH.
rETH holders	Cross-layer evidence can help operators identify validator or Megapool conditions requiring review before they become operational problems.
Potential NOs	Clearer validator and Megapool state reporting can reduce the difficulty of understanding operational conditions when running a Rocket Pool node.
NOs	Operators receive one structured report combining execution-layer and Beacon Chain evidence instead of manually comparing separate systems.
Community	The project provides transparent, replayable evidence and clearly separates healthy, actionable, and inconclusive results.
RPL holders	Improved node-operator tooling supports the reliability and continued operation of the Rocket Pool protocol.

Which other non-RPL protocols, DAOs, projects, or individuals would benefit?

The primary beneficiary is Rocket Pool.

The underlying evidence format may also be useful to Ethereum Beacon Chain tooling, node-operator dashboards, and other open-source validator monitoring projects. No external integration is being claimed as part of this grant.

Work

Who is doing the work?

Charles Emmanuel — Project Lead and Integration Architecture
Open-source blockchain infrastructure developer focused on protocol tooling, JSON-RPC integration, smart-contract data analysis, and technical documentation. Leads ILE Labs’ cross-ecosystem grant and engineering program.
GitHub: CodexEmmzy

Gideon Bature — Core Implementation
Software engineer and DevOps specialist with proficiency in Rust, Go, Solidity, JavaScript, and Python. Experience in systems engineering, EVM smart-contract tooling, and production infrastructure. Primary engineer on the existing MVP demonstrating live EVM contract calls, current Megapool ABI decoding, Beacon REST integration, and deterministic replay.
GitHub: GideonBature

Onyekachukwu Nweke — Protocol Layer and Verification
Blockchain engineer with deep experience in Rust systems programming, cryptographic protocol implementation, and adversarial verification. Led the lightning-payjoin-kit protocol implementation including rigorous empirical testing and public documentation of a negative verification result — demonstrating the team’s commitment to conservative, evidence-first engineering over optimistic claims.
GitHub: Onyekachukwu-Nweke

What is the background of the person doing the work?

The work is being carried out by an open-source developer focused on blockchain infrastructure, protocol tooling, Rust and JavaScript development, JSON-RPC integration, smart-contract data analysis, Beacon Chain data, test harnesses, and technical documentation.

The existing MVP demonstrates:

• live EVM contract calls;
• current Megapool ABI decoding;
• Beacon REST integration;
• validator pubkey correlation;
• withdrawal-credential verification;
• deterministic replay;
• mock-RPC integration tests;
• structured JSON and terminal output;
• conservative handling of incomplete evidence.

What is the breakdown of the proposed work?

Milestone 1 — Evidence and reconciliation

Weeks 1–3

• Add another live validator lifecycle scenario.
• Improve execution-layer and Beacon Chain evidence capture.
• Add batch validator reconciliation.
• Finalize healthy, actionable, and inconclusive classifications.
• Add tests and replayable evidence.

Milestone 2 — Public release

Weeks 4–6

• Complete the CLI workflow.
• Add clean-install CI verification.
• Publish documentation and the evidence schema.
• Package replayable reports and fixtures.
• Publish the release and maintenance guidance.

How is the work being tested?

Testing is included throughout the schedule.

The project will use:

• automated unit and integration tests;
• mock execution-layer and Beacon endpoints;
• live testnet captures;
• deterministic offline replay;
• malformed and incomplete-data fixtures;
• CI checks;
• manual review of generated evidence reports.

The tool will not classify missing or conflicting information as healthy. Such cases will be reported as inconclusive unless the available evidence supports a stronger conclusion.

How will the work be maintained after delivery?

The repository will remain public and open source.

Maintenance will include:

• keeping the supported ABI and network configuration documented;
• accepting issue reports and pull requests;
• updating fixtures when protocol interfaces change;
• preserving replayable evidence for regressions;
• clearly marking unsupported protocol versions or incomplete data.

Costs

What is the acceptance criteria?

The grant will be complete when:

1. The public repository contains the finished read-only auditor.
2. The tool supports at least two live Megapool/Beacon scenarios.
3. Reports include network, block, validator, contract, Beacon state, evidence source, and limitations.
4. Healthy, actionable, and inconclusive states are clearly separated.
5. Evidence can be replayed offline without network access.
6. Batch reconciliation is implemented.
7. Automated tests and CI pass.
8. Documentation explains installation, usage, evidence format, and limitations.
9. No private-key handling, transaction signing, or transaction broadcasting is introduced.

What is the proposed payment schedule?

ILE Labs requests $6,500 USD, payable in the equivalent RPL amount at the time of payment if preferred by the GMC.

The proposed delivery period is six weeks:

• Milestone 1: $2,500 equivalent
• Milestone 2: $4,000 equivalent

Payments will be requested after acceptance of each milestone, not upfront.

Who will directly receive the payment?

Ethereum address: 0xaE6EAd7e192ea83D8c90DE85a7354063Daf6bAF0
The payment should be sent to the recipient address specified above.

How will the GMC verify delivery?

Each milestone will produce public repository evidence, including:

• code commits;
• test results;
• redacted live reports;
• replay commands;
• updated documentation;
• CI results;
• release notes.

What alternatives or options have been considered to save costs?

The project deliberately avoids:

• a hosted dashboard;
• transaction execution;
• private-key management;
• protocol changes;
• duplicating the entire Smartnode stack;
• operating paid infrastructure.

Have you already been compensated by the Rocket Pool protocol?

No. ILE Labs has not received Rocket Pool compensation for this work.

Conflict of Interest

Does the person or persons proposing the grant have any conflicts of interest?

No conflict of interest exists between ILE Labs and the Rocket Pool Grants and Bounties Management Committee.

Will the recipient or another project benefit financially if the grant succeeds?

The recipient will receive the grant payment for completing the open-source work.
The main benefit is the development of reusable open-source infrastructure for Rocket Pool operators and the wider community.

[filipe.leonor]

Name of Grant

AlphaYields — rETH as the base asset of ayETH: net-new, delta-neutral rETH demand across chains ($30,000)

What is the work being proposed?

We propose to make rETH the base asset of ayETH, AlphaYields’ ETH-denominated yield product, and to ship it live on Ethereum mainnet within three weeks of grant approval. The grant funds the rETH-specific integration, an independent review of the rETH code paths, entry/exit liquidity to support at-size deposits and redemptions, and a public dashboard reporting the rETH accumulated through the product.

About AlphaYields. AlphaYields is the Yield Layer of DeFi — a chain-abstract protocol that packages conservative, real-yield strategies into single-deposit ayTOKENs. We never take custody, and we compute APY from on-chain share-price history only. Each ayTOKEN is a portfolio of DeFi strategies: a user deposits one asset and the protocol runs, rebalances, and hedges the underlying positions.

Why this drives rETH adoption. Most users don’t want to manage LSTs, leverage, or hedges — they want to deposit and hold a token that goes up. When the product holds the LST as its base asset, LST adoption scales with deposits, without asking any user to convert or stake anything. ayETH accumulates rETH under the hood as capital flows in, creating net-new, price-insensitive demand for rETH and sticky liquidity.

The strategy behind ayETH is fully measured on-chain over a full year (366 daily archive reads of the rETH exchange rate, Aave V3 borrow rates read at the same blocks, Rocket Pool deposit-pool liquidity, and 8,760 hourly Hyperliquid funding prints). No centralised-exchange data or account is used anywhere in the construction.

The strategy map

We assessed five constructions on rETH. Two are deployable, one is an overlay, one is set aside, and one is the reference floor:

Strategy	Denomination	Net APY	Capacity	Verdict
Funding carry — hold rETH, short ETH perp	USD	6.3% (365d) · 7.7% (90d)	$390M+	Deploy
GMX ETH-USDC pool + hedge	USD	5.9% (2026) · 17.6% (full window)	$20–50M	Deploy
Secondary-market arbitrage overlay	USD	+0.5–2% on top (est.)	scales with the above	tick-level analysis required
rETH looping on Aave (4×)	ETH	2.5% — leverage adds +0.3pp	$78M	not worth the leverage
Hold rETH (reference)	ETH	2.26%	$1.3B	floor

Figure 1 — Net APY vs. capacity each strategy can absorb (log scale). Green = deployable, grey = ETH-denominated reference. Carry capacity is 15% of ETH perp open interest; GMX from the pool’s $54M TVL at a 20–50M discipline.

Every input, verified on-chain

Claim	How verified	Result
rETH yield 2–2.5%	Exchange rate at 366 daily blocks, 2025-09-19 → 2026-09-18	2.26% full year; 2.21% trailing 90d; rolling-30d range 2.00–2.90%
WETH borrow cost ~2%	currentVariableBorrowRate from the Aave V3 Pool at the same blocks	2.05% today; 2.10% 90d mean; 2.37% full-year mean; one spike to 9.01%
rETH usable as collateral	Aave V3 reserve bitmap + e-mode 1 “ETH correlated” bitmaps	rETH collateral enabled, WETH borrowable, LTV 93% / LT 95% in e-mode
Instant redemption liquidity	rocketDepositPool.getExcessBalance()	0 ETH excess today; deposit pool holds 19.7 ETH
Hedge venue depth	Hyperliquid metaAndAssetCtxs	ETH perp open interest $2.62B
Funding is income, not cost	8,760 hourly prints	+6.17% (365d), +7.86% (90d), +9.70% (30d); 13.9% of days negative
rETH trades at a discount	DEX price vs. on-chain rate, 364 daily points	discount on 69% of days; mean −10bp; −16bp today

(Point-in-time reads as of 2026-09-18.)

Primary strategy — funding carry

Delta-neutral to ETH by design: the long is ETH via rETH, the short is ETH via the perpetual, and both legs are executable from a contract.

hold rETH              2.26% staking yield, accrues in the exchange rate
short ETH perpetual    funding +6.17% over 365 days, paid to the short

hedge ratio = rETH × exchange rate   (1 rETH = 1.172 ETH today; ratio drifts up ~2%/yr)
margin ~25% of notional at 4×        capital = 1.25× the position

There is no gamma; the only rebalancing is the exchange-rate drift plus margin maintenance. The short is re-struck on the exchange rate, not held 1:1, so the hedge stays neutral as rETH accrues.

Component	365-day basis	90-day basis
rETH staking yield	+2.26%	+2.21%
ETH funding received	+6.17%	+7.86%
Gross	8.43%	10.07%
Less round-trip execution	−0.50%	−0.50%
Divided by 1.25× capital	—	—
Net APY	6.3%	7.7%

Figure 2 — Hyperliquid ETH perpetual funding, 8,760 hourly prints over 366 days to 2026-09-18. 365d mean +6.17%; negative on only 13.9% of days, and strengthening through the window (30d +9.70%). The 6.3% headline plans against the full-year mean; 7.7% is the current regime.

At a 15%-of-open-interest discipline the hedge supports $390M. On the spot side rETH is a $1.3B token; entry at size is through minting when the deposit pool is open and through DEX otherwise.

Second leg — GMX ETH-USDC + hedge

The same delta-neutral idea applied to a different income source: supply liquidity to the GMX V2 ETH-USDC pool (trading fees, borrowing fees, and the counterparty side of trader PnL) and short ETH against the pool’s measured exposure. The pool’s realised β to ETH is 0.457, not the 0.5 its composition implies; hedging at the measured figure leaves residual β of −0.004. Net 5.9% in the current regime (17.6% full window), sized at $20–50M, sharing the same ETH short as the carry.

Discount-capture overlay — and why it helps the peg

rETH vs. redemption value (364-day window)
Days at a discount	69%
Mean / median basis	−10.1bp / −8.8bp
Days beyond −25bp	27%
Range	−112bp to +166bp
Today	−16bp

Figure 3 — rETH/ETH secondary price vs. the on-chain exchange rate, 364 days. Grey = daily, green = 7d rolling.

Because ayETH accumulates rETH anyway, it systematically buys rETH below its exchange rate — a positive-expectation entry that also puts net buy-side pressure behind the rETH peg. Layered onto the carry it plausibly adds 0.5–2%; sizing requires tick-level analysis before any figure enters a forecast. It is an entry-timing overlay, not a standalone strategy.

What we assessed and set aside for now — looping

Figure 4 — net(L) = L × staking − (L−1) × borrow. At 4× the loop returns ~2.5% in ETH, +0.3pp over holding rETH, against a 95% liquidation threshold. At full-year rates (2.26% earned vs. 2.37% paid) the spread was negative and the same loop would have cost money.

rETH looping is mechanically open on Aave V3 (rETH collateral in e-mode at 93% LTV, WETH borrowable at 2.05%, $860M available) but the spread is too thin to leverage. We’d rather show the DAO we ran the numbers and declined than pad the proposal.

Exit path

Instant rETH → ETH redemption depends on the deposit pool holding excess ETH (0 today), so protocol redemption at size waits for inflows. The secondary route is DEX liquidity — ~$8M direct rETH/ETH depth on mainnet plus ~$13.8M in the osETH-rETH Curve pool — so an at-size exit is executed in tranches over a short window, automated: DEX in tranches while the discount is narrow, protocol redemption when the pool refills.

Is there any related work this builds off of?

Our own ecosystem LST playbook. We partner directly with each ecosystem so that our product becomes the adoption engine for their staking token and a source of sticky liquidity:

• Flow — ayFLOW (live since Sept 2025): drove staked-FLOW adoption 3–4× above the ecosystem’s prior baseline, purely through product deposits.
• Katana — ayKAT (live): KAT-based yield driving adoption of avKAT, the staked version of KAT.
• Polygon — ayPOL (coming soon): the same construction applied to POL.

Rocket Pool + rETH is the natural next partner — a larger, more liquid market than any of the above.

Existing protocols and data this builds on: Rocket Pool’s rETH and deposit-pool contracts; Aave V3 (e-mode collateral/borrow markets); Hyperliquid (ETH perp hedge venue); GMX V2 (LP leg); Curve/DEX liquidity for entry and exit. The rETH assessment above reproduces from on-chain archive reads and public APIs.

Will the results of this project be entirely open source?

Partially, and we want to be precise about which parts.

• Open (MIT): the full rETH assessment package — the data, scripts, and charts behind every figure in this application — can be published under MIT for the GMC and community to reproduce.
• Publicly verifiable, not open-source: AlphaYields’ proprietary AI/ML code will not be open-sourced, because they are the product AlphaYields operates commercially. They are, however, deployed on-chain and independently auditable, and the rETH holdings accumulated through ayETH will be viewable on a public dashboard and directly on Etherscan. APY is derived from on-chain share price, so returns are independently checkable.

In short: the analysis is open; the product code stays proprietary but is on-chain, audited, and transparently reportable.

Benefit

Group	Benefits
Potential rETH holders	A one-deposit ETH-yield product that holds rETH under the hood — an easy on-ramp to rETH exposure for users who would never manually stake, broadening who ends up holding rETH.
rETH holders	Net-new structural demand that scales with ayETH TVL, plus the discount-capture entry that puts buy-side pressure behind the secondary price and supports the peg.
Potential NOs	Indirect — growth in rETH demand and TVL strengthens protocol economics that underpin node-operator revenue over time.
NOs	Indirect — the same demand/TVL growth supports commission economics and protocol health.
Community	Transparent, on-chain reporting of rETH accumulated via ayETH; a flagship delta-neutral integration that showcases rETH; multichain reach for rETH via LayerZero.
RPL holders	rETH TVL growth is the primary driver of protocol revenue accrual; net-new, sticky demand plus peg support are constructive for RPL holders (indirect).

Which other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?

AlphaYields (the applicant) benefits commercially, earning protocol fees on ayETH TVL — disclosed here and under Conflict of Interest. Usage would also flow to Aave V3, Hyperliquid, GMX V2, Curve/DEX liquidity venues, and LayerZero as the strategy’s underlying rails. More broadly, any ETH-holding DAO or treasury (e.g. NounsDAO) stands to benefit: ayETH gives them a delta-neutral, USD-denominated home for otherwise-idle ETH — which in turn becomes another channel of net-new rETH demand.

Work

Who is doing the work?

The AlphaYields team.

What is the background of the person(s) doing the work? What experience do they have with such projects in the past?

• Filipe Leonor (Founder) — Serial entrepreneur and DeFi investor with over 12 years of team leadership experience; co-founder of Decentralized Foundation, a web3 revenue-share model protocol on Avalanche with a charitable focus. LinkedIn
• Bogdan Ivaniuk (ML/AI Lead) — Co-founder and CEO of AlphaCube, building AI solutions for algorithmic trading. 12 years as a quantitative analyst and AI/ML engineer. LinkedIn

Directly relevant experience: we have already run this exact adoption model on Flow (ayFLOW) and Katana (ayKAT), with ayPOL for Polygon in progress.

What is the breakdown of the proposed work, in terms of milestones and/or deadlines?

Delivery is committed within three weeks of approval:

• Week 1 — Integration: rETH deposit/mint and redeem routing, exchange-rate hedge automation, phased-exit logic.
• Week 2 — Review & liquidity: independent review of the rETH-specific code paths; bootstrap rETH/ETH entry/exit liquidity.
• Week 3 — Launch: ayETH live on mainnet with rETH as base asset; public rETH-held dashboard; joint education with the Rocket Pool community.

How is the work being tested? Is testing included in the schedule?

Yes — testing is in Week 2. The ayETH strategy contracts are audited, and the rETH-specific paths (deposit-pool interaction, redemption, exit tranching, exchange-rate hedge re-strike) get an independent review. Launch is preceded by testnet and mainnet dry-runs. In production, delta-neutrality is monitored continuously (residual β, measured at −0.004 on the GMX leg) with automated margin maintenance. The on-chain assessment behind the numbers is reproducible, and its scripts are available for review.

How will the work be maintained after delivery?

ayETH is a live product AlphaYields operates. Ongoing strategy management, rebalancing, hedge maintenance, and dashboard upkeep are part of running the protocol at no additional cost to the GMC. No recurring RP funding is requested.

Costs

What is the acceptance criteria?

• ayETH deployed on Ethereum mainnet with rETH as its base asset.
• Users can deposit and the product accumulates rETH under the hood.
• A public dashboard reports rETH held via ayETH, verifiable on-chain / Etherscan.
• The position is delta-neutral (measured residual β near zero).
• Delivered within three weeks of approval.

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

A flat $30,000, requested as a single payment on acceptance.

Who will directly receive the payment?

USDC or ETH on Ethereum mainnet to: 0x26992251c55af3e2b541d985cac23369253f3337

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

On-chain. The GMC can confirm, before releasing payment, that the ayETH contract is live with rETH as its base asset and that the public dashboard reports rETH held — all independently checkable on Etherscan and from the on-chain share price.

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

AlphaYields self-funds the core protocol build; this grant is scoped only to the rETH-specific integration, the review of those paths, and the entry/exit liquidity bootstrap that addresses rETH’s thin instant-redemption depth. Without the grant the integration can still happen, but more slowly and without dedicated liquidity bootstrapping — which is exactly the piece that de-risks at-size rETH entry and exit for users.

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?

No member of the GMC participated in this work, and to our knowledge no GMC member benefits financially from it. The applicants (Filipe Leonor and Bogdan Ivaniuk) are founders of AlphaYields.

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?

Yes. AlphaYields earns protocol fees on ayETH TVL and therefore benefits commercially if ayETH succeeds. The underlying venues (Aave V3, Hyperliquid, GMX V2, Curve/DEXs, LayerZero) also see usage. We disclose this openly; the aligned outcome is that ayETH’s success is driven by, and drives, net-new rETH demand.

[adalhi]

Name of Grant: Rocketpool Monthly Financial Reporting & Analysis

What is the work being proposed?

Produce monthly reports analyzing the state of Rocketpool, rETH and RPL.

These reports would include (but not limited to): TVL growth, Fees, DAO Expenses, Revenues, RPL Metrics, rETH main pools & APYs, Governance updates, new integrations…anything relevant to the community.

Is there any related work this builds off of?

The grant will utilize data sources like Defillama, Blockworks, Token Terminal, Dune…

Data about the protocol already exists, but scattered across multiple sources. The objective is to gather all relevant information about RocketPool Ecosystem in monthly reports shared with the community on the governance forum.

Will the results of this project be entirely open source?

The reports will be shared with the community on the governance forum.

Benefits: The grant’s objective is to bring transparency and inform the community about the state of Rocketpool ecosystem in a summarized format.

Who is doing the work?

I am a grantee of Uniswap, Compound, Aave, Paraswap, Gearbox…

What is the background of the person(s) doing the work? What experience do they have with such projects in the past?

I produced similar reports for Uniswap & Compound previously.

Examples here: Defi Financial Reporting & Analysis – Google Drive

What is the breakdown of the proposed work, in terms of milestones and/or deadlines?

Monthly Reports produced max 15 days from month end.

How will the work be maintained after delivery?

I propose a trial run of 3 monthly reports, then extend the grant if the work is satisfactory.

What is the acceptance criteria?

Monthly Reports similar to what I produced previously for Uniswap and Compound.

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

500 USD per Monthly report, paid after the report production.

This application proposes a trial run of 3 months, extendable afterwards, total 1500 USD for 3 monthly reports.

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

Wallet address to be communicated if the grant is approved.

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

The reports will be shared on this forum directly. No pdf or external dependencies.

Does the person or persons proposing the grant have any conflicts of interest to disclose?

No

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

[Instaswap]

## Name of Grant

InstaSwap: cross-chain rETH access. Acquire, receive, and get paid in rETH from any asset on any chain (including Bitcoin, Bitcoin Lightning, Solana, and Zcash), with an embeddable widget and partner API. ($15,000)

### What is the work being proposed?

We propose to make **rETH a first-class, cross-chain destination inside InstaSwap** and to ship it as a reusable **widget and partner API**, so that anyone, on any chain, holding any asset, can move into rETH in one step, with no manual staking and no wallet setup. Most of this already runs in production today: rETH is already a live swap destination in our engine, so **a user can convert BTC, SOL, USDT, and any asset across 67 chains straight into rETH delivered to their Ethereum or L2 address right now.** Every flow below can be tried in the live app today (see “Try it now”). This grant funds turning that into a dedicated Rocket Pool on-ramp with distribution.

Concretely, we will deliver a Rocket Pool “rETH toolkit” built on our existing rails:

- **Swap into rETH from anything, anywhere.** Any asset on any of 67 supported chains converts to rETH, walletless, delivered to the user’s address. Live today; we harden it into a dedicated flow.

- **Mint-preferred routing.** When the Rocket Pool deposit pool has capacity we route to primary mint (new rETH, growing TVL); otherwise we use best-execution on secondary markets. Either way the user simply receives rETH.

- **Get paid in rETH (Payments).** A payment link or page where whoever pays, in any asset on any chain, results in the recipient holding rETH. rETH becomes a receive currency, so income can accumulate into staked ETH automatically.

- **Split into rETH (Split).** Route a chosen percentage of an incoming payment into rETH automatically, for dollar-cost accumulation or for treasuries putting idle assets to work.

- **Receive rETH by name (ENS).** Send to a name such as `alice.eth` and the recipient receives rETH, cross-chain. Our cross-chain ENS resolution already ships in the product.

- **Private entry (optional), two modes.** A user can accumulate rETH with no public on-chain link between the source of funds and the rETH-holding address, either through a confidential rail or through a ZKProof mode, with settlement on-chain and no custodian in the middle. No other non-custodial on-ramp offers ZKProof or confidential entry into a liquid staking token.

- **Embeddable widget and partner API.** Every flow above is exposed through one integration, so any wallet, app, or Rocket Pool ecosystem project can add “Stake to rETH from anything” with a single change on their side, up to a full white-label deployment. This turns our distribution into net-new rETH demand across many front-ends, not just ours.

- **Revenue-share incentive for integrators.** Partners that embed the widget or API earn a share of the fee on the rETH volume they bring, funded entirely by InstaSwap at no cost to Rocket Pool. This gives wallets and apps a direct financial reason to promote rETH access, so rETH adoption compounds across many independent front-ends.

- **Public rETH dashboard.** A public page reporting the rETH brought into Rocket Pool through InstaSwap, verifiable on-chain.

The result: a cross-chain distribution layer for rETH that reaches an audience Rocket Pool has no non-custodial, integrable on-ramp for today (Bitcoin, Bitcoin Lightning, Solana, Zcash, and multichain stablecoin holders), with the acquisition made effortless (walletless, one step), settled on-chain without a custodian, and, optionally, private.

_Figure 1: Zcash to rETH in the live app today. The user enters the ZEC amount and receives rETH on Ethereum, walletless, no ETH required._

_Figure 2: the privacy selector
on the same flow. Public, Private (confidential rail), or ZKProof entry into rETH._

### Try it now (live today, no sign-up)

Everything below runs in production right now. Each link opens the live app with the flow prefilled, so the GMC can verify the claims before reading further:

- **Bitcoin to rETH:** Private Crypto Swaps | InstaSwap App

- **Solana to rETH:** Private Crypto Swaps | InstaSwap App

- **Bitcoin Lightning to rETH:** Private Crypto Swaps | InstaSwap App

- **Zcash to rETH:** Private Crypto Swaps | InstaSwap App

- **Stablecoins to rETH (from an L2):** Private Crypto Swaps | InstaSwap App

- **Private entry into rETH:** open any link above and select Private or ZKProof in the privacy selector before quoting.

- **Get paid in rETH (Payments):** Private Crypto Swaps | InstaSwap App (choose rETH as the asset, set the amount, share the link; the payer funds it with anything). Example request: Payment request | Instaswap.com

- **Split into rETH (Split Swap):** Private Crypto Swaps | InstaSwap App (one deposit, up to 100 payouts, rETH as a destination asset).

_Figure 3: a payment request denominated in rETH. Whoever pays, in any asset on any chain, the recipient holds rETH._

_Figure 4: Split Swap with rETH as a destination. One deposit, a chosen share routed into rETH automatically._

- **Receive rETH by name (ENS):** Payment request | Instaswap.com (any ENS name works; the sender pays in any asset on any chain).

_Figure 5: paying an ENS name. Here `vitalik.eth` is resolved on the fly and the name receives rETH, funded by the sender from any asset on any chain._

- **RPL cross-chain:** Private Crypto Swaps | InstaSwap App

- **Partner API (the same rails, programmatically):** Crypto Swap API for Cross-Chain Swaps | InstaSwap

- **Embeddable widget:** Crypto Swap Widget for Your Website | InstaSwap

_Figure 6: the same rETH flow exposed through the partner API and the embeddable widget, so any wallet or app can offer “Stake to rETH from anything” with one integration._

### Is there any related work this builds off of?

Yes. This builds directly on InstaSwap’s live infrastructure:

- A cross-chain routing engine spanning **67 chains** (including Bitcoin, Bitcoin Lightning, Solana, Zcash, Cosmos, XRP, Aptos, Cardano, and the major EVM L1s and L2s), already in production.

- A walletless swap product, a Payments product, and a Split product, all live.

- A partner API and affiliate system used by third-party integrators today.

- A confidential settlement rail for private execution.

- Cross-chain ENS name resolution, already shipped in the product.

On the Rocket Pool side it builds on rETH and, for mint-preferred routing, the Rocket Pool deposit pool. rETH is already enabled as a destination in our engine; RPL is also enabled (token `0xd33526068d116ce69f19a9ee46f0bd304f21a51f`).

**How this differs from what exists.** We want to be upfront about the landscape. Buying rETH with another asset is possible today through two kinds of services: EVM-only aggregators (which cannot originate from Bitcoin, Lightning, Solana or Zcash at all), and centralized instant exchanges that do reach those chains but hold user funds in custody, can freeze or KYC a transaction mid-flight, and offer a swap and nothing else. InstaSwap is neither: every rETH acquisition settles on-chain to the user’s own address with no custodian, and the same rails offer a confidential mode and a ZKProof mode that no custodial service can provide. Our rails are already used as infrastructure by third-party aggregators that resell our non-EVM routes, which is exactly the point: the routing exists and is proven. What does not exist anywhere, and what this grant funds, is a Rocket Pool-facing rETH toolkit on top of it: mint-preferred routing that grows rETH supply, get-paid-in-rETH and split-into-rETH flows, receive-by-name, an embeddable widget and partner API with revenue share so other front-ends promote rETH, and a public dashboard with a 90-day impact report to the GMC.

### Will the results of this project be entirely open source?

Partially, and we want to be precise.

- **Open (MIT):** the widget integration reference, the partner API documentation and examples for the rETH flows, and the public dashboard’s read/aggregation scripts can be published under MIT so the community can integrate and reproduce.

- **Publicly verifiable, not open source:** InstaSwap’s core cross-chain routing engine is the platform we operate commercially and will not be open sourced. It is, however, independently verifiable on-chain: the on-chain settlement (including the contracts involved) is public, every rETH delivery is an on-chain transaction, and the dashboard’s figures are checkable on Etherscan.

In short: the integration surface and reporting are open; the routing engine stays proprietary but its results are transparently verifiable on-chain.

## Benefit

| Group | Benefits |

|—|—|

| Potential rETH holders | A new way to get rETH from any asset on any of 67 chains (Bitcoin, Bitcoin Lightning, Solana, Zcash, multichain stablecoins), with no ETH required, no manual staking, no wallet setup and no custodian (settlement lands on-chain at the user’s own address), plus an optional private entry and platform reward points on every acquisition. This broadens who can realistically end up holding rETH far beyond people who already sit on ETH on Ethereum. |

| rETH holders | Net-new, structural demand that scales with adoption of the widget and the get-paid-in-rETH and split-into-rETH flows, plus deeper practical utility for rETH as a cross-chain receive currency. |

| Potential NOs | Indirect: growth in rETH demand and TVL strengthens the protocol economics that underpin node-operator revenue over time. |

| NOs | Indirect: the same demand and TVL growth supports commission economics and overall protocol health. |

| Community | A widget and partner API any Rocket Pool ecosystem app or wallet can embed to offer rETH access; multichain reach for rETH; and a transparent, on-chain dashboard of the rETH brought in through InstaSwap. |

| RPL holders | rETH TVL and demand growth is the primary driver of protocol revenue accrual; net-new, cross-chain, price-insensitive demand is constructive for RPL holders (indirect). Directly: RPL itself is now live as a cross-chain destination in InstaSwap, so RPL can be acquired from any asset on any of the 67 chains through the same walletless flow, widening access to RPL beyond Ethereum-native holders. |

### Which other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?

InstaSwap (the applicant) benefits commercially, earning its standard swap fee on rETH-routed volume, disclosed here and under Conflict of Interest. Wallets and apps that embed the widget or partner API benefit directly: they earn a share of the fee on the rETH volume they bring (funded by InstaSwap, at no cost to Rocket Pool), which gives them a standing financial incentive to promote rETH access to their users. Any ETH-holding DAO or treasury benefits too: the split-into-rETH and get-paid-in-rETH flows give them an easy, cross-chain way to move idle assets into rETH, which in turn is another channel of net-new rETH demand. We are already working with Nouns DAO, and treasury flows into rETH through these rails are part of that collaboration.

## Work

### Who is doing the work?

The InstaSwap team.

### What is the background of the person(s) doing the work? What experience do they have with such projects in the past?

The InstaSwap founding team that built and operates the platform described below.

- **Athanasios Kontos, Founder and CEO.** [LinkedIn](https://www.linkedin.com/in/sakis-k-instaswap/) | [X]( Sakis.INS (@tk_instaswap) / X )

- **Dim Maraslis, Co-Founder and CTO.** [LinkedIn](https://www.linkedin.com/in/dimitris-m-8176a87a/) | [X]( Dimitris M (@dim_instaswap) / X )

Our track record is the platform itself. InstaSwap is a privacy-first cross-chain platform that has been live for **8+ years**, with **over $2.03B in volume settled across 67 chains** and average settlement around 4 minutes, serving users today at app.instaswap.com. Our partner API and widget are already integrated by third-party wallets and platforms in production, which is the exact distribution channel this grant uses for rETH. The platform already spans native cross-chain swaps, Split Swap, Payments, Spot trading, Perpetuals, and tokenized stocks and ETFs, alongside a partner API, an embeddable widget, white-label deployments, an affiliate and revenue-share system, confidential and ZKProof settlement, cross-chain ENS resolution, and KYT/AML screening with fully non-custodial settlement. In other words, we have shipped and operated exactly this kind of cross-chain, walletless, multi-venue product at scale for years. The rETH-specific work below is a focused productization on top of that existing, in-production infrastructure, which is why it ships in one week.

### What is the breakdown of the proposed work, in terms of milestones and/or deadlines?

Our rails already exist and are in production (67 chains, walletless swaps, Payments, Split, the partner API and revenue-share, the confidential and ZKProof private modes, cross-chain ENS, and live rETH swaps). That is exactly why the timeline is short and the cost is low: the grant funds the rETH-specific work and the genuinely new pieces, not rebuilding infrastructure. Delivery is committed within **one week of approval**:

- **Days 1 to 3 (rETH-first flows plus new mint routing):** wire rETH as a first-class target into the existing Swap, Payments, and Split flows with a dedicated stake-to-rETH experience, and build **mint-preferred routing**, the main new component (route to the Rocket Pool deposit pool for primary mint when it has capacity, best-execution on secondary markets otherwise).

- **Days 4 to 5 (packaging for distribution):** package the existing rails into an embeddable “Stake to rETH from anything” widget and a documented partner API endpoint for rETH, connect the confidential and ZKProof private-entry modes to the rETH flows, and add receive-rETH-by-name on top of our existing ENS resolution.

- **Days 6 to 7 (reporting plus launch):** build the public rETH dashboard (new), test across the required assets, launch, and run joint education with the Rocket Pool community.

### How is the work being tested? Is testing included in the schedule?

Yes, testing runs throughout the week. We test cross-chain quote and settlement into rETH across the assets that must work (Bitcoin, Bitcoin Lightning, Solana, Zcash, USDT, ETH, and major stablecoins), the widget and partner API through integration tests, and the private entry path end to end. The dashboard reads on-chain, so its figures are independently verifiable. rETH swaps are already live today and can be tried before work begins through the links in “Try it now”.

### How will the work be maintained after delivery?

InstaSwap operates this as part of its live product. Ongoing routing, integration upkeep, and dashboard maintenance are part of running the platform at **no additional cost to the GMC**. No recurring Rocket Pool funding is requested.

## Costs

### What is the acceptance criteria?

Delivery (within one week of approval):

- Users can acquire rETH from any supported asset on any supported chain and receive it to their address, walletless.

- The embeddable widget and the partner API endpoint for rETH access are live and documented.

- Optional private rETH entry (confidential and ZKProof modes) is available.

- A public dashboard reports the rETH brought into Rocket Pool through InstaSwap, verifiable on-chain.

Measurable adoption targets (reported publicly on the dashboard, verifiable on-chain):

- **Within 30 days of launch:** at least **3 third-party wallets or platforms** live with the rETH widget or API, and the first cross-chain rETH acquisitions from **at least 5 non-Ethereum source chains** (including Bitcoin and Solana) settled and visible on the dashboard.

- **Within 90 days of launch:** a public impact report posted on this forum covering rETH acquired through InstaSwap, the share routed to primary mint versus secondary markets, source-chain breakdown, and integrator count, so the GMC can judge the outcome on data rather than on claims.

The grant payment is tied only to the delivery criteria above. The adoption targets are our public commitment and are reported regardless.

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

**$15,000 total**, requested **as a single payment after acceptance**. No upfront payment is requested.

### Who will directly receive the payment? (Required)

USDC, ETH, or RPL on Ethereum mainnet to: **0x3758765532cfd0D55018e9A18f1aeB3dc9E26ca9**

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

On-chain and in-product. The GMC can confirm the widget and partner API are live, that a cross-chain swap into rETH works end to end, and that the public dashboard reports rETH brought in, all independently checkable on Etherscan and in the live product.

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

InstaSwap self-funds its core cross-chain engine, and rETH swaps are already live, so this grant is scoped only to the rETH-specific productization: the dedicated flows, mint-preferred routing, the widget and partner API, the private entry, and the public dashboard. Because the hard part (the multichain engine) already exists, the cost is small relative to the distribution and net-new rETH demand it unlocks.

### 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?

No member of the GMC participated in this work, and to our knowledge no GMC member benefits financially from it.

### 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?

Yes. InstaSwap earns its standard swap fee on rETH-routed volume and therefore benefits commercially if these flows succeed. We disclose this openly; the aligned outcome is that InstaSwap’s success is driven by, and drives, net-new cross-chain rETH demand.

[PREDGE]

Name of Grant

pDAO Proposal Evidence Ledger: independent, signed, replayable records for every on-chain pDAO proposal

What is the work being proposed?

Since Houston, Rocket Pool’s Protocol DAO runs an optimistic fraud-proof process. A proposer bonds RPL and submits a Merkle-sum pollard of network voting power at a block. Any node can challenge an index, the proposer must answer with a deeper pollard, and if they cannot, the proposal is defeated and bonds move. Smartnode already includes an opt-in verifier (verifyPdaoProps) that does this automatically for operators who enable it. But each verifier’s result lives only in that operator’s local logs. There is no public, independently reproducible record that says, for each proposal: “the submitted voting-power root was recomputed by a third party, here is the result, here is every challenge and response, here is how the vote and execution ended.”

I propose a small, read-only, open-source tool and a public archive that fill that gap:

1. Recompute. For every on-chain pDAO proposal since Houston, read the RootSubmitted / ChallengeSubmitted events from rocketDAOProtocolVerifier and the proposal state from rocketDAOProtocolProposal. Then independently recompute the network voting-power tree at the proposal’s target block from the on-chain voting snapshots (rocketNetworkVoting, delegation getters), with an archive RPC only where a snapshot getter is not enough. Compare the recomputed root and pollard nodes with the submitted ones.
2. Record. Produce one evidence pack per proposal as canonical JSON: proposal ID, proposer, target block, submitted root and pollard, recomputed root, per-node match/mismatch, the full challenge/response timeline with tx hashes and block numbers, vote tallies per phase, quorum, final state and execution tx. Every field carries the RPC call or log reference it came from.
3. Sign. Hash each pack (SHA-256) and sign it with a dedicated ed25519 key whose public key is published in the repository and in this thread. A short Python verifier (standard library plus one ed25519 package) checks signatures and hashes offline.
4. Publish. Serve a static archive: one page per proposal plus an index and an RSS/JSON feed. When a new proposal appears, a pack is published within 24 hours of its RootSubmitted event and updated as challenges, votes and execution happen. Earlier versions stay in the archive, so a pack can be appended to but not silently rewritten.

The tool never holds keys that can transact, never submits challenges and never broadcasts transactions. It observes, recomputes and records. Operators who want to act still use Smartnode.

Is there any related work this builds off of?

• Rocket Pool’s own specification and code: RPIP-33, the pdao-prop-challenge-spec in rocketpool-research, RocketDAOProtocolVerifier.sol, and Smartnode’s network voting tree and verifyPdaoProps logic, which serves as the reference implementation that our recomputation is tested against.
• The applicant’s existing work on Predge, which indexes UMA Optimistic Oracle disputes on Polymarket (the same propose / dispute / resolve pattern) and publishes ed25519-signed evidence packs. A public example of the evidence-pack format: Settlement Risk sample pack · Predge (that sample is signed with a demo key, as the page states; this grant would use a new dedicated key).

Will the results of this project be entirely open source?

Yes. Code, tests, fixtures, the evidence-pack schema and all generated packs will be published under MIT. The signing key is the only private element, and only its public key matters for verification.

Benefit

Group	Benefits
Potential rETH holders	Indirect: a public, third-party record that protocol parameter changes and treasury spends went through a checked process is something an rETH due-diligence reviewer can cite.
rETH holders	Indirect: governance changes that affect rETH are independently recorded and verifiable without running a node.
Potential NOs	Clearer, readable view of how pDAO proposals, challenges and bonds actually work, built from real history rather than documentation alone.
NOs	Operators who do not enable the verifier duty can still see whether each proposal was independently checked. Operators who do enable it get an external cross-check of their own verifier’s result. Delegates get a per-proposal record to point to.
Community	A durable, signed, appendable public archive of pDAO history, linkable from forum threads and governance summaries.
RPL holders	Treasury and parameter proposals carry a verifiable process record, which lowers the cost of monitoring governance.

Which other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?

Other optimistic governance and oracle systems (bonded proposals with challenge windows) could reuse the evidence-pack schema and verifier. This grant is scoped to Rocket Pool’s pDAO only.

Work

Who is doing the work?

Amir, solo developer of Predge.

What is the background of the person(s) doing the work? What experience do they have with such projects in the past?

I build Predge, a data and evidence service for prediction-market resolution. It indexes UMA Optimistic Oracle activity on Polygon for Polymarket. For example, from 1 January to 2 October 2026 it recorded 3,005 UMA disputes on 2,666 Polymarket markets, and of the 2,543 disputed markets that have settled, 853 (33.5%) settled differently from the disputed proposal. Predge publishes ed25519-signed evidence packs and serves data through an x402 pay-per-call API. I have also written bond and arbiter smart contracts for verdict-style dispute flows. The relevant skills are reading propose/dispute/resolve event flows from chain, reconstructing timelines exactly, and producing records that a third party can verify offline.

I have not previously contributed to Rocket Pool and have not received GMC funding. The scope and price below reflect that.

Code: PREDGE · GitHub

What is the breakdown of the proposed work, in terms of milestones and/or deadlines?

• Milestone 1: historical recomputation and verifier (weeks 1 to 3 after approval). Indexer for all pDAO proposals since Houston; independent voting-power tree recomputation; evidence packs for every historical proposal; offline verifier; test suite; schema documentation.
• Milestone 2: live archive (weeks 4 to 6). Watcher for new proposals; static public archive with per-proposal pages, index and RSS/JSON feed; packs published within 24 hours of RootSubmitted and updated through challenge, vote and execution; append-only version history.
• Milestone 3: three months of operation (months 2 to 4). Run the watcher. Publish a pack for every new proposal and fix reproducible defects. At the end, post a short write-up in this forum covering what the archive recorded and any discrepancies found.

How is the work being tested? Is testing included in the schedule?

Yes, in every milestone:

• Recomputed trees are tested against Smartnode’s own tree generation for the same blocks (reference implementation), and against the roots stored on-chain.
• Mainnet event fixtures for every historical proposal are committed, so the full archive can be regenerated offline and byte-compared.
• Negative fixtures: tampered pack, wrong signature, wrong hash, missing log, mismatched pollard node, wrong verifier contract address (the verifier address has changed across upgrades and Smartnode tracks previous addresses), incomplete pagination.
• A pack is never marked “verified” if any input is missing or conflicting. It is marked “inconclusive” with the reason stated.

How will the work be maintained after delivery?

The repository stays public under MIT. During Milestone 3 I operate the watcher and fix issues. After that, the archive is static and anyone can regenerate it from chain with the published code. If the community wants continued operation beyond three months, that would be a separate, small follow-up request. No recurring payment is requested here.

Costs

What is the acceptance criteria?

1. Public MIT repository with indexer, recomputation, pack generator, offline verifier, tests and docs.
2. One signed evidence pack per historical on-chain pDAO proposal since Houston, regenerable offline from committed fixtures.
3. For each historical proposal, the recomputed root either matches the submitted root, or the mismatch is recorded together with the challenge outcome. No silent discrepancies.
4. The verifier passes on all published packs and fails on all negative fixtures.
5. Public archive with per-proposal pages and a feed. New proposals appear within 24 hours of RootSubmitted during Milestone 3.
6. No transaction signing, no private keys that control funds, no automated challenges.

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

$3,200 total, over about four months, each tranche paid only after the GMC accepts that milestone:

• Milestone 1: $1,400
• Milestone 2: $1,200
• Milestone 3: $600 (after three months of operation and the write-up)

RPL or USDC, whichever the GMC prefers. Hosting and RPC costs are covered by the applicant.

Who will directly receive the payment?

Ethereum address: 0x102c601688B1fF5B285B68C83953B979cBae8507

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

Each milestone ends with a forum post linking a tagged release, the test results, and the commands that regenerate the packs offline. A reviewer can pick any proposal ID, run the verifier, and compare the pack against Etherscan and the rocketDAOProtocolVerifier events. For Milestone 3, the publication time of each new pack can be compared against the block time of its RootSubmitted event.

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

• No hosted backend or database: static archive only.
• No dashboard framework: plain HTML pages and a feed.
• No reimplementation of what Smartnode already does for operators. Smartnode is the reference, and this tool only adds the public, signed record.
• oDAO submissions (balances, prices, rewards trees) were considered and left out of scope to keep the cost small. The same pack format could cover them later if the community wants it.

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?

I am not a GMC member, and no GMC member is involved in or benefits from this work. I hold no RPL or rETH and do not operate a Rocket Pool node.

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?

Indirectly and modestly. The evidence-pack format is the same one I use in Predge, my prediction-market data project, which is unrelated to Rocket Pool and has no Rocket Pool integration. All code and packs produced under this grant are MIT-licensed and free to reuse. No token, fee or paid tier is attached to this work.

[franklinwilster]

Name of Grant

Rocket Pool TypeScript SDK & Integration Conformance Kit

What is the work being proposed?

I am proposing a focused open-source TypeScript SDK and conformance kit for developers integrating Rocket Pool and rETH into applications.

The practical gap is straightforward: Rocket Pool’s older rocketpool-js repository is archived and read-only, while application developers still need typed, testable building blocks for current Rocket Pool integrations without each team maintaining its own ABI/address glue and one-off RPC logic.

The project would provide:

• a modern TypeScript package for selected public Rocket Pool read/write integration paths;
• typed contract bindings and network/address resolution for supported deployments;
• rETH-focused helpers for common integration flows, with transaction construction separated from signing/broadcasting;
• a small conformance suite that checks the SDK against pinned Rocket Pool interfaces/deployments;
• reproducible examples for Node.js and browser/React-style integrations;
• migration notes for developers coming from the archived rocketpool-js package;
• CI, tests, versioned fixtures and clear unsupported-version behavior.

This is intentionally not a replacement for Smartnode and not a hosted service. It is a developer integration layer.

No substantial implementation has been completed yet; this application is for prospective work.

Is there any related work this builds off of?

Yes. The main reference point is the official Rocket Pool rocketpool-js repository, which GitHub marks as archived/read-only. The project would also build from Rocket Pool’s public contract interfaces, deployment information and documentation.

The goal is to preserve the useful idea of a JavaScript integration library while rebuilding the surface around current TypeScript tooling, reproducible tests and explicit version/deployment support rather than extending the archived package.

Will the results of this project be entirely open source?

Yes. The source, tests, fixtures, examples and documentation will be public under the MIT license.

Benefit

Group	Benefits
Potential rETH holders	Makes it easier for wallets, dashboards and applications to add straightforward rETH integration paths instead of requiring custom contract code.
rETH holders	Better application-level integration can improve the availability and reliability of tools that expose rETH balances, rates and supported actions.
Potential NOs	Indirect benefit: third-party tools can consume Rocket Pool data through a documented TypeScript layer instead of rebuilding contract access from scratch.
NOs	Indirect benefit through easier integration of Rocket Pool state into external developer tooling. This project does not replace Smartnode operator workflows.
Community	Reduces duplicated integration code, provides reproducible examples and gives developers a public compatibility/conformance target.
RPL holders	Indirect benefit from lower integration friction and broader developer support for Rocket Pool applications.

Which other non-RPL protocols, DAOs, projects, or individuals would stand to benefit from this grant?

Wallet developers, dashboards, analytics tools and general Ethereum application developers could reuse the package and test patterns. The implementation would remain Rocket Pool-specific; I am not proposing a generic multi-protocol SDK.

Work

Who is doing the work?

Franklin Wilster, an independent technical contributor based in Brazil.

GitHub: franklincg · GitHub

What is the background of the person doing the work? What experience do they have with such projects in the past?

My background is in technical automation and developer tooling: TypeScript/Python, APIs, SDK-style integrations, databases, CI workflows and open-source contribution work.

I am not claiming prior Rocket Pool team affiliation or previous Rocket Pool compensation. The relevant fit here is implementation work around APIs, typed integration layers, automation and reproducible testing.

What is the breakdown of the proposed work, in terms of milestones and/or deadlines?

Proposed delivery: six weeks from award/start.

Milestone 1 - foundation and compatibility surface (Weeks 1-2)

• public repository and package structure;
• supported-network/deployment registry;
• typed contract interfaces for the agreed initial surface;
• core read helpers;
• fixtures and CI;
• exact supported/unsupported version behavior documented.

Milestone 2 - integration helpers and examples (Weeks 3-4)

• rETH-focused integration helpers;
• transaction-building helpers that do not custody keys or broadcast transactions;
• Node.js example;
• browser/React-oriented example;
• error handling and malformed/incomplete RPC cases;
• migration notes from the archived JavaScript package where relevant.

Milestone 3 - conformance, documentation and release (Weeks 5-6)

• conformance tests against pinned Rocket Pool interfaces/deployments or an agreed public test environment;
• clean-install CI verification;
• documentation and API reference;
• release tag/package;
• reproducible verification commands and final handoff notes.

How is the work being tested? Is testing included in the schedule?

Yes. Testing is part of every milestone.

The project will include:

• unit tests for encoding/decoding and helper logic;
• ABI/interface compatibility tests;
• local fork or public test-environment integration tests where appropriate;
• negative tests for wrong networks, unsupported addresses, missing RPC data and stale configuration;
• clean-install/build checks in CI;
• reproducible example runs.

The SDK will not handle private keys or custody funds. Transaction helpers will construct typed requests/calldata; signing remains with the integrating wallet/application.

How will the work be maintained after delivery?

I will keep the repository public and provide a 90-day bug-fix window for reproducible defects in the delivered scope.

After that, issues and pull requests can remain open in the public repository and straightforward compatibility fixes can continue on a best-effort basis. A major future protocol expansion would be treated as a separate scope rather than silently turning this into an ongoing paid service.

Costs

What is the acceptance criteria?

The grant is complete when:

1. A public MIT-licensed repository contains the SDK, tests and documentation.
2. The TypeScript package builds cleanly from a fresh checkout.
3. Supported Rocket Pool deployments/interfaces are explicit and versioned.
4. The agreed rETH/core integration helpers are typed and documented.
5. Transaction helpers do not store private keys or broadcast on behalf of the user.
6. At least one Node.js and one browser-oriented integration example run successfully.
7. The conformance/integration test suite passes against the pinned supported environment.
8. CI passes on the release commit.
9. Migration/compatibility notes explain what is and is not covered relative to the archived rocketpool-js package.
10. Reproduction commands are documented so the GMC or another developer can independently verify the release.

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

US$8,000 total over approximately six weeks.

Proposed schedule:

• US$4,000 (50%) at award/start, to fund the implementation period;
• US$4,000 (50%) after the acceptance criteria above are met.

This is my proposed payment schedule, not a claim that the amount is already approved.

Who will directly receive the payment?

Ethereum recipient address:

0xea7D8ed7E0a7d491a0501086E828CA386Ac32876

Payment can be sent directly to this address using the GMC’s normal supported payment process. No invoice is required.

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

Each milestone will be visible in the public repository through commits, tests, CI and documentation.

For final verification, the GMC can:

• clone the repository at the release tag;
• run the documented install/build/test commands;
• run the included integration/conformance examples;
• inspect the supported deployment/interface registry;
• compare the release against the acceptance checklist above.

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

I deliberately kept the scope to a library and reproducible test/examples rather than a hosted dashboard or service.

The project will avoid:

• paid hosted infrastructure;
• databases or backend services that need ongoing operation;
• private-key management;
• transaction relaying;
• rebuilding Smartnode;
• broad multi-protocol abstractions.

The lower-cost alternative is for each integrator to maintain its own contract bindings and address/version logic. This proposal is intended to make that work reusable once.

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?

No GMC affiliation or relationship that would create a conflict is being claimed. I would receive the requested grant payment if the proposal is approved.

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?

I would benefit financially from the grant payment itself. The SDK would be open source and would not carry a usage fee, hosted subscription or token. This proposal does not depend on directing value to another protocol or project I control.

[steve]

Name of Grant

Rocket Pool rETH and Megapools: An English/Korean Research Report

What is the work being proposed?

Four Pillars proposes an eight-week, USD 10,000 project to publish one original 15–20-page English research report and a complete Korean edition on Rocket Pool’s rETH, Megapool architecture and the trade-offs of decentralized Ethereum staking. Short publication summaries will be shared through our existing X and Telegram channels.

The report will explain:

• How rETH’s documented staking, exchange-rate and liquidity mechanisms affect a holder’s evaluation, including the distinction between protocol redemption routes and secondary-market liquidity.
• How Megapools change Rocket Pool’s node-operator design, capital requirements, revenue allocation and protocol governance assumptions.
• What current and proposed upgrades mean for rETH holders and node operators, clearly distinguishing implemented mechanics, ratified changes and proposals still under discussion.
• The practical trade-offs between permissionless participation, capital efficiency, operator performance, smart-contract/oracle/governance assumptions and liquidity.

The work uses public primary sources and focused original analysis. Tables and explanatory visuals, where useful, are part of the report. The Korean edition will preserve the same findings and caveats while making technical terminology accessible to Korean-speaking professional readers. The intended value is a coherent reference for evaluating Rocket Pool and rETH; no increase in deposits, token price or conversion rate is promised.

Is there any related work this builds off of?

The report builds on Rocket Pool’s official protocol documentation (official Rocket Pool protocol documentation), current RPIPs and the Saturn 2 overview (RPIP-86, Saturn 2 Upgrade). The Saturn 2 overview is an evolving informational source rather than proof that every described component is deployed. We will recheck status at research kickoff and record information dates in the report.

At milestone 1, we will review existing official explanations, community research and our own publications to define the incremental contribution. This project funds new Rocket Pool-specific analysis and bilingual synthesis; existing publications are background rather than new grant deliverables.

Funding disclosure: Four Pillars has previously received grants from dYdX, Solana and Blur, among others, as confirmed by the applicant. Prior grant dates and amounts are not included in this application. Separate applications/proposals concern Filecoin storage research (Filecoin devgrants issue 2206), Uniswap LP research, dYdX perpetual-market research, Base creator content, Zcash shielded-payments research, Lido-specific staking research and Tezos. A separate The Graph proposal has been drafted but not submitted because its grant intake is paused. A separate Solana application was submitted before it was excluded from the current application campaign. These applications/proposals are not represented as awarded grants. Four Pillars has also submitted a separate Beam grant application. These applications are not funding awards.

This Rocket Pool report is distinct from the Lido proposal: its central subject is rETH, Megapool mechanics and Rocket Pool’s upgrade/governance choices. This request funds only the Rocket Pool deliverables described here. No personnel time, invoices, source-analysis work or deliverables will be charged twice. If multiple proposals are funded, kickoff dates will be staggered to fit confirmed staffing capacity.

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. All original text, translations, tables and explanatory visuals created with this grant will be freely accessible under Creative Commons Attribution 4.0 (CC BY 4.0): Creative Commons Attribution 4.0 International.

Existing Four Pillars publications and third-party material retain their existing rights and will be cited or used only as their terms permit. They are not relicensed through this grant.

Benefit

Group	Benefits
Potential rETH holders	A source-linked account of rETH mechanics, liquidity/redemption considerations and trade-offs supports an informed assessment of whether and how rETH fits their needs.
rETH holders	Clear distinctions between current mechanics and proposed changes help holders assess liquidity, protocol assumptions and the relevance of upgrades.
Potential NOs	A high-level explanation of Megapool design, capital requirements, commissions and operator responsibilities helps prospective operators understand the model before pursuing official setup guides.
NOs	A consolidated reference connects operator-side design changes with rETH-holder and governance implications; it complements official operating documentation.
Community	Freely accessible English and Korean analysis gives community members a shared, cited reference for discussing Rocket Pool’s design and current roadmap.
RPL holders	Analysis of protocol economics and governance choices can clarify the relationship between Rocket Pool design and RPL-related incentives without making price claims.

Which other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?

Ethereum staking participants, Korean-speaking institutional analysts and product/research teams may benefit from a public, source-linked explanation of decentralized staking choices. The primary funded subject and intended ecosystem beneficiary are Rocket Pool. Wider readers can reuse original CC BY 4.0 material with attribution; no separate deliverable for another protocol is included.

Work

Who is doing the work?

Steve Kim (Namwoong Kim), co-founder and CEO of Four Pillars, will lead the project and serve as the grant contact. He is responsible for scope, source selection, research/editorial quality, grant communication and final delivery.

Supporting research, Korean translation/editing and internal factual review will be assigned before kickoff. Four Pillars’ public roster documents organizational capacity; it does not imply that every listed colleague has accepted this project: Four Pillars official team page.

Public contact: [email protected]
Telegram: @FP_Steve
Steve’s public research profile: Steve Kim’s public Four Pillars researcher profile

What is the background of the person(s) doing the work? What experience do they have with such projects in the past?

Four Pillars combines protocol analysis, institutional research, data engineering and validator-infrastructure expertise, publishing blockchain research in English and Korean. Steve Kim is the organization’s co-founder and CEO. Our existing English/Korean publication process provides a practical basis for delivering the proposed report.

Verified portfolio:

• Research: https://research.4pillars.io/en
• Steve Kim: Steve Kim’s public Four Pillars researcher profile
• Team: Four Pillars official team page
• Korean Blockchain Guidebook for Institutions 2026, prepared with Pantera Capital: https://research.4pillars.io/en/research/korean-blockchain-guidebook-for-institutions-2026

As observed on 4 October 2026, the company X profiles displayed 17.6K English followers (rounded) and 4,629 Korean followers; the Telegram channels displayed 1,874 English subscribers and 3,115 Korean subscribers. These audiences can overlap and do not establish unique readership or guaranteed views. Distribution uses the existing company channels:
X: @FourPillarsFP
X: @FourPillarsKR
Telegram: @FourPillarsGlobal
Telegram: @FourPillarsFP

What is the breakdown of the proposed work, in terms of milestones and/or deadlines?

The eight-week period begins at the agreed kickoff after funding/terms are agreed and internal assignments are confirmed.

Weeks 1–2 / M1 — USD 2,000 after acceptance: finalize the annotated outline, public-source framework, comparison criteria and incremental contribution.

Weeks 3–5 / M2 — USD 4,000 after acceptance: conduct Rocket Pool-specific analysis and deliver the complete 15–20-page English draft with citations, information dates and limitations.

Weeks 6–7: perform internal factual/editorial checks, resolve material review comments and prepare the full Korean translation.

Week 8 / M3 — USD 4,000 after acceptance: publish final English and Korean versions, issue brief summaries through the existing company X/Telegram channels and post the completion update.

Progress will be reported publicly at least monthly and at milestone delivery. Draft links can be supplied to the GMC for acceptance review; final links will be public.

How is the work being tested? Is testing included in the schedule?

Report quality control is included in weeks 1–2 and 6–7. We will check material factual claims against primary sources, distinguish deployment status from proposed changes, check calculations if any are used, and verify English/Korean consistency. Any quantitative figure will include its source and observation date. Material evidence gaps will be identified rather than filled with assumptions.

The GMC will receive milestone artifacts for review, and material factual comments will be addressed before final publication. This is document review within the report-production process; no product testing or field research is part of the funded scope.

How will the work be maintained after delivery?

The report will be published as a dated research reference and remain accessible on Four Pillars’ existing publication infrastructure. Corrections to factual or translation errors will follow our normal publishing process. Future protocol developments will be identified as outside the report’s information cutoff; there is no ongoing monitoring service or recurring operational budget in this request.

Costs

What is the acceptance criteria?

Acceptance is based on inspectable publication artifacts:

1. M1: an annotated Rocket Pool-specific outline and public-source framework, including clear separation from existing work and other grant proposals.
2. M2: one complete original English draft of 15–20 substantive pages covering rETH, Megapools, decentralized-staking trade-offs and clearly labeled upgrade status.
3. M3: the final English report and full Korean edition, with source references, information dates, limitations and CC BY 4.0 notices for original funded material.
4. Brief publication-summary links from the existing company X/Telegram channels and a public completion update with actual expenditure.
5. A short account of material factual/editorial revisions.

The report should improve readers’ ability to understand and evaluate the protocol. Approval is not tied to a guaranteed audience count, token price or increase in rETH deposits.

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

USD 10,000 total over eight weeks, paid only after acceptance of the corresponding milestone:

• M1, end of week 2: USD 2,000 equivalent.
• M2, end of week 5: USD 4,000 equivalent.
• M3, end of week 8: USD 4,000 equivalent.

No upfront payment is requested. Disbursement asset and conversion treatment will follow the terms agreed with the GMC.

Itemized proposed budget:

Item	USD
Rocket Pool research, analysis and English drafting	6,000
Full Korean translation and editing	2,500
Internal factual and editorial review	800
Report layout, publication and short distribution summaries	500
Research and publication tools	200
Total	10,000

These are proposed project allocations, not established corporate salary/hourly rates or a statement of the program’s funding entitlement. The project will report actual expenditure and will not duplicate charges across grants.

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

Grant recipient: Four Pillars (grant applicant; contact Steve Kim)
Ethereum receiving address: 0x94B1a533d927eC4c608890341Ef6a6846A9e5c04

The applicant has designated this receiving address for the grant. We understand that the GMC sends grants directly to a recipient address and cannot accept invoices.

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

At each milestone we will post a brief status update and provide the outline/source framework, complete English draft, or final bilingual publication links, as applicable. The GMC can compare those artifacts with the agreed outline, page scope, milestone dates and acceptance criteria.

The final update will include report links, license notices, links to the normal publication summaries, completion status and actual expenditure. Report distribution can be evidenced by links; follower counts are contextual audience evidence rather than performance guarantees.

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

The proposal uses a single focused report, a complete translation and existing publication/distribution channels. Public primary sources and existing company publishing infrastructure keep acquisition and publication costs modest. Source review, internal editorial checks and translation share one controlled report outline, while each funded task is allocated once.

The grant pays for incremental Rocket Pool-specific research and publication. Existing articles are not billed as new work, and the budget contains no recurring service, event or software-infrastructure allocation.

Have you already been compensated by the RP protocol in any way for this work?

No. The applicant confirms that Four Pillars has not received prior Rocket Pool compensation, paid contracts or grants for this work.

The separate prior grants from dYdX, Solana and Blur disclosed above are not being represented as Rocket Pool compensation.

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

Four Pillars is a commercial research organization and would be paid for delivering this report. Prior non-Rocket Pool grants and separate grant applications/proposals are disclosed above.

The applicant confirms no relevant conflict of interest, GMC membership or financial relationship, or GMC member’s direct financial benefit from this proposal.

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?

The confirmed grant recipient will receive compensation for accepted work. Four Pillars may also receive the ordinary reputational benefit of publishing research.

The applicant confirms no other relevant financial interests or benefits involving non-Rocket Pool protocols or projects to disclose beyond the grant compensation and ordinary publishing benefit noted above. General public benefit to Ethereum staking readers is not a claim that another protocol will receive a grant-funded service or financial allocation.

[winverseDP]

Name of Grant

Saturn 2 Exit and Bond Impact Model

Applicant: DAOplomats
Technical lead: @winverseDP
Request: $3,600 USD, paid in USDC in two milestones after acceptance
Delivery: Six weeks from approval

What is the work being proposed?

DAOplomats proposes to extend our published minipool exit simulation into a reproducible model of Saturn 2’s exit, bond and withdrawal trade-offs. The aim is to give the pDAO numbers it can use when choosing or revisiting parameters: how much liquidity a rule provides, what it costs remaining rETH holders, and how exits are distributed across node addresses.

Our preliminary work already shows a measurable trade-off. At a 50k rETH net shortfall, commission-first rules wipe 206–251 eligible minipool books, versus about 118 under uniform random selection. They also leave a lower capital-weighted commission on the remaining eligible minipools. We have not yet measured whether alternatives can keep that efficiency while reducing concentrated losses.

The grant funds four extensions:

1. Exit-rule comparison. Extend the data to validator-level megapool state and compare the six candidate megapool criteria discussed in RPIP-71: random, lower RPL stake, FIFO, bond shortfall, larger-node bias, and avoiding repeated hits to the same node. This includes the tournament mechanism, with explicit scoring definitions and sensitivity to tournament size. For minipools, add a node-balanced tie-break within each exact commission tier and a broader node-balanced ordering. Compare all of these with our existing commission and random rules at 10k, 50k and 200k rETH net shortfalls.
2. Bond and reentry analysis. Compare 1.5, 4 and 6 ETH marginal bond scenarios using the full bond curves, including initial requirements and reward-funded top-ups under RPIP-42 and RPIP-83. Report capital requirements, queue clearance under stated inflow paths, reentry effects, and the incremental return from topping up compared with solo staking.
3. Exit-penalty economics. Model the RPIP-80 penalty and re-request schedule together. Compare the cost of non-compliance with additional operating rewards and exit/reentry opportunity costs across bond and commission levels. Report break-even conditions under stated assumptions; we will not infer how operators will actually behave.
4. Mint-and-withdraw incentives. Test the concern that repeated large withdrawals could create costly validator churn. Account for the mint fee, withdrawal buffer, reward treatment of queued rETH, capital lockup, liquidity inflows and exit/entry delays. Compare the baseline with illustrative exit fees and hysteresis settings, reporting actor costs and protocol reward losses separately.

Exit comparisons will report validators selected, credited ETH, nodes touched, eligible books wiped, each node’s fraction of pools removed, top-10 exit share, and associated RPL exposure. Where execution and consensus data establish it, we will also count addresses losing all active Rocket Pool validators across minipools and megapools. Incomplete cases will stay marked unknown, and addresses will not be presented as verified independent operators.

Efficiency comparisons will separate rETH liquidity from returned operator bonds and total validator principal removed, and will distinguish remaining commission from modeled reward losses during queue and reinvestment delays. We will publish the measured trade-off between concentration and efficiency, including results that do not support a proposed alternative.

Is there any related work this builds off of?

Yes. We published preliminary findings in the RPIP-86 discussion, post 35. The snapshot is block 26,127,238 (5 October 2026), with 11,571 eligible minipools across 1,323 node addresses. Already-exiting and withdrawn validators are excluded. The post documents the method, seeds, a second-seed rerun, cap-crossing sensitivity, and 10k and 200k runs.

Preliminary finding	Commission ordering / observed	Random comparison
Commission-homogeneous multi-minipool nodes	72.28%	18.97% shuffled mean
Eligible minipool books wiped, 50k rETH	206.0–250.8 across four tie-breaks	117.6 mean
Top-10 node share of exits, 50k rETH	39.5–43.0%	22.8% mean
Remaining capital-weighted commission	Approximately 10.64%	Approximately 11.68%

The commission difference corresponds to about 3.1 basis points of annual yield at an illustrative 3% gross reward rate. This is a static fee proxy, not a protocol APR forecast. Wiped books are not verified operator departures, and associated RPL is not a forecast of unstaking or selling. At 200k rETH, some commission rules have a lower top-10 share than random, so the result depends on the metric and request size.

This grant pays only for the extensions above. The published baseline is completed work and is not a paid deliverable. The project builds on the Saturn 2 proposals and community discussion; no core-team or GMC endorsement is claimed.

Will the results of this project be entirely open source (MIT), GPL, Apache, CC BY? If not, which parts will not be, why, and under what license will they be published?

Yes, entirely. Python code and tests will be published under MIT, reports and original charts under CC BY 4.0, and original data exports under CC0. Third-party sources keep their original licensing and attribution. License files will be included in the first milestone release. Inspecting the funded analysis will not require any proprietary model or paid subscription.

Benefit

Group	Benefits
Potential rETH holders	Clearer evidence about withdrawal liquidity, queue delays and the costs of alternative designs when evaluating rETH. Adoption growth is not assumed.
rETH holders	Quantifies the reward and capital-efficiency consequences of liquidity exits, including idle-capital costs and withdrawal incentives.
Potential NOs	Shows how bond choices and reentry priority affect required capital and modeled queue access.
NOs	Measures the distribution and severity of exits, surviving megapool validators, top-up economics and penalty incentives.
Community	Reproducible comparisons for Saturn 2 deliberations and later parameter reviews, with assumptions and uncertainty exposed.
RPL holders	Evidence about operator participation and associated RPL exposure. It does not claim to predict RPL sales or price.

This work serves the GMC goal of improving quality of life for the protocol and its community. It informs parameters that affect the experience of node operators and rETH holders, which bears on whether operating a node or holding rETH is attractive.

Which other non-RPL protocols, DAOs, projects, or individuals, would stand to benefit from this grant?

Ethereum staking researchers and other staking protocols can reuse the public methods. DAOplomats gains a reusable research contribution and a public record of delivery. The funded questions and outputs are specific to Rocket Pool. This is not a cross-DAO advocacy campaign.

Work

Who is doing the work?

DAOplomats. @winverseDP is the technical lead and is accountable for data collection, model implementation, validation and publication. Other members of the DAOplomats team contribute to the work. Public contact: Telegram @Win_Verse.

We will invite protocol authors and node operators to challenge assumptions and inspect results on the public forum. Delivery and acceptance do not depend on any particular reviewer volunteering, and no independent reviewer appointment is represented as confirmed.

What is the background of the person(s) doing the work? What experience do they have with such projects in the past?

Winverse’s background includes DAO governance, protocol research, grant-program design and technical communication, including prior work on the RARI Foundation grants framework and playbook, and the Cryptex’s Treasury Strategy Optimization. DAOplomats works on governance across multiple ecosystems.

The most relevant evidence is the Rocket Pool work already published in post 35: a pinned block, randomized comparisons against a stated baseline, a second-seed rerun, cap-crossing sensitivity and multiple request sizes. The GMC can assess this directly.

What is the breakdown of the proposed work, in terms of milestones and/or deadlines?

Milestone	Due from approval	Deliverables	Payment after acceptance
M1: Exit rules and bonds	End of week 3	Extended data and coverage report; minipool alternatives and six defined megapool criteria; 10k/50k/200k comparisons; bond, top-up and queue/reentry scenarios; tests, CSVs, charts and a forum summary.	$1,800
M2: Penalties, withdrawal incentives and release	End of week 6	Penalty break-even analysis; mint-and-withdraw, fee and hysteresis sensitivities; a final data refresh and comparison; integrated decision report; documented refresh commands, release and handoff.	$1,800

We will freeze and record RPIP versions at kickoff, log any model-relevant changes during delivery, and reflect them in the final comparison. The work stays useful for parameter review after the initial votes, and delivery does not depend on any vote still being open.

How is the work being tested? Is testing included in the schedule?

Yes, throughout both milestones:

• Reconcile registries and execution/consensus joins; report missing state, duplicates and exclusions.
• Check exact capital accounting, hard-cap boundaries, and the distinction between gross requests and net shortfalls.
• Use synthetic node layouts to test selection scores, tournament sampling, reentry priority, and full-node versus eligible-book counts.
• Run at least 1,000 draws for each stochastic comparison at each request size, repeat with a second seed, and report empirical 5th–95th percentiles with sensitivity to cap handling and eligibility assumptions.
• Reconstruct a representative extended exit scenario independently in a spreadsheet, and check bond, reward, fee and penalty equations against small hand-calculated cases, including zero-inflow and zero-fee boundaries.

The release will include an offline replay command and automated checks. Queue and incentive results will be conditional scenarios, with parameter ranges and data gaps documented.

How will the work be maintained after delivery?

All deliverables and saved datasets will stay public. The final handoff will document how to collect a new pinned snapshot and regenerate the reports on GitHub. We will correct reproducible defects affecting the delivered scope for 90 days after final acceptance, within this grant. Later feature development, or support for materially changed protocol mechanics, would need a separate scope.

Costs

What is the acceptance criteria?

M1 is accepted when the public release contains the extended data and coverage report, both new minipool alternatives, six explicitly defined megapool criteria using tournament selection, all three withdrawal sizes, and the bond, top-up and reentry comparisons. Each rule must state its scoring, eligibility and capital-accounting assumptions. Tests, per-draw results and reproduction instructions must accompany the report.

M2 is accepted when the penalty and withdrawal-incentive modules publish their equations, parameter grids and break-even results; the refreshed data and integrated report show the efficiency and concentration comparisons; and the release passes its documented checks and offline replay.

For both milestones, every headline number must trace to a saved input and generated output. RPIP versions, blocks, seeds and limitations must be recorded. Unknown validator state, proxy metrics and illustrative alternatives must be labeled. Code and reports must carry the stated licenses. A forum summary and public issue log must accompany each delivery. Acceptance concerns completeness and reproducibility, not a preferred policy conclusion.

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

$3,600 USD, paid in USDC, over six weeks. The two $1,800 payments are requested only after the GMC accepts the corresponding milestone. No upfront payment is requested.

The planning estimate is 100 hours, an effective rate of $36/hour. This is a fixed-price request; the hours explain the estimate and do not create hourly billing.

Work	Estimated hours	Budget
Extended data and exit-rule comparisons	30	$1,080
Bond, top-up and queue/reentry analysis	20	$720
Penalty economics	15	$540
Withdrawal incentives, fees and hysteresis	20	$720
Release validation, reports and scoped support	15	$540
Total	100	$3,600

Routine data-access and compute costs are included. No recurring infrastructure funding is requested.

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

DAOplomats, in USDC on Ethereum mainnet to:

0xEe5A54F83Ef0F983e9173BcCAc7615DBE12a78A0

No invoice is required.

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

Each milestone will have a tagged public release, a completion report mapping artifacts to the acceptance criteria, and a forum update. The GMC can replay the saved inputs, inspect the tests and the spreadsheet check, and reconcile report figures with CSV outputs before payment. Weekly forum updates will show progress and flag any material scope or data issues.

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

We will reuse our existing collection pipeline and simulation rather than charge to rebuild them. Batch scripts, cached snapshots and static reports avoid ongoing hosting. The work concentrates on numerical policy comparisons and excludes production exit automation, Smartnode features, a security audit and a hosted dashboard.

A prose-only review would cost less but would not measure the node-level distribution or identify break-even thresholds. The existing commission-versus-random study is already available at no extra cost. This request pays for the missing comparisons and incentive analysis.

Have you already been compensated by the RP protocol in any way for this work?

No. Neither winverse nor DAOplomats has received compensation of any kind from Rocket Pool or the GMC, and no other grant, client or DAO is funding this work. The milestones exclude the already-published baseline, and the same work will not be charged to another grant or retrospective award.

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 to disclose. No member of the GMC is involved in this work or would benefit financially from it. Neither winverse nor DAOplomats runs a Rocket Pool node or holds RPL or rETH, and neither has a relationship with any GMC member or the Rocket Pool team. DAOplomats takes part in governance in other DAOs; none of those paid roles touches Rocket Pool or rETH, and this grant carries no mandate to promote another protocol.

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?

DAOplomats will receive the grant payments and may benefit reputationally from delivering public research. No other protocol or project in which we have a vested interest will benefit financially. The outputs are free to use, no token or fee is attached, and results will be reported whichever policy comparisons they support.

[ShfRyn]

Notice: This message marks the closing of the forty first (41) round of Rocket Pool grant applications. Any applications submitted after this will not be considered for this round.