# Perspective on Rocket Pool tokenomics changes

### Motivation
It's nearly a part-time job keeping up with voluminous content surrounding the quickly developing protocol change proposals. Time that many people don't have. It's time that I don't really have either, but I have set aside enough time to read the entire [pre-form thread](https://discord.com/channels/405159462932971535/1215788197842255972), as well as all of the RPIPs, and prepare this alternative perspective, to give the average Rocket Pool Node Operator something else to consider.

It's easy to go by vibe check and get a sense that something that seems to have a lot of energy behind it is necessarily a good idea. Also, some understandably are happy when they see any change that intends to positively impact their investments, while perhaps not deeply considering potential risks and adverse side-effects.

These are my considered opinions, if you find general alignment with this perspective, and wish to be added as a cosignatory, whether anon (tell me, and I will just add an anon counter), or by discord handle, reach out to me in discord, DMs are open. That said, I don't have time to get involved in dozens of DM threads of debates. I'm necessarily dialing back the time I spend keeping up with these change ideas from here. I know how I'd vote on the RPIPs as they stand today.

### 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

### Who I am
I go by rocknet in discord. I run six LEB8 minipools from home (East Coast, US). I started as a Node Operator on Jan 18, 2022. As of Mar 11, 2024, my RPL collateralization is about 100%, down quite a bit in ratio since entry. I also run nodes for other permissionless liquid staking protocols, partially to support them in their infancy, and partially as multi-faceted risk management.

I'm also on the GMC as of 11/10/2023. Nothing herein should be construed as feedback from the GMC. I don't expect any of the items below to come before the GMC, they should be pDAO level items. I will abstain if any application for implementation comes before me, because I have pre-conceived opinion. I'm generally positive on research funding.

My overarching desire is for a maximally decentralized Ethereum, while acknowledging the realities of the evolving ecosystem. Having my RPL bag maintain vs. ETH would be great, but not at the cost of making Ethereum or Rocket Pool worse. Assuming Rocket Pool remains a place that prizes independent operators, I plan on running my minipools for at least 15 years. If that changes, I may reassess.

### Preferences
In order, my goals:
1. Try to keep Ethereum as decentralized as possible via independent stakers. I think the gold standard is home stakers, since there are obvious benefits in distributing validation duties as widely as possible, but independent operators are important, even if they use centralized service providers.
2. Grow Rocket Pool's share of the stake, in furtherance of #1, but not if it takes away from #1. The more Rocket Pool can onboard ETH stake with independent, permissionless operators, the less stake goes to those with an already large stake share. I'm much less interested in Rocket Pool's share of stake growing just for the sake of it. If doing so allows 10 operators to go from 1% total ETH stake each to 2%, that's much worse than 1000 node operators increasing their stake share by 0.02% each.
3. RPL numba maintain vs. ETH.

I also have a preference for moving other levers to scale, prior to making large monetary policy changes. This goes for Ethereum, as well as Rocket Pool. Stability of monetary policy is an important attribute for many market participants, and changing it often and drastically can have unintented consequences.

Further, we should avoid making additional large tokenomics changes atop an already changing tokenomics regime of RPIP-30. We need to evaluate, to the extent possible, the positive or negative results of this change. The change will not be fully implemented until at least two weeks after the June 2024 rewards payment, when RPL withdrawals down to 60% collateral will be enabled. 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. It is always useful to know if the desired goal of a change was achieved, because results matter much more than intent.

Finally, I support the work of community member projects in furtherance of the goals above.

### Expected scaling solution prior to recent months
Since before Atlas, I believed the Rocket Pool scaling solution has been ETH bond reduction, specifically with LEB4, and potentially lower with forced exits in the future. In addition, the community member birthed NodeSet / Constellation "Layer 2" for Rocket Pool NOs, where minipools could be created with entirely delegated ETH / RPL (0 ETH / RPL Bond), was looked to, by me at least, as a huge scaling opportunity.

### LEB4 and forced exits

There has been previous research / discussion into whether Rocket Pool requires execution layer forced exits prior to enabling LEB4. Obviously, for ultimate safety, it'd be good to have, then again, it'd be good to have today for poorly performing operators and the potential for huge block MEV theft, in case the MEV / tip market goes wild.

I'm seeing some discussion in the community that given the minimal observed MEV theft to this point, and the expectation of forced exits via EIP-7002 in Pectra (date TBD, but likely by spring 2025), LEB4 without forced exists would be acceptable for an interim period, which is expected to be less than 1 year. I agree with this thinking.

### Prefer to scale with current Rocket Pool NOs, or those that have avoided Rocket Pool so far?
One of the great things about LEB8s / Atlas, was that it allowed the scaling of Rocket Pool TVL (minted rETH), while benefiting the Node Operators that had supported Rocket Pool for more than a year, those that had already been helping the protocol to scale to the level it had achieved. Without them, Rocket Pool never achieves any scale.

It's great that we also allowed solo-staker migration, because they would also get higher ETH rewards (at the cost of RPL stake buy-in), but we didn't privilege new Node Operators that had avoided Rocket Pool above those that had already supported the protocol. I believe this ethos should be maintained. "Dance with the date that brought you", so to speak. There is some sentiment around the proposed changes that there is more desire for new Node Operators, rather than (or at least in preference to) scaling using our existing Node Operators first. I strongly disagree with this approach.

If there is a desire for new Node Operators, we should promote the NodeSet / Constellation opportunity. Since some outside operators see the RPL stake as near-trash, demonstrate how much more quickly the RPL stake can be "paid off" (assume it's a 100% written off expense) with NodeSet. By demonstrating 95% performance and becoming a NodeSet operator in six months and getting commission on bonded ETH that was provided by others, you're gaining even more juiced yield, which helps offset the RPL bond.

### Overall risks of a changing market / staking landscape
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, especially after things like EigenLayer airdrops are completed and an ETH bull market is in full swing. Is there continually rising demand for ETH staking at all, and rETH specifically? No one can know this with any confidence. It's quite possible that ETH staking at $10,000 ETH looks very different from $3,300 ETH.

## Feedback on specific tokenomics change proposal
Now that the discussion has moved to draft RPIPs in the rocket-pool repo, I'll be discussing each. Note: I'm commenting on drafts that are included in a yet-to-be, but expected-to-be merged [branch](https://github.com/Valdorff/RPIPs/commits/spring2024-tokenomics-rework-drafts2/).

### 1. [Bond Curves - RPIP-42](https://github.com/rocket-pool/RPIPs/blob/main/RPIPs/RPIP-42.md)
**Note**: As of 3/23/2024, there are [draft changes](https://github.com/Valdorff/RPIPs/commit/36534b1e0ad2e9e6b4c133b4879815cd7f888a32) that make RPIP-42 combine the ETH-only validator concept, so I'll include that here, and note that RPIP-48 is withdrawn, below.

#### LEB4
Reducing ETH bond is a good idea. It's been the goal since before Atlas. This should be its own RPIP, and would likely achieve universal support. As this RPIP includes other things I view as having negative side-effects, **I do not support this RPIP**.

#### ETH Only Minipools
This RPIP envisions Rocket Pool ETH-only minipools. **I do not support this idea** for several reasons.

##### Community impact
My first reaction to the potential of ETH-only validators is that, sure, everyone that has avoided Rocket Pool so far will love it. Now that they've "made the right call", and waited out the DAO to make this change, they can hop on board for the juiced yields, never really supporting the DAO or development at all. So, the deposit pool draws down to some unknown extent, and no value acrues to the protocol token to help fund the DAO and team, due to the removed RPL stake.

Previous and current Node Operators could, by extension realize they made the wrong call, by supporting the protocol via the RPL stake. They should have exited and sold their RPL bags, perhaps moved to other LSTs in the meantime, and maybe come back (maybe not) when this change gets made. If you also consider that the pure ETH commission is going down by 75% in the [UVC change](https://github.com/rocket-pool/RPIPs/blob/main/RPIPs/RPIP-46.md) (14% to 3.5%, if passed), while the ETH commission has likely been the thing keeping some operators around, existing operators might wonder if they're wanted much anymore. If current operators leaving the protocol is seen as acceptable or desirable by the proponents, in pursuit of new NOs, I think this is reason enough to reject it.

It's long been in the discord /support template about RPL, and explained this way to newcomers, that it's the price of accessing the ETH commission on the borrowed ETH, and helps fund the protocol. This makes sense, and is worthwhile. I don't see why we should stop requiring real support of the protocol, when we have required it of every operator to this point.

There could be a FUD campaign by various actors in the space to point out, loudly and often, that the protocol had it wrong all along, the design financially injured participants for the past year, and they're trying to undo the original 'damage' to 'save themselves', or something along those lines.

In addition, because of the points made above, and the points on operator set makeup below, it could materially change the nature of the Rocket Pool community itself.

##### Decentralization impact
This change will attract large staking operators like a magnet. It is a known fact that some entities are not able to have RPL on their balance sheet in size, and others just wouldn't want to. This is part of what has cultivated and maintained the Node Operator makeup that we have. I believe this is a critical differentiator for Rocket Pool, and is often used as a marketing point to demonstrate Ethereum alignment by having 3000+ independent operators. We're widely known as the most Ethereum aligned, distributed, decentralized, largely independent Liquid Staking Protocol in the ecosystem. It may be one of the reasons that rETH tends to have a small premium. If our Node Operator set became largely served by industrial staking providers, what I see as special about Rocket Pool would begin to fade, and I'd start looking more closely at serving other protocols.

If we do this to compete with other more centralized players, we risk becoming an extension of the same players, driving more stake into the most well capitalized, playing into the worst criticisms of proof of stake consensus. Some think that Ethereum staking generally, and even Rocket Pool specifically, will eventually be served primarily by large staking operators. That may or may not be the case, but I don't think we should basically encourage that scenario, by making this change. Yes, Houston allows for pseudo ETH-only validators with stake-ETH-on-behalf-of, but you can say the same about Rocket Split. Someone is still staking RPL protocol fee.

Further, assuming large staking operators do come onboard for the juiced yields, it could easily and quickly remove the ability for other smaller operators to help Rocket Pool scale. It's easy to envision larger operators to queue minipools or at least use bots to queue, which only marginally drags on their profits. If / when rETH demand levels out, it's a smaller hit for a large operator to stay queued for months as compared to an independent operator.

In addition, I'm wary of the second major change for RPL in less than a year. You can theorize and model what people should do given some change, but uncertainty creates risk, and people value that risk differently. I'm sure that there are some that have de-risked due to RPIP-30, and I suspect more may de-risk, or de-risk further with a second massive change so soon. The DAO can easily be perceived as not knowing where they're going by having to make a second course correction so soon. Value could start accruing to RPL beginning from a much lower level than today.

#### Minipool bonds < 4ETH
**I do not support this as part of this RPIP.** First because it's connected with ETH-only validators. The combination of these two make it worse than the sum of the parts. 4ETH bonded ETH-only minipools are bad enough, 1.5E bonds would allow industrial staking providers to swamp a huge amount of protocol ETH. A single large staking entity could migrate half of their current natively staked validators and create over 100,000 1.5ETH minipools, lifting over 3,000,000 rETH by themselves. Is that what we want?

Second, as previously mentioned, we should move smaller levers first, and observe, and not move many levers at once. Implement LEB4, observe, adapt as needed.

If, 12 - 18 months from now, we have Megapools, LEB4 and NodeSet, with rETH demand, and we still need to scale Node Operator ETH, I would support bonds lower than 4, while retaining RPL stake.

### 2. [Megapools - RPIP-43](https://github.com/rocket-pool/RPIPs/blob/main/RPIPs/RPIP-43.md)
I thought this was already kind of on the roadmap for Saturn, and is a huge benefit for everyone involved in Rocket Pool. We've recently learned that EIP-7521 (MAXEB), will be included in Pectra. This likely impacts the design of Megapools to some extent.

**I support this RPIP** to implement Megapools. In my view, this work, as well as LEB4, should be prioritized above any other changes.

### 3. [Forced Exits - RPIP-44](https://github.com/rocket-pool/RPIPs/blob/main/RPIPs/RPIP-44.md)
Rocket Pool would ideally have forced exits for some time already. Having the ability to exit a validator would have allowed the rETH APY to be higher, by exiting chronically poor performers / abandoned nodes. Given, rETH demand is not the issue today, but it has been before, and it may be in the future.

Any specific functionality in Rocket Pool regarding forced exits requires EIP-7002. It is expected, as of early March 2024, that EIP-7002 will be included in the Pectra upgrade. The date for this upgrade is TBD, but soft expectation is already that it's likely early 2025, not late 2024.

**I support this RPIP** to enable protocol forced exits when EIP-7002 is on mainnet.

Note: NodeSet's Constellation protocol will have the ability to force-exit from day 1 via pre-signed exits, prior to EIP-7002, and likely prior to other upcoming competitive challengers, without any changes to Rocket Pool.

### 4. [RPL Burn - RPIP-45](https://github.com/rocket-pool/RPIPs/blob/main/RPIPs/RPIP-45.md)
This RPIP, dependent on [UVC - RPIP-46](https://github.com/rocket-pool/RPIPs/blob/main/RPIPs/RPIP-46.md), envisions essentially buying / burning an amount of RPL using a portion of all ETH commission on borrowed ETH (75% of the native ETH commission on borrowed ETH would be directed to this mechanism). Technically speaking, users / bots would exchange RPL for ETH stored in the burn contract. **I do not support this RPIP** for several reasons.

First, we're privileging those that have avoided RPL to this point, above those that have already been supporting Rocket Pool for some time. The best case scenario is for someone to wait at least until the vote looks likely to pass (but safer to wait until implementation), and only potentially buy RPL at that time. Those people (in theory at least), get immediate value acrual, while the saps that supported Rocket Pool for long before that, and potentially topped up multiple times, are still in a deep hole. Yes, they both gain at the same starting time, but the fact this drives value to plain old token holders is a slap in the face to those that have topped-up RPL, possibly multiple times, while supporting rETH, and still may not be receiving RPL rewards.

Second, take the Rocket Pool Node Operator that is here for the ETH commission, and has written off the RPL stake. Potentially as a donation to the team, or just figuring that they'll be running their validators for so long, that combined with the rewards they may have acrued in the good times, the support they've gotten via the community and the Smart Node, they prize the ETH commission above all else. Why should that operator be happy about reducing their commission by 75%, to funnel some of that to speculators, entirely outside of the ecosystem?

Additionally, this should be looked at (and has already been discussed by some), as a fee switch. The DAO should consider whether and how much this exposes the protocol to additional regulatory scrutiny. Recently, everyone was hyped up about Uniswap activating their fee switch, and distributing fee revenue to token holders. This idea was [recently rejected by the UNI DAO](https://cryptonews.com/news/uniswap-community-rejects-proposal-to-distribute-revenue-to-uni-token-holders.htm), largely due to concerns over regulatory / legal implications. I'm not a fan of the current SEC makeup, but we don't know how long that makeup lasts, or whether the next one will be any better. It could be argued that RPL then bears rights to the collective work of others. Let's just say that things have been called securities for less. It's unlikely that secondary purchases will ever be deemed securities (but that won't stop the SEC from trying again). Consider, however, when the team enters into an agreement with a new strategic partner and exchanges RPL, or when the GMC or IMC distributes RPL to an individual or team. Those could arguably be deemed to be not exchanges in the secondary market, and could find their way into an enforcement action.

Finally, combined with UVC, the implementation would definitely damage NodeSet, which many community members have been looking forward to, to help scale Rocket Pool, and provide more yield for their nodes, in a reasonably egalitarian manner. Knowing that NodeSet has been approached by other interested parties, and having poured the efforts they have into Constellation, it'd be reasonable to assume they may look to more stable protocols upon which to build. Some operators may follow them.

It's been said that how these changes impact NodeSet haven't been considered as part of the design of these changes. I think that's a mistake at this late stage. If the Rocket Pool DAO didn't want NodeSet, it should have made that very clear early on rather than, in effect, potentially rug-pulling near the finish line.

### 5. [Universal Variable Commission - RPIP-46](https://github.com/rocket-pool/RPIPs/blob/main/RPIPs/RPIP-46.md)
When I first heard the concept of Universal Variable Commission, I thought it was to enable dynamically setting the Node Operator commission vs. rETH fee, in the case that we have too much demand on one side vs. the other. I'm generally supportive of that concept, where we could dial the Node Operator commission / rETH fee based on where the demand imbalance was. Given this RPIP includes devoting some commission to RPL buy/burn, **I do not support it as written**, see the RPL burn section, above.

### 6. [Remove operator-gated upgrades - RPIP-47](https://github.com/rocket-pool/RPIPs/blob/main/RPIPs/RPIP-47.md)
I don't have a strong reaction to this. I believe for a long time we'll still have some 16E and 8E minipools hanging around, they can, in fact run for the life of Ethereum. If we were to remove support from the Smart Node for older minipool delegates, that would likely be pretty effective at encouraging upgrades, but still not entirely require them. Certain software will have to take them into account for a potentially long time. I'm not sure how much this moves the needle, but I'm not opposed.

### 7. [Lower minipool requirements - RPIP-48](https://github.com/rocket-pool/RPIPs/blob/main/RPIPs/RPIP-48.md)

As of 3/23/2024, there is a [draft change](https://github.com/Valdorff/RPIPs/commit/36534b1e0ad2e9e6b4c133b4879815cd7f888a32) that withdraws this RPIP, as the ideas are subsumed within RPIP-42.