Round 37 - GMC Call for Bounty Applications - Deadline is June 7

This thread is for applications for Rocket Pool’s May 7, 2026 - June 7, 2026 bounties. Please only post bounty 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 Round 37 - GMC Community Discussion of Submitted Applications 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 June 7, 2026 at 23:59 (11:59 PM) UTC will be considered. Any bounties posted after that deadline will be carried over to the next award period.

This is the expected schedule for round 37:

  • Application Period (May 7 - June 7)
  • Scoring Deadline (June 23)
  • Final Voting Amendments, Discussion and Finalization (June 24 - June 27)
  • Award Announcement (June 28)
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 built 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.

Bounties Rubric

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

  • If the bounty is completed successfully, to what extent does it further the GMC goals?

  • To what extent is it likely that the bounty can be feasibly claimed/completed successfully?

  • If the bounty is successfully completed, how large is the benefit to the protocol relative to the size of the proposed costs?

Bounty Proposal Template

Guidelines

  • The goals of the Bounty Proposal are:
    • to communicate your bounty idea clearly, in general terms, such that the GMC can decide if it’s worth pursuing.
    • to estimate the benefits and costs attached to your proposal.
    • to disclose any relevant conflicts of interest.
  • Answers to the template questions do not need to be highly detailed. Estimates or ranges are acceptable. Brief answers are also fine.

Template

# Bounty Name

## General Information

### What is the nature of the proposed bounty?

### Why are you writing this bounty proposal?


## Benefit

<please enter N/A where appropriate>

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

### Which other non-RPL protocols, DAOs, projects, or individuals would stand to benefit from the bounty being successfully completed?



## Work

### What steps would be entailed in completing the bounty? Do successful examples of such work exist elsewhere? What skillsets or knowledge will be required?

### What advice would you give a bounty hunter working on this bounty?

### Should the output of this bounty be available under an open source license?



## Costs

### How much do you think the completion of this bounty worth to Rocket Pool (in USD)?

### How much work will be needed to verify this bounty has been completed? What skillsets or knowledge will be required?


## Structure

### How would you structure this bounty, and why? 
* A single payout to single team on completion? 
* Divided into milestones? 
* Multiple payouts to multiple teams? 
* Should this be written up as multiple bounty definitions?
* Something else?

### Is this bounty repeatable?

### Are there any reasonable circumstances under which this bounty should be withdrawn? Should it expire?


## Conflicts of Interest

### Does the person or persons proposing the bounty 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 successful completion of the bounty).

### Will the applicant, or any protocol or project in which the applicant has a vested interest (other than Rocket Pool), benefit financially if the bounty is successfully completed?

Bounty Definition Template

Guidelines

  • When a single proposal bounty proposal has parts that must be completed by different groups, it should become multiple definitions.
  • Where reasonably possible, bountiy definitions should limit the number of distinct skillsets required for completion of the bounty.
  • Bounties should be defined in terms of the smallest worthwhile unit of work. IE: $25 to add/update a single relevant FAQ question rather than $5,000 to update the FAQ.
  • Include any information or resources that might reasonably help a bounty hunter complete the bounty.
  • Think carefully about which tasks are required, and which can be optional.
  • Clearly list any dependencies, if the bounty cannot be completed in all circumstances.
  • Only include multiple milestones for large bounties with natural points of division.

Template

# Bounty Name 

## Data
* Repeatable?
* Expiring?
* Skillsets for completion? (See existing bounties and reuse where possible, new skillsets are recommended if sufficiently distinct)
* Relevant tags? (See existing bounties and reuse where possible, new tags are recommended if sufficiently distinct)
* Min reward (USD)?
* Max reward (USD)?
* Any linked definitions? (e.g. if a single bounty proposal becomes multiple definitions.)
* Any dependencies? 

## Summary 
Short 1-3 sentences describing the bounty.

## Dependencies
Is there anything that must happen (outside of a bounty hunter's control) before it is possible to complete this bounty? This may be other bounties that must be completed first, an upcoming event or change or a regular occurance that triggers a valid bounty. This section is optional. May be later removed from the definition if the dependency becomes permanently met. 

## Required Milestones
What _must_ be completed for a bounty hunter to claim some amount of bounty. Described per milestone.

### Milestone A - <Name of Milestone>
**Payout: ** <payout amount>
Clear bulleted list or subheadings covering the items that must be completed and/or adhered to for this milestone to be valid.

### Milestone B - <Name of Milestone>
**Payout: ** <payout amount>
Clear bulleted list or subheadings covering the items that must be completed and/or adhered to for this milestone to be valid.

### Milestone C - <Name of Milestone>...

## Optional Milestones
What tasks _may_ be completed for a bounty hunter to earn extra bounty rewards. Described per milestone. This section is optional.

Optional milestones may be less strictly defined than required milestones. You may aggregate multiple minor considerations that would contribute to a payout. 

### Milestone D - <Name of Milestone>
**Maximum Payout: ** <maximum payout amount>
Clear bulleted list of the items that would contribute to payout for this milestone.

### Milestone E - <Name of Milestone>...


## Further Notes
Anything you think that would be beneficial for a bounty hunter to know when working on this bounty. Maybe be divided into subsections as needed.

## Resources
Links to repositories, web pages, forum discussions, etc. Anything that the bounty hunter may be able to use to do a better job on the bounty work. 

## Contacts
Individuals that have agreed to act as contacts for this bounty. Include usernames + contact details for any platform on which the contact is willing to respond to requests. Any contacts are expected to fully understand the bounty definition. This section is optional. 

Contacts:
* MAY be eligible for incentives.
* SHOULD NOT assist the bounty hunter directly with the bounty work.
* SHOULD assist bounty hunters via feedback, direction and oversight upon request.

## Verification
Who is expected to verify that the work delivered meets the relevant milestones? This person or group must have agreed to do this in advance of this definition being published. This person or group should have any relevant skillsets needed to properly verify the bounty work.


1 Like

Independent Tokenomic Health Report — Rocket Pool Comparative Analysis

Data

  • Repeatable? Yes — can be repeated quarterly or after major protocol upgrades (e.g., Saturn)
  • Expiring? Yes — expires 6 months after award. Data-dependent analysis loses relevance if not completed promptly.
  • Skillsets for completion? Tokenomic analysis, DeFi protocol economics, technical writing, quantitative benchmarking
  • Relevant tags? research, community, rETH-advocacy
  • Min reward (USD)? $2,000
  • Max reward (USD)? $3,500
  • Any linked definitions? No
  • Any dependencies? No

Summary

An independent, data-driven tokenomic health assessment of Rocket Pool (RPL + rETH), benchmarked against comparable liquid staking protocols using a standardized 25-framework scoring methodology. The report produces two deliverables: (1) a standalone comparative analysis covering RPL demand architecture, supply dynamics, operator economics post-4-ETH bond reduction, and rETH liquidity profile, and (2) a one-page rETH collateral profile formatted for direct submission to DeFi lending governance forums (Aave, Morpho, Spark) when advocating for rETH parameter improvements.

Dependencies

None. All data sources are publicly available on-chain and through protocol dashboards.

Required Milestones

Milestone A — Core Tokenomic Health Report

Payout: $1,500 - $2,500

  • Full tokenomic assessment of Rocket Pool covering:
    • RPL demand architecture: Structural demand from mandatory operator bonding, demand curve dynamics post-4-ETH bond reduction, effective utilization of fixed supply
    • Supply dynamics: 20M RPL cap, 5% annual inflation analysis, inflation-to-security conversion efficiency
    • Operator economics: Capital efficiency at 4-ETH bond vs. prior 8-ETH and 16-ETH tiers, effective yield comparison, operator pool accessibility analysis
    • rETH liquidity profile: Current pool depth quantification, redemption throughput capacity, composability constraints from post-Balancer hack liquidity levels
    • Stakeholder alignment: How rETH holders, node operators, and RPL holders interact economically — whether incentives reinforce or conflict
  • Comparative benchmarks against Lido (stETH) and at minimum one additional LST protocol, scored using identical methodology across all dimensions
  • Scoring methodology must be explicit, reproducible, and documented — not opinion-based rankings
  • Published as open-source markdown + PDF under CC-BY 4.0 or equivalent open license
  • Hosted publicly (e.g., GitHub, dedicated project site) with permanent URL

Milestone B — rETH Governance Advocacy Toolkit

Payout: $500 - $1,000

  • One-page “rETH Collateral Profile” document containing:
    • Liquidity depth metrics (current pool sizes, historical trend, slippage estimates at various trade sizes)
    • Redemption throughput analysis (how much rETH can be redeemed to ETH under stress without material price impact)
    • Decentralization metrics (operator count, geographic distribution, infrastructure diversity)
    • Operator distribution data (bond concentration, minipool distribution)
    • Comparative positioning vs. stETH and other LSTs on the same metrics
  • Formatted for direct copy-paste submission to DeFi lending protocol governance forums
  • Must be usable by any Rocket Pool community member — no specialized knowledge required to submit it
  • Includes a brief (2-3 paragraph) template cover letter that community members can adapt when submitting to specific protocol governance forums

Optional Milestones

Milestone C — Saturn Upgrade Impact Addendum

Maximum Payout: $1,000

  • Post-Saturn analysis documenting how the upgrade changes the tokenomic fundamentals from Milestone A
  • Specifically addresses: whether mandatory RPL bonding is preserved across all operator tiers, changes to commission structures, impact on RPL demand architecture score
  • Must be completed within 60 days of Saturn mainnet deployment
  • Published as an addendum to the Milestone A report under the same license

Milestone D — Contagion and Dependency Mapping

Maximum Payout: $500

  • Analysis of rETH’s exposure to external protocol dependencies:
    • Balancer V3 boosted pool architecture — percentage of rETH/ETH liquidity routed through Aave, and what happens if Aave freezes the relevant market
    • Cross-protocol contagion channels (e.g., rsETH/Kelp-type events that spike borrowing rates affecting boosted pools)
    • Quantified risk assessment with historical precedent (April 2026 Kelp incident as case study)
  • Can be integrated into the Milestone A report or published as a standalone supplement

Further Notes

Why This Analysis Exists

Rocket Pool’s tokenomic design is one of the strongest in DeFi — mandatory RPL bonding creates genuine structural demand that scales with protocol growth, pDAO governance has no admin keys, and the fair launch with no premine set the standard. These properties matter, but they’re currently documented in scattered forum posts, community discussions, and protocol docs rather than in a single, rigorous, independently-authored reference.

The 4-ETH bond reduction, ongoing liquidity recovery from the Balancer hack, and the approaching Saturn upgrade create a window where the community benefits from having a clear-eyed baseline assessment. The comparative lens against Lido and other LSTs provides context that protocol-native documentation cannot — it answers “how does Rocket Pool stack up?” with data, not conviction.

Methodology Context

The scoring framework used for this analysis evaluates protocols across 25 dimensions including stakeholder architecture, demand architecture, supply mechanics, governance structure, distribution fairness, health metrics, and contagion exposure. The same framework has been applied to 34 DeFi protocols across 10 categories. Rocket Pool currently scores 72.20/100 (classified: SAFE, #1 in Liquid Staking). Lido scores 49.21 (classified: EXTRACTIVE). These scores and the full methodology will be published alongside the report.

Practical Value

The rETH Governance Advocacy Toolkit (Milestone B) is designed for a specific use case: when Rocket Pool community members engage with lending protocol governance to advocate for rETH listings, supply cap increases, or LTV parameter improvements. Aave, Morpho, and Spark all use liquidity depth, decentralization metrics, and redemption throughput as inputs to their risk parameter decisions. A standardized, data-backed document reduces the effort required for each submission and increases the credibility of each ask.

Resources

  • Rocket Pool documentation
  • Rocket Pool governance forum
  • RPL tokenomics overview
  • Rocketscan (protocol analytics)
  • Tokedex project site (existing framework): https://tokedex.org
  • Prior applied analysis — Reserve Protocol rETH forum submission
  • ENSIP-26 Agent Text Records (context for broader ecosystem)

Contacts

  • Robert Greenfield IV — Author of Tokédex, CPO @ Bluprynt, Fmr Head of ConsenSys Social Impact, Fmr. Blockchain Observatory Expert Panel member. Twitter/X: @robtg4

Verification

The GMC or a designated community reviewer with familiarity in DeFi tokenomics and liquid staking protocol economics. Verification should confirm:

  • Milestone A: Report covers all specified dimensions, comparative benchmarks use consistent methodology, data sources are cited, analysis is published under open license at a permanent URL
  • Milestone B: Document is formatted for governance forum submission, metrics are current and sourced, template cover letter is included, a non-technical community member can use it without modification
  • Optional milestones: Addendum addresses specified questions with data, published within stated timeframes

Notice: This message marks the closing of the thirty-seventh (37) round of Rocket Pool bounty applications. Any applications submitted after this will not be considered for this round.