Amendment For Retrospective Award Cap

Due to the current 50% retrospective award cap in RPIP-18, the GMC faces difficulties in efficiently disbursing retroactive awards. RPIP-18 has the following line:

The GMC MAY give retrospective awards for previously-completed work. Such applications MAY be submitted on behalf of others rather than being self-nominated. In any given award period, no more than 50% of the awarded RPL SHALL go to retroactive awards.

With over a year of backlogged projects before the GMC, around 80% of submissions fall into the retrospective award category.

During the second award round, retrospective awards accounted for 75% of the total awards, further exacerbating the GMC’s accounting challenges as they struggle to recover from the overwhelming volume of retrospective award submission, which continue to outweigh grants and bounties.

Here is the reward breakdown from round 2:

Screen Shot 2023-05-08 at 10.56.36 AM

In order to fix this issue the GMC is proposing either of these solutions:

  1. Raise the 50% cap to 80% and
  2. Allow a one-time payment to clear through the backlog

OR

  1. Remove the cap entirely

What do you believe is the best solution?

  • Raise the cap to 80% and allow a one-time payment to clear the backlog
  • Remove the cap entirely
  • Leave it the way it is
0 voters
1 Like

My preference would be either:

  • Don’t count work from before first GMC round towards the cap
    • Redo some math from the past to see where were at
    • This preserves the forward focus originally intended, but likely clears the backlog (or most of it)
  • Remove the cap entirely [update 5/19: I no longer like this option, see below]

Setting the cap high enough that it does nothing doesn’t make sense to me.

I’d probably favor just getting rid of the cap. There’s been little evidence that the GMC as currently constituted is being wasteful with funds or is denying grants/bounties in favor of RAs. We also have a challenge process if the pDAO thinks that the GMC is overly favoring RAs and, in the ultimate case, could reinstitute the cap if needed. As of now I don’t think it is serving much purpose other than to make people wait a year or more to receive RAs they’ve earned.

I like this idea better than the other options.

2 Likes

I like clearing the backlog and seeing where we stand in the next period. If rewards are still skewed towards retroactive awards, it might make the most sense to remove the cap entirely.

I voted to keep the structure unchanged. To me, none of the solutions dealt with the central issue: we don’t have enough forward looking projects. The bar to reimburse retroactively is a lot lower than funding prospective grants (by my rough count, 12/13 retrospective awards were approved [and #13 was partially funded through other means] and 4/13 grants were approved this round); RA are more likely to be funded based on ‘time spent’ on rocket pool, whereas grants have needed to be discreet, actionable, and highly effective. I think many of the RA awardees would not have been approved for grants, or not in those sizes, for their efforts.

I think we are still early, but we need some sort of grants and bounty incubator for high quality submissions and follow-through; then the retroactive backlog will take care of itself. Retroactive awardees are currently monetarily incentivized to get grants approved (for themselves or others)-I think this is healthy.

2 Likes

The GMC is still struggling to properly value awards. In fact, we made a policy this time to push certain grant applications toward retroactive grants. Sadly, that will just skew the issue further. In the meantime, we have people waiting months to receive payment for retro grants that have been approved.

We have a BIG issue with the retro cap right now. Based on the amount of grants we awarded in round 2, we can only pay out 396 RPL towards retro awards.

We currently have 7,125.95 RPL in retro awards that have been approved but not paid out. We can only pay ~5% of the total balance this period. It could potentially take years to pay back all retroactive awards, leading to dissatisfaction and discouragement among community members.

Even with the approval of all grants during this period, the retroactive awards would still surpass the grants by a significant margin. To enhance the effectiveness of the grant incubator, the ideal solution would be to implement a rolling rewards period or introduce an additional review phase after each grant round (which is currently in development). The current limitation of the cap is merely impeding the distribution of rewards, without providing any substantial benefits.

3 Likes

Really, all the stuff pre-round one should just be cleared. An RPIP for that would pass for sure. The other procedures for the future, rolling rewards or review period post-decision might be good, also, but I doubt anyone would dispute paying out the round one RA backlog.

1 Like

I am speaking here in the context of a retroactive grant recipient and not a member of the GMC.

I find it incredibly frustrating that the work I did is not being funded in line with what we were told at the end of cycle 1. I know there are many people in the same position as me, and we have different levels of patience. Regardless, this issue needs a solution.

I’ll add my vote that the cap should probably just be removed at this point so we can actually put the treasury to work. A lot of good stuff isn’t being rewarded because of it, and it’s going to cause more hamstringing in the future. If you’re going to trust the GMC to help grow the protocol and ecosystem, let it do its job.

1 Like

My worry is that the GMC is not doing its job. RPIP-10 defines the budget for “Grants and Bounties”. RPIP-18 is the charter for the “Grants and Bounties Management Committee”.

We’ve seen ~74% of funds go to retros each cycle. This is not entirely on the GMC - they can’t change the ratios of the retrospective vs forward-looking items they receive, which comes from the greater community. They also can’t do anything about retrospective rewards from before the first GMC period. I think this latest cycle was roughly 50% retrospective from the pre-GMC era, 25% forward-looking, 25% retrospective from the GMC era. In other words, I think we’re only slightly off if we allowed pre-GMC work to ignore the cap (which was my suggestion above).

I think it’s important to keep the forward focus so we’re not asking folks to do work first without any reliable expectation of pay.

Other possibilities to aid forward focus
  • Reduce cycle time - this has been talked about
    • Add a discussion period where GMC and poster can go back and forth; prevents a “close, but not quite” into a full quarter of delay
    • Rolling submissions; rather than increasing the odds of hitting it in one
  • Reward forward-looking items more more while supply of forward-looking items is low
    • Reward more aggressively - even being a little irrational on purpose can make sense to incentivize getting more inputs
    • Reward grant and bounty submissions in some way
    • Reward beyond amounts asked for if appropriate
  • Slightly lower the bar for acceptance. This can’t be “fund everything”, but it can be “we were on the edge, so let’s go for it”

I’m perfectly happy scrapping the cap if we have some plan to keep us forward-focused. I don’t think I’m ready to fully axe the cap otherwise though. At a minimum, it’s a symbolic item that says we want to be forward-focused, which is better than nothing.


I will note that I’m fine with a couple of lesser interventions, which I mentioned in discord earlier. Either of the following would be an easy “For” vote for me:

  • Explicitly don’t count work prior to round 1 towards cap (including future retro grants for work before round 1)
  • One-off clear (but that would have future retro grants for ancient history still contribute to cap)
1 Like
So our current GMC flow goes something like:
  1. Community member sees a problem and guesses that the GMC also thinks this is a problem based on what the GMC believes the DAO would see as a problem.

  2. Community member comes up with a solution and guesses that the GMC also thinks this is a good solution based on what the GMC believes the DAO would see as a good solution

  3. Community member writes a grant

  4. GMC approves/rejects based on their conception of what the DAO wants

  5. The DAO and community members wonder why the process is jacked up.

It’s almost peak inefficiency, because many grant writers are spinning their wheels dealing with problems (see translation of docs) that the GMC doesn’t think the DAO needs to fix. And because no two grants are trying to fix the same problem, I’m sure we are not getting even close to optimal solutions.

What I think a better flow would look like:

  1. The DAO agrees upon which problems need fixing by the community (priority/roadmap RPIP)

  2. Community members come up with one or many solutions to those problems

  3. The gMC decides if the solutions would likely fix the problems already laid out by the DAO, although they can award outside that for new or innovative ideas.

Once we agree on the problems, I definitely support lowering the bar for grants/bounties- even going so far as to say we could use grant stimulus: some minimum amount of RPL awarded to the grants category each round no matter how dim the GMC thinks their choices are. Shovel ready.

In response to the recurring concern regarding the absence of a suitable replacement for the cap’s purpose, the GMC has addressed this issue by incorporating the removal of the cap in the same proposal as the implementation of rolling awards periods. You can find detailed information about our outlined plan here.

1 Like