2024 Tokenomics Rework Drafts

Hi all,

I wanted to get us to a next step towards tokenomics revamp.

This follows on from the work Val and Samus presented at Denver Lift-Off (see high level video or the more detailed proposal writeup; either of these is my recommended starting point if you’re new to the ideas), as well as some community refinement in the Tokenomics RPIPS (preforum era) thread on discord.

There are 8 new RPIPs here. 1 is an info RPIP to guide folks through the others, a couple are very simple, and some are more complex. I suggest starting at the info RPIP I mentioned: https://github.com/rocket-pool/RPIPs/blob/main/RPIPs/RPIP-49.md.

Here’s my little teaser from that info RPIP:

17 Likes

Reserving this post for todos, and kicking it off with a couple off the bat

TODO

This is currently in RPIP-49 itself

1 Like

I would be curious to hear from the team how long they would expect each release to take under the scenarios listed here (for example, how much longer would release 1 take under Scenario C compared to Scenario B/D? Would it take roughly twice as long, or delay things by 6+ months if we wanted to wait for UVC/Burn to be included?):

https://github.com/Valdorff/RPIPs/blob/spring2024-tokenomics-rework-drafts/RPIPs/RPIP-49.md#potential-deployment-scenarios

I’d also like to hash out how we should handle RPL emissions/inflation especially in the short term

3 Likes

Example RPL Inflation Options/Discussion:

https://discord.com/channels/405159462932971535/1215788197842255972/1219073899925344318

DAO

  • Present Day: 1.5% of RPL inflation (30% of 5% total)
  • Option A: Scale down with market share growth, replaced by ETH commission instead

NOs

  • Magnitude
    • Present Day: 3.5% RPL inflation (70% of 5% total)
    • Option A: Keep at 3.5% indefinitely
    • Option B: Set to zero as soon as UVC/Burn is released
    • Option C: Scale down with market share growth. Ex:
      • Lower to 3% as soon as UVC/Burn is released
      • Lower by 1% for each major market share milestone
        • Lower to 2% after crossing 5% market share
        • Lower to 1% after crossing 10% market share
        • Lower to 0% after crossing 15% market share
  • Eligibility
    • Present Day: RPL Staked >= 10% borrowed ETH
    • Option A: Keep at RPL Staked >= 10% borrowed ETH
    • Option B: Lower to RPL Staked >= 4.3% borrowed ETH
      • This could be for LEB4 to keep the same RPL exposure requirements as LEB8s, especially if we release LEB4 before UVC/Burn
    • Option C: Change to scale directly with borrowed ETH
      • All Node Operators receive RPL emmissions, determined by (your Borrowed ETH)/(total Borrowed ETH)
      • RPL inflation is used here to further incentivize NOs, also providing a path for Eth Only NOs to “earn” access to governance

Thank you for putting that together @Valdorff

From the team’s perspective, we are kicking off workshops this week to breakdown each of the RPIPs. This is so that we a) socialise across the team b) can provide feedback c) get an idea of sizing and complexity to facilitate estimation.

We can work on the estimation and timeline in parallel to the governance process. Bear in mind, there is still Houston work going on so it is a balancing act to get that out and dedicate time to scoping these RPIPs. The Houston work should ease off in the next two weeks and in the meantime we will run these workshops.

4 Likes

@kane and I have discussed the potential release scenarios and have a preferred candidate but we need to break it down further and get the rest of the team’s input to give that answer. We will do that in the workshops over the next couple of weeks.

9 Likes

Linking my perspective for consideration.
https://hackmd.io/@rocknet/BkbhHe6TT

TLDR;

I hope that you take the time to read what took me a lot of time in reading, consideration, and writing this document. If you can’t, here’s the TLDR;

Scale with:

  • Implement LEB4 alone (distinct RPIP needed)
  • Implement megapools (RPIP-43)
  • Implement forced exits (RPIP-44)
  • Keep RPL bond / do not implement ETH-only minipools (abandon RPIP-42 / RPIP-48)
  • Do not reduce the borrowed ETH commission to Rocket Pool Node Operators by 75% (abandon RPIP-46)
    current Node Operator commission: 14%
    RPIP Values:
    node_operator_share = 2.5
    voter_share = 1.0
    2.5 + 1 = 3.5
    3.5 / 14 = 0.25 (25%, a 75% reduction)
    Note: Some reduction in commission for LEB4 may make sense, just like we did for LEB8, that should go to rETH, again, like we did with Atlas. (distinct RPIP needed)
  • Do not implement a mechanism to buy and burn RPL (abandon RPIP-45)
  • Support NodeSet as a method of scaling Rocket Pool
  • Generally supportive of a dynamic / variable commission concept without the buy/burn concept
    Indifferent on removing opt-in upgrades RPIP-47
  • Consider reducing the ETH bond below 4, after a demonstrated period of LEB4s and NodeSet being deployed while the deposit pool remains full, and Rocket Pool is not approaching self-limit, while retaining some level of RPL bond
4 Likes

Thanks for the thoughts @rocknet

I’ll respond to some particular bits…

We should allow another six months after the withdrawal threshold is set to 60% before making further RPL tokenomics changes, to see how the change plays out. This means I advocate not making dramatic RPL tokenomics changes for the remainder of 2024.

We are, essentially, a startup protocol. We are not yet getting enough revenue at this size to be stable imo. We have lost market share since last summer (some of the recent action has been the points meta etc). I think action is existential.

And then there’s competition. Lido CSM aims to launch late 2024. If we haven’t even started to move by the time that has already launched, I think there’s a good chance we simply cannot compete for Node Operators.

I think our brand is awesome. There’s a period of time we can use that to keep ourselves above water. I don’t think it’s indefinite and I think if we’re simply waiting the rest of 2024, then we might as well pack it in.

3.5 / 14 = 0.25 (25%, a 75% reduction)

This is not right. Currently, we pay 14% commission to an amalgam of both ETH and RPL staking. The only way to get 75% reduction is to assume that RPL burn has zero benefit to RPL holding NOs. There is a reduction insofar as more RPL is now being rewarded (all vs staked). I see this partly as a temporary thing, however – there’s no reason to expect large amounts of unstaked RPL long term.

Nodeset/Constellation

You discuss the NOs that benefit – absolutely, accepting free money is the easy part. RPL also shouldn’t be too hard – holders can get some yield instead of none. The tough part is finding enough ETH. xrETH yield is solo apr, or ~3.9%; this is lower than something like rETH/ETH LPing, currently 4.5-10% apr, and it uses younger less tested contracts. RPL also becomes a challenge at maturity. When growth isn’t a significant expectation and more than 70% of RPL is staked, rewards won’t even offset inflation and I’m not sure why anyone would hold it independent of personally running a minipool.

I hope I’m misunderstanding the market and there is a huge appetite here, but I don’t personally see it.

I believe one should consider whether some of the more dramatic changes below will even be necessary. Assume NodeSet / Constellation provides some level of scaling, and LEB4 with Megapools provides more. No one knows for sure how deep the rETH demand is

This might be an important perspective difference. If rETH demand is easily met because it isn’t deep, I consider RP a failed experiment. I think we need to see at least a 4x of our TVL to hit long term sustainability.

Prefer to scale with current Rocket Pool NOs, or those that have avoided Rocket Pool so far?

I am a little agnostic. All else being equal - sure, I love the community. But I think it’s primarily important to scale.

As a small side note… we could absorb ~95k more ETH if current NOs that already have enough RPL staked migrated to LEB8s. I’m not quite sure what to make of that fact, to be honest. I think some of it is simple awareness and inertia of the status quo. I think some might be liking a large buffer to continue receiving RPL rewards. The point I’m trying to make is that we’ve only had about 4.8k migrations and we could’ve had ~double that. If we keep the 10% borrowed ETH RPL bond, I suspect we do even worse at migrating to LEB4s (as the required RPL exposure of the smallest minipools would get more extreme from the current 30% to 70%).

So, the deposit pool draws down to some unknown extent, and no value accrues to the protocol token to help fund the DAO and team, due to the removed RPL stake.

I’d love to discuss this further. The whole point of the burn is market demand that benefits all RPL holders. Please see slides 13 and 14 in On The Horizon - Google Slides, which explicitly address how the token is benefitted by more ETH-only operators. Alongside the earlier “75% reduction” calculation, I am wondering if it’s simply the case that you believe that market buy+burn accrues no value. If that’s the case, do you feel any different about the buy+LP strategy?

1 Like

I have been told it may be helpful to express myself on this forum and not just in Discord. In my own words: “just do something” is my sentiment. As summarised by Valdorff: my stance is “I believe we must act fast. I don’t have the time to work on the details, this seems reasonable from the high level stuff I’ve seen.”

This Proposal will Change How RPL Works

This proposal is MORE important than the nETH/pETH debate.
Personally, I am mostly in favor of the tokenomics changes here.

READ it and think about it. It affects your money and REWARDS!

RP is losing node operators and risks becoming less competitive. It is happening with every month that passes. We must adapt or lose relevance.

4 Likes

Adding a couple of polls to help get a better feel for where the community is at.

How much have you read about the proposal?

  • I haven’t read any of the links yet
  • I have read RPIP-49 (summary) but not the individual RPIPs
  • I have read all the RPIPs
0 voters

What is your opinion on the proposal?

  • I like it and support it
  • I like it overall but disagree with some aspects (if so, please comment/speak up on what you dislike or how you’d suggest to change it)
  • I don’t like it and prefer the status quo
  • I don’t like it and want something else (if so, please comment/speak up on an alternative proposal)
0 voters
2 Likes

I understand that Nick and Wander have a rebuttal and counter argument that should be released momentarily (eg. day(s) to some of the tokenominc proposals. I recommend that we wait for their input. I agree with Dr. D that these proposals are one of the more important decisions that the pDAO has ever undertaken and encourage all pDAO members to fully understand the proposals.

12 Likes

Very keen to see the rebuttal. I am overall of the opinion that a good set of actions to take now is 100x more valuable than a perfect set of actions in 6 months.

15 Likes

I can’t think of a more important moment in the history of the protocol than this one. We have lost a significant amount of stake towards people airdrop farming for Eigen layer points and elsewhere. It is critical that we implement changes to the protocol to drive value to RPL, deliver the best yield available to node operators, and increase the network effects of rETH.

Tokenomics changes such as these will help Rocketpool tremendously over the long term. Ethereum’s tokenomics took a long time for them to be researched and implemented (and are still being worked on) to make it what it is today. These are key changes needed for long term growth and sustainability.

7 Likes

I get the reasoning behind forced contract upgrades, it makes sense.

But there is tremendous value in being sure that you can operate as per agreed upon terms.

At the moment, this works like a perpetual license. I buy the specific software version and have the right to use it for all eternity. If I want updates, I have to buy a new version and agree to the updated license conditions.

But what this wants is a subscription service. You have the right to use the software but you must always worry about changes being introduced that you don’t like. Of course, you can quit then, but you already invested much.

Example: I develop software that produces PDFs. So, we integrated some third party library with subscription license. Now they are way too expensive and we have to either pay or get rid of all the code and implement a new PDF library because without annual payments we cannot use their product…

Why anyone would ever choose subscriptions if he can also choose perpetual is truly beyond me.

So, concluding, with this change I would rather go with a competitor if that competitor doesn’t have a much worse product, because I don’t have the guarantee anymore that I have now.

I waited quite a while to initialize my fee distributor because I was in the smoothie pool and didn’t need it. Only when I wanted to convert to LEB8 I had to do it (if I rememver this correctly). But it was my decision and I got something out of it that I wanted.

If I would have been forced to spend gas to initialize something I didn’t even need/want, I would have probably left then and there.

1 Like

I hear you, but I can’t think of a way that allows both “overall market responsiveness at the protocol level” and “NO sovereignty over their settings responding”.

From a competitiveness standpoint, my question would be: “does a competitor exist like that?” and “does their choice hinder their market responsiveness to the point that they will be damaged over time?” I think right now the answers are “no” and “yes”. The closest I can think of is Stakewise, perhaps.

3 Likes

The full NodeSet review of this topic is located here:


In this report, we analyze RPL in the context of the current use case and what makes it sustainable. Additionally, we consider how the current indirect model compares to the proposed direct revenue approach. Next, we analyze the proposed tokenomics rework and assess the risks associated with each component individually and in totality. Lastly, we evaluate the impact of these proposed changes on NodeSet’s work before suggesting an alternative proposal.


Ultimately, we cannot support the proposals outlined here as written due to the extreme risks involved. There are some changes which may decrease this risk, which we outline in the above document. We encourage the community to make informed decisions instead of hyperfocusing on “doing something”.

Finally, I will note that it is very poor form to begin the sentiment poll process with a draft proposal. Even a finalized proposal should have plenty of time set aside for high quality study and discussion before moving towards implementation.

EDIT: misunderstanding!

9 Likes

Thank you for your paper!

Finally, I will note that it is very poor form to begin the sentiment poll process with a draft proposal. Even a finalized proposal should have plenty of time set aside for high quality study and discussion before moving towards implementation.

I believe this poll is an attempt to try to force discussion with the larger community since this is such a massively important topic. It is not meant as a sentiment poll that directly leads to a particular RPIP vote. If I am mistaken, someone will no doubt correct me.

7 Likes

It is absolutely not a sentiment poll to gate being ready to vote. The RPIPs are waaaaaay too unpolished at this time for that.

5 Likes

Noted, my apologies! I’ve edited my previous comment.

1 Like