Round 38 - GMC Call for Bounty Applications - Deadline is July 7

Grants / Bounties
,
1

This thread is for applications for Rocket Pool’s June 7, 2026 - July 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 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 July 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 38:

  • Application Period (June 7 - July 7)
  • Scoring Deadline (July 21)
  • Final Voting Amendments, Discussion and Finalization (July 22 - July 25)
  • Award Announcement (July 26)
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.

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 is 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 a 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 bounty proposal has parts that must be completed by different groups, it should become multiple definitions.
  • Where reasonably possible, bounty 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 occurrence that triggers a valid bounty. This section is optional. It may later be 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 would be beneficial for a bounty hunter to know when working on this bounty. May 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.
2

Support Payments #8

Data

  • Repeatable? Yes
  • Expiring? Yes
  • Skillsets for completion? knowledge of protocol and tooling, general computering
  • Relevant tags? #support?
  • Min reward (USD)? $0
  • Max reward (USD)? $7,500
  • Any linked definitions? Nope
  • Any dependencies? Nope

Summary

Provide support for questions posed by Rocket Pool community members in the #support discord channel. This is a continuation of the previously approved Support Payments #7 in gmc_round_36.

Required Milestones

Provide user support in the #support channel of discord, under the following terms:

  1. Provide at least 1 hour of work providing #support discord channel in EACH of the three months July 2026 - September 2026, as measured by RocketScrape; alternatively provide 15 hours TOTAL over the 3 month block.
  2. Total payout of the bounty is min((Total Hours / 135), 1) × $7,500
  3. The payout will be split proportionally amongst all awardees based on time spent as measured by RocketScrape and adjustments based on investigation (see Verification); payment will be done during the next GMC distribution phase. Should an awardee forfeit their reward, it will be split proportionally among the other eligible participants.

Resources

Contacts

@haloooloolo on Discord

Verification

Multiple previous recipients have generally run RocketScrape independently at the end of the period to reach consensus on final participation numbers. This includes @leighm.eth, @Steely and @haloooloolo. This should be sufficient as it is in everyone’s best interest to not understate their own numbers and not let someone else overstate theirs.

  1. Within the first 3 days after a 3 month block ends, a list of all potential awardees will be produced by GMC.
  2. A 10-day period will follow where any community member can publicly or privately notify the GMC that a potential awardee was not providing support (for example, was requesting support) or not providing quality support (for example, multiple ineffective messages/farming). Anyone offering support can also petition for a name to be added to the list if they narrowly failed the initial inclusion criteria and can be included on a case-by-case basis. Community members may also advocate for inclusion of participants that do not strictly meet all the bounty criteria.
  3. The GMC will investigate the #support record of any questioned potential awardee and weight contributions either 0%, 50%, or 100% based on posts in the #support channel. The 50% level will be for users with approximately 25%-75% effective support messages. Potential awardees receiving 0% or 50% will be considered 0% or 50% for future #support bounties unless they specifically request and are granted re-evaluation.
3

rp-ledger: rETH Cost-Basis & Accounting Export CLI

General Information

What is the nature of the proposed bounty?

A standalone, open-source CLI tool (rp-ledger) that pulls a wallet’s rETH transfer history and the historical rETH/ETH exchange rate on-chain, and generates a cost-basis / gains report (CSV and JSON export) for tax and accounting purposes. Currently, rETH holders who want this kind of reporting generally rely on third-party paid tax-software integrations or manual spreadsheet work, this closes that gap with a free, open-source, purpose-built tool.

Why are you writing this bounty proposal?

This is a well-scoped, generically-skilled task (on-chain data fetching + report generation) that doesn’t require deep Rocket Pool-specific insider knowledge to complete well, making it a good fit for the open bounty model rather than a grant. I may also attempt to claim this bounty myself (disclosed below), but it’s structured so any capable developer could pick it up.

Benefit

Group Benefits
Potential rETH holders Removes a real practical barrier (tax/accounting complexity) to holding rETH long-term, making it more attractive to start.
rETH holders Free, open-source tool for ongoing cost-basis tracking and tax reporting, reducing reliance on third-party paid services.
Potential NOs N/A
NOs N/A — this tool is holder-facing rather than operator-facing.
Community Adds to the ecosystem of open-source rETH tooling; documentation and code can be reused/extended by others (e.g., integrated into wallets or dashboards).
RPL holders Indirectly supports rETH adoption and retention, which supports overall protocol usage and health.

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

Any liquid staking token holder facing similar cost-basis/tax reporting needs could adapt the underlying pattern (on-chain exchange-rate history + transfer parsing). Portfolio trackers, tax-software integrations, and wallet dashboards could potentially integrate the output format directly.

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?

Steps:

  1. Pull historical rETH/ETH exchange rate data from on-chain sources (the rETH contract exposes exchange rate at any block/time).
  2. Pull a given wallet address’s rETH transfer history (mints, transfers, burns) from on-chain data or an indexer/RPC.
  3. Compute cost basis and realized/unrealized gains per transaction, using standard accounting methods (e.g., FIFO).
  4. Export a clean CSV and JSON report.

Similar tools exist for general crypto tax reporting (e.g., Koinly, CoinTracker) but none are open-source and purpose-built for rETH’s specific exchange-rate mechanic. Required skillsets: comfortable working with an Ethereum RPC/indexer (e.g., via ethers-rs, web3.py, or similar), basic accounting logic (FIFO cost basis), and CLI tool development in any language (Rust preferred for consistency with other RP tooling, but not required).

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

Start by confirming the exact on-chain method for retrieving historical rETH exchange rate (checking the rETH contract’s getExchangeRate() function history via block queries or a subgraph, if one exists for Rocket Pool). Keep the scope to single-wallet, single-network inputs first ; multi-wallet/multi-chain support can be a stretch goal but isn’t required for the core bounty.

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

Yes, MIT or similar permissive license.

Costs

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

$2,500 — reflecting a well-scoped, moderate-complexity CLI tool (on-chain data fetching, accounting logic, report export) achievable by a competent developer in roughly 1-2 weeks of focused work.

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

Verification should be straightforward: run the tool against a known wallet address with a known transaction history, confirm the exchange-rate data and cost-basis calculations are accurate, and confirm CSV/JSON output is well-formed and usable. Requires someone familiar with rETH’s exchange-rate mechanic and basic accounting concepts to sanity-check the output , roughly 1-2 hours of review.

Structure

How would you structure this bounty, and why?

A single payout to a single team/individual on completion, since the scope is small enough that splitting into milestones would add more overhead than value. First submission that meets the acceptance criteria (working tool, verified against a test wallet, open-source release) claims the bounty.

Is this bounty repeatable?

No — a single canonical tool is the goal, not a repeatable/recurring task. Future feature extensions (multi-chain support, integration with a specific tax platform’s export format) could be proposed as separate follow-on bounties or grants later.

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

Yes — if no submission is received within a reasonable window (e.g., 2-3 months) or if the GMC identifies that an existing third-party tool already adequately serves this need, the bounty should be withdrawn or reconsidered.

Conflicts of Interest

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

I (Mahmud Bello, GitHub: mahmudsudo) am proposing this bounty and may also attempt to claim it myself. I am not a member of the GMC.

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?

Only insofar as I may claim the bounty payout myself if I complete the work, consistent with the open, first-to-complete nature of the bounty structure.

4

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