Rebalance RPL Inflation for Protocol Funding - Sentiment Poll

[drdoofus]

Rebalance RPL Inflation for Protocol Funding

Status: Sentiment Poll
Related: RPIP-10, RPIP-25, RPIP-33, RPIP-46, RPIP-68, RPIP-69
Discord Discussion: #Rebalacing RPL Inflation for Protocol Funding
RPIP Draft: RPIP-81

This has been discussed and had a successful sentiment poll before, but it has been long enough and conditions have changed that we need to do it again.

Sentiment poll below (keep scrolling, it’s there).

Overview

This is discussion and sentiment poll for an RPIP to rebalance RPL inflation allocation to increase protocol funding during and after the Saturn 2 transition.

Before Saturn 2, the current RPL inflation allocation sends 70% of RPL issuance to Node Operators, 27.5% to the pDAO, and 2.5% to the oDAO. This RPIP would reduce the Node Operator share to 50%, increase the pDAO share to 47.5%, and leave the oDAO share unchanged at 2.5%. This RPIP also updates the internal pDAO allocation policy to 30% IMC, 40% GMC, and 30% Reserve Treasury.

When Saturn 2 takes effect, Node Operator share of RPL inflation is already set to go to zero (RPIP-46). Under the existing Saturn 2 plan, annual RPL inflation would thus fall from 5% to 1.5%. Under this RPIP, elimination of Node Operator RPL rewards will reduce inflation from 5% to 2.5%.

Motivation

Rocket Pool currently faces a protocol funding shortfall.

The decline in RPL price has greatly reduced the DAO’s funding capabilities. The GMC has already made multiple rounds of cuts to support, administration, business development/STAR, marketing and other recurring expenses. However, current funding is now not enough for basic operating costs and does not provide adequate room for upcoming protocol needs.

The DAO is increasingly asked to fund or help fund items such as support, rescue node costs, business development, Chainlink costs, Saturn 2 related work, Snapshot, and other worthy initiatives. Meanwhile, pDAO funding from megapools is not yet available at meaningful scale and it might be a long time before it becomes helpful at all.

Before Saturn 2, 70% of RPL inflation is directed to Node Operator RPL rewards. When Saturn 2 takes effect, those Node Operator RPL rewards will go away entirely. This RPIP proposes a phase out of those rewards pre-Saturn 2 by redirecting part of the current Node Operator RPL issuance to the pDAO immediately, and to preserve that funding after Saturn 2.

Scope

Pre-Saturn 2 RPL Inflation Allocation

Before Saturn 2, this RPIP makes two related changes:

1. It changes the RPL inflation allocation from:

   Node Operators: 70%
   pDAO:           27.5%
   oDAO:            2.5%

to:

   Node Operators: 50%
   pDAO:           47.5%
   oDAO:            2.5% (unchanged)

2. It changes the internal pDAO allocation policy from:

   IMC:              50%
   GMC:              25%
   Reserve Treasury: 25%

to:

   IMC:              30%
   GMC:              40%
   Reserve Treasury: 30%

This bolsters the GMC RPL by about 10,000 RPL per cycle and approximately doubles the reserve treasury RPL per cycle (the IMC gets a practically negligible increase).

Post-Saturn 2 RPL Inflation Allocation

When Saturn 2 takes effect, Node Operator RPL issuance will still be eliminated as planned in accordance with RPIP-46 and the oDAO and pDAO absolute issuance will remain the same as the above changes dictate:

Node Operators:       0%
pDAO:                 95%
oDAO:                 5%

However, instead of reducing annual RPL inflation from 5% to 1.5%, annual RPL inflation will be reduced from 5% to 2.5% (simply the effect of eliminating the 50% Node Operator share).

Note that inflation can be further reduced in the future if circumstances dictate, but it might be a greater challenge to raise inflation after Saturn 2 from 1.5% if further funding is needed than to reduce it if it is not.

Rationale

Protocol funding need

The GMC’s current funding stream is insufficient at current RPL prices. The GMC has already reduced spending, but continued austerity has limits. Further cuts to support, administration, committee work, and contributor compensation risk weakening the protocol and losing contributors who are already working for modest compensation.

This RPIP is based on the view that Rocket Pool should not solve a structural protocol funding issue only by further reducing compensation to people actively maintaining and improving the protocol.

Node Operator RPL issuance is already transitional

Node Operator RPL issuance rewards are already expected to end with Saturn 2. This RPIP does not create a new long-term direction for Node Operator RPL rewards. Rather, it starts the transition earlier by reducing the Node Operator RPL rewards before Saturn 2, while still preserving a meaningful share until Saturn 2 takes effect.

Timing matters

This proposal is time sensitive because the current Node Operator RPL share only exists before Saturn 2. If no change is made before Saturn 2, then the 70% Node Operator share remains in place until Saturn 2 and then disappears. At that point, the protocol would need a separate future vote to increase inflation again if pDAO funding from megapools is not sufficient.

pDAO funding from megapools is not yet sufficient

A future pDAO share from megapools may become an important protocol funding source. However, that source is not yet available. The protocol needs funding during the period before Saturn 2 and may continue to need this RPL funding after Saturn 2 if pdao_share is insufficient.

Minipool operator expectations

A potential concern is that reducing Node Operator RPL rewards before Saturn 2 changes expectations for current minipool operators. This concern should be weighed seriously. However, the reduction affects RPL issuance rewards, not ETH rewards. It also occurs in the context of an already planned transition away from Node Operator RPL issuance rewards in Saturn 2. The proposal preserves 50% of RPL issuance for Node Operators before Saturn 2 while redirecting the remaining portion towards the pDAO.

RPL value and inflation tradeoff

This RPIP would result in higher post-Saturn 2 RPL inflation than currently specified in RPIP-46. The existing Saturn 2 plan reduces annual RPL inflation to 1.5%; this RPIP would instead reduce it to 2.5%.

Higher inflation can be harmful to RPL value if the additional RPL is spent inefficiently or sold into shallow demand. This proposal accepts that risk because underfunding core protocol needs can also harm RPL value by weakening support, development, growth, and contributor retention.

The intended tradeoff is not “more inflation forever.” It is to preserve protocol funding during a period where other funding sources, including pdao_share, may not yet be sufficient. If protocol revenue or treasury conditions improve, future governance can reduce inflation or revise the pDAO allocation policy.

Security Considerations

This RPIP does not change ETH rewards, validator duties, minipool delegate behavior, megapool mechanics, or validator security assumptions.

The primary risks are economic, governance, and incentive risks:

1. Node Operator expectations: Reducing Node Operator RPL issuance before Saturn 2 may be perceived as changing the expected transition for current minipool operators.

2. RPL value and sell pressure: Increasing the pDAO share and preserving higher inflation than RPIP-46 currently specifies, may increase sell pressure if the additional RPL is spent quickly or inefficiently.

3. Treasury discipline: Larger pDAO, GMC, and Reserve Treasury inflows do not by themselves guarantee better outcomes. Poor budgeting or weak grant oversight could waste the additional issuance.

4. Underfunding risk: If this RPIP does not pass and no alternative funding source is available, Rocket Pool may underfund support, operations, security related work, Saturn 2 work, contributor retention, and growth initiatives.

This RPIP attempts to balance those risks by:

• preserving 50% of RPL rewards for Node Operators before Saturn 2,

• eliminating Node Operator RPL rewards at Saturn 2 as already planned,

• keeping GMC, IMC, and Reserve Treasury spending subject to normal governance and budgeting processes, and

• leaving future governance able to reduce inflation or revise allocations if the additional funding is no longer needed.

Poll

Should this proposal proceed to a vote?

• Yes
• No
• Other

Next Steps

This RPIP modifies RPL inflation allocation and therefore requires a 75% “For” supermajority under RPIP-25. That means upon successful sentiment poll, the RPIP will go to snapshot vote and if supermajority votes “for”, then onchain vote will take place.

Passage of this RPIP should be treated as authorization for three related governance actions:

1. A pre-Saturn 2 onchain pDAO proposal to change RPL claim percentages to 50% Node Operators, 47.5% pDAO, and 2.5% oDAO.

2. An update to the pDAO allocation policy in RPIP-10 to set IMC to 30%, GMC to 40%, and Reserve Treasury to 30%.

3. An amendment to RPIP-46 so that the Saturn 2 rpl.inflation.interval.rate target is 2.5% annual inflation rather than 1.5%.

This proposal does NOT disallow or attempt to disallow further future changes to RPL inflation or its allocation.

Poll will close in 7 days.

[ramana]

I’d like to hear more about the IMC share reduction part. We desperately need rETH demand and IMC spend is plausibly better than GMC spend on creating that? I’m not sure.

[drdoofus]

IMC won’t get a reduction. In this scenario, they get some trivial increase (a couple hundred RPL) just to have the percentages look nicer. I would not be in any way against an even larger IMC increase, but they have not requested it and last time we changed percentages they just asked theirs not be cut.

edit: they will get 30% of 47.5% rather than 50% of 27.5%

[ramana]

thanks for explaining. i changed my vote to approve.

[Valdorff]

So… if we’re boosting things the protocol funds, I do like the idea of the IMC getting a boost as well. Here we’re ~tripling the GMC income (in RPL terms), ~doubling reserve income, and keeping IMC ~steady.

Our liquidity has suffered a lot. For context, here’s a bit over 2 years of what 1% price impact depth looks like (averaging rETH->ETH and ETH->rETH).

[drdoofus]

yep, let’s do it. Do you have a percentage you like? 40% for IMC (rather than 30%) is about an extra 4000 RPL roughly at the last cycle.

[epineph]

So i think we need to rebalance RPL inflationary rewards. We are getting to a critical point where we don’t have enough funding to carry out basic functions of the protocol; funding these pieces will do much more to drive value to RPL holders than the small slice of inflation. I think that there are points to be made for GMC, IMC, reserve, and oDAO each getting larger slices.

It does not seem to me that there is consensus about how much each should be raised relative to the others; to me, this RPIP is written largely from the point of view of GMC duties, so would need some minor revision if oDAO or IMC were significant recipients. Also, there are many people who have already voted to proceed to a vote with numbers that are changing.

I wonder if:

1. this RPIP should function as just a GMC rebalance, with future RPIPs for the other committees.

2. we need to push back a few weeks to get consensus on the correct splits (or maybe less time, maybe we just need a few polls?)

3. we adjust to send the additional funds to the reserve, and committees subsequently petition the pDAO for funding (this seems like the ugliest)

[langers]

ODAO Allocation

One area I’d like to raise for discussion is whether this is the right moment to revisit the ODAO allocation, which has remained at 2.5% unchanged.

The ODAO requires a minimum number of members to operate effectively and maintain adequate diversity. We have seen some high profile exits from the ODAO recently, and while the causes are varied, compensation is a factor that is within our control to address.

Given we are already rebalancing allocations, it feels like a natural opportunity to consider a modest increase to the ODAO share rather than handling it in a separate vote. I don’t have a specific figure to propose at this stage and would welcome community input on what feels appropriate.

[drdoofus]

I am not against considering oDAO changes (in fact, I spearheaded the effort to bring oDAO from 1.5%to 2.5%). Personally, I would be fine with putting an oDAO increase in here. The biggest issue for me is I want this to go to a vote. It will already be at least seven weeks from now to implement all this if nothing else delays.

On the one hand, RPIP-25 says:

The inflation allocation to the oDAO SHOULD NOT be changed (up or down) based on RPL price. Price risk was already considered in the selection of the inflation allocation.

On the other hand, it also says:

Payments to the oDAO:

1. Must cover ongoing expenses and initial expenses
2. Should help keep members eager to serve in their role
3. Should mitigate the chance of bribery

Then there are questions about how much is appropriate (I have no idea if going from 2.5% to 3.0% is enough to keep oDAO members “eager” or not)?

I am generally for increasing oDAO payment. However, oDAO has not been easy to advocate for because some do not perform duties and they are pretty opaque to the greater community. I think the community would like to see an oDAO representative come in the the discord on occasion to tell us what things are like for them, what they need and why, and what they are doing about it.

The greater issue as I’ve seen brought up by @knoshua, @epineph, and @sckuzzle to name just a few is that oDAO payment in RPL seems a little broken. We might need a complete restructuring of how it is done, including the possibility of paying them ETH from pdao_share when that becomes available.

In light of all that, for me, I’d break down whether oDAO should be included in this vote as follows:

Do NOT include oDAO in this re-allocation if

• we don’t know how much oDAO should get without a much longer debate
• we think oDAO can wait for a restructuring that is more appealing to them and takes their views into consideration
• we think the percent increase needs to be significant
• there is too much community angst over this (I very much want and the protocol, imo, needs this re-allocation to pass and it needs a super majority)

Do include oDAO in this re-allocation if

• a small 0.5%-1.0% (~900 RPL per cycle to the oDAO pot) is sufficient

My worry would be this delays this vote too much and oDAO is still unhappy and we come back to square one in the near future, so as someone NOT against oDAO increase, I’d prefer oDAO gets together, discusses what they really want and advocates for themselves to the community. If this smaller change makes them happy, we could change the draft RPIP to something like 50% Node Operators, 3.5% oDAO, 46.5% pDAO and take a new sentiment poll. That’s another week added to this already lengthy multi vote process.

However, for the needs of the GMC (the reason I am pushing all this) and my sanity, I need the groups who want changes to this (oDAO and IMC) to say what they want so we don’t have to guess then have them not be happy.

[knoshua]

I agree with @drdoofus on the oDAO inclusion here. In addition, I’ll point out that we’ve been very wasteful with oDAO gas for three years since RPIP-19, despite a more efficient solution being possible. Three years ago this wasn’t a big deal since gas cost was very low compared to oDAO compensation. But this hasn’t been the case for over a year now and I’ve tried to push for fixing it when increasing oDAO pay last came up and it’s even included in RPIP-68. Nothing happened on that front and now we appear to be back to “oDAO pay is not enough, lets just increase it instead of working on lowering their expenses”. This is quite wasteful and frustrating.

[langers]

Although gas costs are a significant aspect of ODAO costs, they are not the only costs. Each ODAO member is different but they may also have infrastructure costs, maintenance time, and an archive service to factor in.

We have already started looking at optimising gas costs but happy to take designs/feedback on further improvements.

[langers]

The loss of members has actually improved the per member economics somewhat, as the allocation is split fewer ways - so we may not be as far off as it seems. I think a 0.5% increase would get us to a reasonable place from a cost coverage perspective in the short to medium term.

On the broader engagement point, keeping members motivated comes down to ensuring the role is adequately compensated but I agree an engagement process is needed to properly assess that. I’m happy to drive that going forward so we can identify what’s needed and inform longer-term funding decisions.

My main goal here was to open the conversation while we have a natural opportunity to do so. I don’t want to hold up the pDAO funding vote, and if this proposal is proving controversial, I’m comfortable with it being excluded and addressed separately.

[Pieter]

This seems like a good plan for the protocol to weather current circumstances.

The IMC share, while not reduced in absolute terms, is reduced in relative share compared to the GMC. Valdorff raises a good point related to liquidity, but I’m not sure how urgent the need is compared to the GMC’s and hence what an ideal percentage for each would be. A modest increase compared to current baseline seems defensible.

Regarding the oDAO funding, this has historically been a touchy subject, and risks opening a community can of worms before or during the vote.
As far as I know, no leaving oDAO member has explicitly named funding as a reason for their exit. It may of course still have played a part in their decision making. But my interpretation is that the oDAO exits were motivated more by shifting priorities and the broader crypto winter. So, a modest funding increase may not even be enough to sway future decisions, and does risk delays or even defeat of this proposal.

If we do want to include the oDAO payment increase, I’d prefer the vote to be structured such that oDAO inclusion preference does not risk the entire proposal.

[NeverAnIsland]

@drdoofus

Node Operator expectations: Reducing Node Operator RPL issuance before Saturn 2 may be perceived as changing the expected transition for current minipool operators.

What does this risk entail? Things are constantly changing so what?

I’d like to see the total inflation lowered by the same amount that pDAO is going to receive, instead of rebalancing from NO share. The reason is that it is guaranteed that pDAO is going to sell RPL and simple rebalancing does not protect the RPL price from that pressure.

To clarify what I mean here are the numbers:

inflation: 4%
NO share: 36%
pDAO share: 59.5%
oDAO share: 4.5%

This gives almost the same absolute numbers for [op]DAO RPL shares as proposed above, while further reduces RPL rewards for NOs. At the same time the inflation is reduced the same amount as pDAO share is increased in terms of RPL (absolute value).

[drdoofus]

I’m not in some absolute sense against such a reallocation. I am trying to be the least disruptive I can be in this proposal. Inflation is already set to come down in Saturn 2, so I am not rocking the boat of making us reduce inflation pre-Saturn 2, then again post Saturn 2 (which then comes with share reallocation and potentially internal pDAO reallocation). That is a lot of votes and time and work.

This example also reduces NO share quite a bit more that the 70% → 50% I propose. Again, to try to make it as palatable as possible while getting the funds I think we need along with some buffer (eventually). There is no buffer for many months while we will be using funds to pay off Saturn 2 work.

Now, you might say reducing inflation should raise RPL price which makes up for this example NO share being 36% of 4% rather than 50% of 5% (down from 70% of 5%) which is an argument you can choose to make but I’m trying to minimize the “why my number of RPL rewards go down” NO confusion that is bound to happen. “We reduced you by 30% as a step down because protocol needs funding” was the sweet spot we chose.

[drdoofus]

This sentiment poll is now closed.

Based on the result 27 to 0 in favor of proceeding to a vote and based on extensive forum and discord discussion, the post-mortem is as follows:

From a content point of view, RPIP-81 is ready for vote.

1. When the RPIP review stage is complete, the RPIP will be finalized
2. At that time, RPIP-81 will go to snapshot vote
3. If the vote succeeds, the pre-Saturn 2 reallocations will be proposed in on-chain voting
4. After Saturn 2, inflation and allocations will be changed according to this RPIP, unless it is subsequently altered via another vote.

on IMC funding
After the next few months where the funding is very much needed for GMC for Saturn 2 work and outstanding obligations, we can and should review the internal pDAO allocation in regards to increasing IMC share. It would be a good use of RPL, but might need some more review to find the amount that is most effective.

on oDAO inclusion
First, thank you very much to @langers for bringing up the oDAO in this discussion. It needed to be had and I think it moved in a positive direction.

It seems that currently oDAO payment is quite a contentious subject. Not because people are largely opposed, but because:

1. pDAO does not feel oDAO is fully aware of its obligations and wants this to be known.
2. There is fixable inefficiency in gas costs that knoshua has been trying to push through for a long time. That should be part of an oDAO payment discussion.
3. The overall payment structure to oDAO is broken and needs an overhaul.
4. With oDAO not advocating for itself, the pDAO really has no way of knowing what price is appropriate without leading us right back to this point.
5. A healthy way should be sought for oDAO to bring forth its wants/needs and pDAO to express its grievances/thoughts without oDAO members feeling attacked and pDAO members feeling frustrated.

This suggests that a dedicated debate and RPIP is most appropriate. This should be pursued sooner rather than later to try to put some of this behind us (as soon as we can responsibly get to it).

on on-chain voting
The RPIP voting and supermajority requirements were designed before the on-chain voting system was enacted. The current framework is outdated, clunky and inefficient and needs reworked.

Thank you everyone for your heartfelt contributions to this proposal.