Round 13 (May 7 - Jun 7) Grants / Bounties / Retrospective Awards Results)

Grants / Bounties
,
1

The GMC has concluded discussions and scoring for the Round 13 (May 7 - June 7) Grants/Bounties/RA Award Round.

This post also begins the fourteen-day clock during which, according to RPIP-15, “[a]nyone MAY file an RPIP disputing a grant, bounty, or retrospective award within two weeks of the announcement of recipients. Such an RPIP SHALL be subject to a snapshot vote.” Any awards not subject to such a challenge will become official on July 12, 2024 at 23:59 UTC.

This round, all applications were deliberated by all subcommittees. This was due to the importance of the tokenomics and RocketLend applications that take up most of the slate and called for much back-and-forth discussion.

The GMC had live threads recording member feedback and came together for a discussion call to resolve specific disagreements.

The GMC is allocating $300,000 from the treasury to support the Rocket Pool tokenomics rework. They want to recognize the contributors thus far and encourage more community participation to help shape the future of the protocol.

Current GMC Roster
  • Ken
  • Waq
  • dondo
  • rplmaxi
  • rocknet
  • LFO
  • epineph
  • Dr Doofus
  • Destroyaaa
Application Breakdown
  • Total Grant Applications: 8
  • Total Bounty Applications: 1
  • Total Retro Applications: 3
  • Total Applications Transferred From Last Round: 1
  • Total Amount Grants Requested: $480,000
  • Total Amount Bounties Requested: $100,000
  • Total Amount Retros Requested: $127,065
  • Total Amount Grants / Bounties / Retros Requested: $707,065
  • Total Amount Incoming Funds This Period: $90,000
  • Total Amount Reserves: $1,300,000
Awards, Average Overall Scores
Number Applicant Title Decision Amount (USD)
GA132402 ShfRyn Tokenomics Rework Grant (Core Contributors) Approve $125,000.00
GA132403 ShfRyn Tokenomics Rework Grant (Other Contributors) Approve $50,000.00
RA132401 ShfRyn Tokenomics Rework Retro Approve $125,000.00
RA132402 Patches Patches “optimistic work” prior to May 12 Approve $5,800.00
RA132403 Valdorff Contract Verification w/ Guides Approve $2,500.00
RA132404 Leighm.eth May 2024 Support Hours Approve $765.00
GA132405 ramana Rocketlend Defer w/ Future Consideration
BA112402 LFW Release Process RPIPs Decline
GA132404 shudog2162 RocketPool & Gitcoin: Grants For Growth Decline
GA132407 Unitap Unitap Videos Decline
GA132401 ShfRyn Expand Non-Custodial Grant (BA082402) By One Team Withdrawn
Detailed Award Results

Name: Tokenomics Rework Grant (Core Contributors)
Proposer: ShfRyn
Type: Grant
Subcommittee: All
Link to Application: Round 13 - Call For Grant Applications - Deadline is June 7 - #3 by ShfRyn
Decision: Approve
Requested Funding: $150,000
Awarded Funding: $125,000
Score: 4.94
Comments: The GMC has approved the proposal at a revised amount, recognizing it as a critical investment for the protocol. They have reduced milestone B to $50k, down from $75k, and will be awarding milestone A at the full amount of $75k. Acceptance criteria will be defined as “RPIPs reach snapshot voting” to ensure clarity and avoid any misunderstandings. Distribution will be managed by core participants, and the administrator will help facilitate. The GMC will support ongoing discussions to potentially amend this grant as needed.
Payment Structure: $75k upon completion of milestone A. $50k upon completion of milestone B. At the culmination of the project, core contributors will stack rank each other on skill level / technical ability, productivity / output, group contribution, and product contribution to determine compensation.

–

Name: Tokenomics Rework Grant (Other Contributors)
Proposer: ShfRyn
Type: Grant
Subcommittee: All
Link to Application: Round 13 - Call For Grant Applications - Deadline is June 7 - #4 by ShfRyn
Decision: Approve
Requested Funding: $100,000
Awarded Funding: $50,000
Score: 4.94
Comments: The GMC has approved this proposal, recognizing it as important work that complements the core contributors. The funding amount has been adjusted to $50k, as the tier system is unlikely to reach $100k. This adjustment provides a more accurate estimate of the total payout. The acceptance criteria will be defined as “RPIPs reach snapshot voting” to ensure clarity and avoid any misunderstandings. Distribution criteria, though imperfect, have been effective in the past and the addition of a survey will provide an extra layer of oversight.
Payment Structure: The project will receive up to $25,000 upon completing Milestone A and an additional $25,000 upon completing Milestone B. The compensation for contributors will be categorized into preset tiers established by the GMC: Tier 1 receives $4,000, Tier 2 receives $2,000, Tier 3 receives $1,000, Tier 4 receives $500, and Tier 5 receives $100. The placement of contributors into these tiers will be determined based on a combination of Rocket Scrape data analysis and private feedback surveys from core contributors.

–

Name: Tokenomics Rework Retro
Proposer: ShfRyn
Type: Retrospective Award
Subcommittee: All
Link to Application: Round 13 - GMC Call for Retrospective Applications - Deadline is June 7 - #3 by ShfRyn
Decision: Approve
Requested Funding: $80,000 - $100,000
Awarded Funding: $125,000
Score: 5
Comments: The GMC is approving this proposal at a revised amount of $125k, recognizing it as crucial work that deserves funding for its contributions. The acceptance criteria will be “RPIPs reach snapshot voting” to ensure clarity and avoid any appearance of paying for influence. The GMC acknowledges the significant risk taken and the foundational work done to guide the DAO towards necessary changes.
Payment Structure: Split will be determined by compiling peer review data. Top 10 members from Rocket Scrape data will be polled on their opinion of each other member’s contributions. If available, the content of the peer review questions will be verified by knoshua and LFW to ensure efficiency. Members with higher scores will receive higher splits proportionally. The GMC has the ability to amend the compensation process if new information is brought to light by contributors.
–

Name: Patches “optimistic work” prior to May 12
Proposer: Patches
Type: Retrospective Award
Subcommittee: All
Link to Application: Round 13 - GMC Call for Retrospective Applications - Deadline is June 7 - #2 by Patches
Decision: Approve
Requested Funding: $5,800
Awarded Funding: $5,800
Score: 4.63
Comments: The GMC recognizes the valuable and necessary work being done, particularly in automated testing. The work hours are reasonable, and Patches’ past contributions before the team-support grant justify this payment. While there is a preference for WIP code to be open source and some curiosity about Kurtosis, the overall consensus is positive. The GMC is trusting the judgement of committee members who have a better grasp of the technical details, and their support solidifies their decision.

–

Name: Contract Verification w/ Guides
Proposer: Valdorff
Recipieint: peteris
Type: Retrospective Award
Subcommittee: All
Link to Application: Round 13 - GMC Call for Retrospective Applications - Deadline is June 7 - #4 by Valdorff
Decision: Approve
Requested Funding: $2,000 - $2,500
Awarded Funding: $2,500
Score: 4.63
Comments: The GMC has decided to approve funding for Peteris’ verification work, recognizing it as a critical and valuable contribution to the contract upgrade process. This important step ensures thorough checks and separation from the team, which the pDAO should appropriately compensate. While some concerns were raised about the cost, the infrequency of these verifications makes the expense justifiable. In the future, we may consider creating bounties to better manage fund allocation. Overall, this work is essential, and we want to encourage and support those stepping up to perform it.

–

Name: May 2024 Support Hours
Proposer: Leighm.eth
Type: Retrospective Award
Subcommittee: All
Link to Application: Round 13 - GMC Call for Retrospective Applications - Deadline is June 7 - #5 by leighm.eth
Decision: Approve
Requested Funding: $765
Awarded Funding: $765
Score: 4.88
Comments: The GMC recognizes Leighm.eth is a highly valuable contributor.

–

Name: Rocketlend
Proposer: ramana
Type: Grant
Subcommittee: All
Link to Application: Round 13 - Call For Grant Applications - Deadline is June 7 - #6 by ramana
Decision: Defer w/ Future Consideration
Requested Funding: $90,000
Score: 3.33
Comments: The GMC has decided to defer the application and requests the applicant to provide more evidence to justify the cost. Specific concerns include the relationship between RocketLend, ETH-only minipools, and NodeSet, as well as the current appetite for borrowing following recent liquidations. Clarification on the necessity and justification of the fee, potential revenue models for the GMC/pDAO, and detailed loan terms are also needed. There is uncertainty about the project’s impact on TVL and UX, with insufficient evidence of demand. If no significant new information is provided in the next round, the application may be declined, and we recommend those who support it consider funding it independently. We also suggest discussing a potential audit at a lower cost and exploring alternative funding models. Specifically the GMC would like the applicant to submit the following for review:

  • Clear audit price
  • Identification of a committed project manager
  • Detailed fee structure

–

Name: Release Process RPIPs
Proposer: LFW
Type: Bounty
Subcommittee: All
Link to Application: Round 11 - Call For Bounty Applications - Deadline is April 7 - #3 by LongForWisdom
Decision: Decline
Requested Funding: $100,000
Score: 2.43
Comments: At this time, the GMC has declined the proposal due to current prioritization of tokenomics and timing concerns. We recommend reapplying after Saturn and suggest breaking the project into smaller, manageable parts for future consideration. Additionally, the GMC believes it would be beneficial to conduct robust disaster scenario planning to ensure protocol continuity. One member suggested a smaller scope; funding some introductory research beforehand to create the scaffolding for a revamp.

–

Name: Gitcoin Grants For Growth
Proposer: shudog2162
Type: Grant
Subcommittee: All
Link to Application: Round 13 - Call For Grant Applications - Deadline is June 7 - #5 by shudog2162
Decision: Decline
Requested Funding: $100,000
Score: 1
Comments: The GMC has decided to decline the application. We believe it is unnecessary and offers no real benefit, as we are already conducting retroactive funding. Adding this proposal would result in additional costs and redundancies. Given our current priorities and the lack of unique advantages, we find no justification for approving this funding.

–

Name: Unitap Videos
Proposer: Unitap
Type: Grant
Subcommittee: All
Link to Application: Round 13 - Call For Grant Applications - Deadline is June 7 - #7 by Cotab3
Decision: Decline
Requested Funding: $18,000
Score: 2.125
Comments: The GMC has decided to decline the application. We believe our current focus should be on making existing content more discoverable rather than producing new educational materials. We have had mixed success with similar marketing efforts in the past and already have sufficient onboarding training opportunities. While additional marketing may be relevant closer to the new tokenomics launch or after Saturn, it is not a priority at this time. Therefore, we find no specific need to fund this proposal right now.

–

Name: Expand Non-Custodial Grant (BA082402) By One Team
Proposer: ShfRyn
Type: Grant
Subcommittee: All
Link to Application: Round 13 - Call For Grant Applications - Deadline is June 7 - #2 by ShfRyn
Decision: Withdrawn
Requested Funding: $40,000
Score: N/A
Comments: This grant was withdrawn by the applicant on 6/15/2024.

Bounties That Need Definitions

GMC is requesting support writing a definition for the DAO Engagement Discussion bounty.

Member Participation

All members were present in the discussions and submitted their decisions and feedback.

Final Voting Stages

No amendments were declared and no members chose to reject the slate of awards.

3 Likes
2

Some more comments on the tokenomics-related grants and retros. Apologies to keep going on about these.

‘RPIPs reach snapshot voting’ unfortunately may not be very clear. There are discussions currently about having both an indicitive vote on direction, and locking down the specifications much later. If we go this route, when would Milestone A and B be considered complete?

To reiterate on stack rank, this version is a mechanism designed to set salary and compensation within Valve. It doesn’t fit 1-to-1 with what we’re doing here, its meant to measure the value of permanent employees. Like, quoting from the handbook: ‘By choosing these categories and basing the stack ranking on them, the company is explicitly stating, “This is what is valuable.”’ ie, these categories and descriptions were chosen intentionally based on Valve’s goals.

We have a different working environment and different goals, and I haven’t seen evidence we’ve made an intentional choice here, it looks like we’ve just adopted something without spending too much thought to how it maps to our situation.

It also ranks relative rather than absolute contributions, if everyone provides roughly the same rankings, but agrees there is not much in it, that will return very skewed compensation towards the higher ranks.

Why have we split this into a retro and a grant when the payout criteria is the same?

My assumption (possibly false) was that the intention was to distribute some value asap to those involved to recognize the significant effort that has already taken place.

Secondly, if this does match the same milestones as the grant, why is the distribution mechanism different to the grant? Peer reviewed questions versus Valve’s version of stack rank.

This just all seems very confusing to administer. Are we supposed to take into account retro-covered work in the stack rank answers? Because inevitably that will happen. Is there a specific date cut-off before which we are awarding with a retro, and after which we are rewarding with the grant?

I do want to again protest at structure of compensation for core contributors versus other contributors as well.

With the initial Core set and for milestone A, assuming an even divide for simplicity we have 15k. And then grants for other contributors max out at 4k.

So, the method for someone that’s provided more than 4k worth of value is to add them to the core set and reduce the payout of the core contributors by at least 4k… even if there is budget within the other contributors grant remaining. And the current core contributors need to choose to do this.

I agree with the people that have comments that the core contributors aren’t dicks, and would do this for people where it made sense to do so. But it doesn’t change the fact that there are just bizarre incentives with this structure.

Maybe I’m just missing some context and explanation for why the GMC has chosen these mechanisms? Like is there an intent that’s not come through well that I’m missing?

1 Like
3

Are you under the impression that a) the indicative vote and b) the locking down of specs are more efficiently constructed milestones based on work involved and time of delivery?

We have a different working environment and different goals, and I haven’t seen evidence we’ve made an intentional choice here, it looks like we’ve just adopted something without spending too much thought to how it maps to our situation.

It also ranks relative rather than absolute contributions, if everyone provides roughly the same rankings, but agrees there is not much in it, that will return very skewed compensation towards the higher ranks.

Do you have an alternative proposal? The GMC has left flexibility in: “The GMC will support ongoing discussions to potentially amend this grant as needed.”, recognizing they do not have the same context as the tokenomics contributors, and that any direct suggestions would be helpful.

Why have we split this into a retro and a grant when the payout criteria is the same?

Apologies, that was a clerical error on my part when compiling the commentary. I’ve edited the above. The retro does not require acceptance criteria.

I do want to again protest at structure of compensation for core contributors versus other contributors as well.

So, the method for someone that’s provided more than 4k worth of value is to add them to the core set and reduce the payout of the core contributors by at least 4k… even if there is budget within the other contributors grant remaining. And the current core contributors need to choose to do this.

I assume this could be easily remedied / patched with some supplementary retros if this becomes an issue. However, if you think there’s a way to handle it proactively the GMC can vote on adding that revision.

2 Likes
4

my opinion:

‘RPIPs reach snapshot voting’ unfortunately may not be very clear. There are discussions currently about having both an indicitive vote on direction, and locking down the specifications much later. If we go this route, when would Milestone A and B be considered complete?

This is a reasonable criticism. The previous iteration had something along the lines of “successful passage if milestone A and milestone B” as criteria. My concern was that “paying for passage” would be tipping the hand of the pDAO (like if the leader of a country promised government funds to pay a private group if they secured passage of a referendum…); it immeshes the GMC very deeply into what should be a political choice- a pDAO vote. The pDAO requesting that arrangement would be different (“we will pay you if you convince us to pass this package”). I agree that it needs better clarification, so that the entire bounty can’t be claimed before any additional work is performed.

Why have we split this into a retro and a grant when the payout criteria is the same?

The retro was intended to be a retro for work already completed and available immediately. The GMC will clarify, but presumably the cutoff is sometime between when the application was submitted and approved. Thus the retro is backwards looking, and the distribution for grant is only forward looking.

I do want to again protest at structure of compensation for core contributors versus other contributors as well.

I do not find these incentives to be bizarre. The budget for the core grant is 125k; that is set and if it seems insufficient or oversufficient the pDAO can challenge now. I think that is a reasonable pot given the extent that has already been completed. The core contributors are ultimately responsible for bringing the finished product. The additional 50k for (other contributors) is a supplement to encourage diverse views/eyes/oversight without subtracting from the core’s piece. If the core group feels like an individual needs to be spending 50-100+ hours (to justify well over 4k USD) to bring a finished product, then that individual probably should be added to the core group for coordination purposes. If the core contributors think that a person spending 50-100+ is not efficient (eg, will not decrease the core member hours by 50-100+), then they just have to not add the person to the core and there will be no expectation of a >4k award.

2 Likes
5

Appreciate the responses both. I’m going hard on this because it feels like something concrete I can try to make as smooth as possible for everyone.

Maybe? I’m not sure. I didn’t have specific milestones in mind, I just wanted to raise the concern that this is already looking like it’ll be a bit muddy. I’ve no idea what the timeline for spec lock-down would be, also not sure how much we’d be involved versus the core team.

It does do this to some extent, yes. I’m not sure there’s really a good alternative. You could pay regardless of the vote outcome, but that feels bad for other reasons. You could pay on delivery of the upgrade, but that’s very far in the future. I’m not sure what would be best here. A series of retro’s might be good? A stipend + bonus for delivery by date might be good? We’re approaching the end of this chunk now, so maybe not worth worrying too much about it.

I think I covered it in the discussion thread for this round. My instinct is to trust the core contributors to handle it with minimal drama. So basically:

  • Get everyone to list out what they’ve done.
  • Get everyone in a DM (likely with you ShfRyn to supervise / witness) and discuss.
  • Everyone suggests splits out of 100 and we converge on something everyone is happy with.
  • If we can’t agree, we each enter a split and take the average.

I would also discuss with the others prior and see if this works for them, so far I’ve not brought it up because its tangential to the actual goal. Once we’re at a good place to pause (likely when the forum sentiment vote is up) we can discuss.

Cool. I’m not sure if there is a plan to start the peer review thing soon. From a focus standpoint I’d suggest waiting until we get to a point where we’ve got the forum sentiment vote up. On the other hand, maybe people want to get paid asap. So hard to judge.

I’m a little concerned the cut-off is going to add a bit of complexity. For both peer review questions and stackrank / agreed split, having to consider what someone’s contributed within a specific time period is much harder than what they’ve contributed overall. I can barely keep track of when I did things, let alone track when 5-10 other people did things.

I’m unsure how to best handle this though, I guess we’ll talk it out once we’ve finished current stuff. Might just be a me thing.

I think I covered this in the discussion post. I think the tiers are inflexible and either they should be removed or only used as a starting point, or add additional tiers above 4k. Though to be clear I’m unsure if this is going to be an issue yet, I just err on the side of flexibility.

To be clear, I don’t really have an opinion on the totals, for that I’m very much ‘whatever you think makes sense.’ It’s the tier cap of 4k (and tiers more generally) that are my primary concern here. It just seems unnecessarily inflexible to me.

Are we calculating this on an hourly basis at this point? My impression was that this is getting funded highly due to impact, not solely due to the amount of time people are putting in.

The other thing is, there is no permanent private core group coordination going on. It’s just the public threads, and private spin-offs for specific things (recent Rocket Fuel coordination for example). ‘Added to the core group’ doesn’t really mean much except in terms of this compensation structure, that’s part of my frustration with it.

The practical dividing line between contributors is that some are showing up regularly and driving progress (core). And some (everyone else) are contributing varying amounts of time and effort, either irregularly, in bursts of feedback / drafting, in debate, etc, mostly (but not entirely) at the direction or in response to actions of the regulars (core).

On a slightly meta note, I would strongly and unequivocally recommend that everyone that has engaged with this (even if it was just writing up a bunch of feedback at one point), is rewarded generously, ie not strictly based on estimated hours spent. There are a few reasons this is a good investment:

  • People will be more keen to engage with critical initiatives of this type in the future, even if just by leaving detailed feedback.
  • New people experience first-hand that the GMC (Rocket Pool) funds contributions.
  • We’ve recently discussed the issues onboarding people into contributor roles, this is a chance to strongly communicate that it is worth the effort to onboard and engage with work in the community.
6

I believe we agree on avoiding the devaluation of impact by attaching hourly metrics, which is why I suggested a tier approach to reduce subjectivity and drama.

Based on my impression of the entire pot, contributors, and messages, these amounts seem reasonable. Flexibility can be obtained by submitting additional applications for other contributors that go above and beyond the tier suggestions.

The other thing is, there is no permanent private core group coordination going on. It’s just the public threads, and private spin-offs for specific things (recent Rocket Fuel coordination for example). ‘Added to the core group’ doesn’t really mean much except in terms of this compensation structure, that’s part of my frustration with it.

I believe formalizing a core group could add efficiency to your work. This is hypothetical, and you could, of course, choose to conduct business as usual. However, assigning structure, responsibility, and accountability could have its benefits.

The application grants the power to add to the core group, but if you have further suggestions to improve autonomy, I’m sure the GMC would be happy to hear them.