Saturn 2 Scoping — Community Discussion

Governance
1

Saturn 2 Scoping — Community Discussion

With Saturn 1 live, it is time to define what comes next. During the roadmap discussion, the community signalled a clear priority: strengthen rETH demand.

Goals

Saturn 2 focuses on two concrete outcomes for rETH holders:

  1. Protect rETH yield - Shield rETH from underperforming validators so that the product remains competitive and attracts further demand.
  2. Streamline rETH withdrawals - Defend the rETH peg during periods of volatility and lower the barrier for conservative allocators, including institutions.

Proposed Scope

The following RPIPs are proposed for inclusion in Saturn 2.

RPIP Title Rationale
RPIP-42 Bond Curves (1.5 ETH + pDAO param) Lowers the capital barrier for node operators, increasing validator supply and improving rETH capacity.
RPIP-44 Forced Exits Enables the protocol to remove validators when the megapool has significant debt/penalties.
RPIP-46 Universal Adjustable Revenue Split (inflation change) Reduces RPL inflation
RPIP-71 rETH Withdrawal Liquidity via EIP-7002 Makes rETH withdrawals more reliable, strengthening peg stability.
RPIP-73 rETH Protection From Underperforming Nodes Identifies and exits underperforming validators, protecting rETH returns.

Deferred RPIPs

The following RPIPs are valuable but are proposed for deferral so that Saturn 2 stays focused on rETH demand. They remain on the roadmap for a future release.

RPIP Title Reason for Deferral
RPIP-45 RPL Burn Important for RPL tokenomics, but not directly tied to the rETH demand priority identified by the community.
RPIP-50 RPL Buy & LP Same rationale — better served by dedicated focus in a subsequent release.

Next Steps

  1. Community feedback — Share concerns, questions, or suggestions in this thread. If you believe an RPIP should be added, removed, or re-prioritised, make the case.
  2. RPIP refinement — We will work with authors and the community to update the included RPIPs and seek the necessary governance approval.
  3. Internal workshops — In parallel, the team will begin scoping workshops to define implementation details and surface technical design.
7 Likes
2

Thank you for kicking off this discussion. I also started to look at this last week and broke it down based on the governance status:

Saturn 1 Leftovers

So RPIP-49 has this section that calls for work and votes to happen before Saturn 1. That didn’t happen… I think a Saturn 2 RPIP should either address those outstanding points or state that we decided to delay/remove them entirely.

Saturn 2 Surplus Share Strategy

We wanted to figure out Burn vs. Buy & LP vs. nothing. I agree that this appears less pressing now and we should defer here.

Penalty System

We wanted to research and ratify a mev penalty system. With how mev has been going the last few years, this also appears less pressing now. But I worry that we keep pushing this off indefinitely and that mev could become a problem at some point.

This also relates to the voted on RPIP-44, see below.

Node Operator Commission

Increasing the deposit pool maximum effectively removed the control the security council has over node_operator_commission_share. RPIP-72 also added a pdao_share to UARS. With limited rETH demand, lowering overall commission may become a conversation. Overall it seems that figuring out when and how to adjust UARS deserves more attention.

Already voted on (RPIP-49)

Lowering Bond after Second Validator to 1.5 ETH (RPIP-42)

I think we should revisit this. For the protocol, we prefer people to move from minipools to 4 ETH megapool validators over people on megapools going from 4 ETH to 1.5 ETH. We may not have the rETH demand to support the former by Saturn 2, I don’t think this was clear at the time we voted on this.

Remove RPL Rewards for Node Operators (RPIP-46)

This seems ok.

EL triggered exits

RPIP-44 is mostly about voluntary exits from the node operator or exits in case of MEV theft. Without the work on the penalty system above, scope could be reduced here.

Ideas without Vote

In addition to using EL triggered exits for bad performers and withdrawal liquidity that langers mentions, I want to also look at:

Faster withdrawal credential exploit check

Saturn 1 removed the oDAO scrub check duty and replaced it with a beacon state proof. With the current proof, this means that the second 31 ETH deposit for a validator can only happen once the first 1 ETH deposit made it through the beacon queue. Depending on how the beacon queue develops going forward, we may want to look at speeding this process up, which may be possible with a tweaked proof.

pDAO Settings Guardrails

The Saturn 1 audits introduced a number of new guardrails on pDAO settings that now clash with what is specified in the RPIPs. I think it would be good to collect the actual values used in one place together with an explanation of why they are necessary. This could just be an informational RPIP that extends the parameter table in RPIP-33. If there are any values that seem unnecessary or problematic, cleaning that up would require a vote.

How can community get involved?

I am interested in contributing to the design and RPIP process here. I know that @haloooloolo also expressed interest in contributing on at least the forced exit stuff. How can we coordinate with the team on this? What does the team want to do internally and what do you want to leave to the community? How can we make sure that we don’t duplicate efforts, especially with regards to those internal workshops you mention?

12 Likes
3

Basically, Yes

This is very much going in the right direction, so it is all very encouraging.
First and foremost, the team and the community must:

  1. Start this off in general alignment
  2. Be aware of any major resistance to one of these issues that any party has
  3. Clearly communicate how team/community will integrate in this process
    • Will team workshops be summarized frequently to the community?
    • Will community discussions involve and be monitored by the team?

We want to avoid late in the game surprises as to where the parties stand and what they have been working on.

Specifically to the Roadmap

rETH

This potential roadmap accurately identifies that rETH redemptions and exits for poorly performing validators are a primary concern. @Butta tweeted out numbers today that are embarrassing for Rocket Pool in terms of efficiency. This is no longer acceptable, as far as we can control it, anyway. I’m not just talking technical fixes, but also communicating to the community that poor performance is not your right as an RP operator.

If we are aware of other resistance by institutional stakers, especially knowledge from RockSolid and @signalxu, we should consider what we can of their input. If this includes finding third parties that can help where we have troubles, we should consider that.

RPL

Some larger scale RPL fixes are justifiably set to the back burner. All the work put into it was not in vain, it was important to understand nuances in our tokenomics, but we should address that we are kicking that can down the road in the RPIPs on Buy & Burn vs LP etc.

Inflation reduction seems an easy proceed with the caveat that we might want to adjust to provide some more inflation to the pDAO rather than just removing the full NO share. When migrations are sufficient, there are other possibilities in regards to shifting RPL rewards around, as well.

1.5 ETH bonds

This is part of the plan, I suppose. I wouldn’t want this to hold up any of the above work or a deployment of the above work. This feels like a Saturn 3 thing to me, really. If it’s easy to put in and not turn on, yet, maybe. But do we want people able to go down to 1.5 any time soon? Not sure.

knoshua’s withdrawal credential proofs

Even if we don’t get bitten by a long queue again, it feels like this is a correct fix to make. Guardrail revisit, as well.

Summary

Communication is key on these issues. rETH full speed ahead.

9 Likes
4

I would not lower the bond to 1.5 ETH. There are many node operators with minipools that are not migrating to a megapool because there is not enough rETH demand.

Enabling 1.5 ETH would probably discourage this migration even more.

I don’t have a strong feeling about RPL buyback/burn but I would say to still include it. Or if it’s going to delay the rest too much, give a bigger portion of the RPL inflation to the IMC/GMC. They are always running low on funds.

1 Like
5

I agree we should be explicit that it was part of the plan but ratifying X RPIP defers those RPIPs. Maybe update the Informational Saturn 2 RPIP (RPIP-56) with that decision?

I believe this has a dependency on ePBS included in Glamsterdam. From my research so far, we still have the fee recipient issue with ePBS but it detection is more consistent and chain based. Looks like it is in devnet stage at this point: Glamsterdam Upgrade - Forkcast

I agree that we shouldn’t keep deferring but I would like to see ePBS be available first. It might be worth doing initial design but my feeling is it is mostly spec/watchtower work? Unless we want verifiability in which case it would be a larger scope.

I am not sure why this is the case? Sorry missing something.

Agreed.

I am really hoping that the queue length is transitive and it resolves. Certainly, if it looks like the new normal we should address this. One aspect that gives this more weight is RPIP-71. If we are exiting node operators for withdrawal demands, it would soften the impact if the UX was more streamlined.

Good idea. As part of this scoping, I will include an RPIP for parameter guardrails.

Fantastic! These are my thoughts on coordination:

How can we coordinate with the team on this?

  • Initial high-level scoping in this post discussion
  • For specific RPIP meta changes, we can discuss these in the #governance Discord channel
  • For design discussions and technical aspects of the RPIPs, we can create threads in the #research Discord channel

What does the team want to do internally and what do you want to leave to the community?

We will have internal workshops to thrash out ideas but our intention is to disseminate design concepts and questions to the #research Discord channel, for community feedback.

It is hard to tell what areas should be carved out yet but open to suggestions

How can we make sure that we don’t duplicate efforts, especially with regards to those internal workshops you mention?

Having a central place to talk about the different RPIPs is important for coordinating.

For example, if we have a thread per RPIP in research we can review what each party has discussed and all get on the same page. That worked well from my point of view last time.

2 Likes
6

Saturn 2 Scoping — Forum Comment Draft

An rETH-First Framework for Saturn 2 Scoping

Thanks @langers for kicking this off and to @knoshua, @drdoofus, and @Kevster.eth for the thoughtful discussion so far.

I want to offer a structured analysis of the proposed scope using a single organizing principle: rETH attractiveness is the protocol’s growth engine, and Saturn 2 should prioritize it above everything else.

Without rETH demand, there is no borrowed ETH, no commissions, no voter share, and no RPL value accrual. Every scope decision flows from this.

The Five Dimensions of rETH Attractiveness

  1. Yield — Competitive returns vs stETH/cbETH

  2. Peg Stability — rETH trades at or above NAV during volatility

  3. Safety — Protection against slashing, underperformance, MEV theft

  4. Liquidity — Easy entry and exit at fair value

  5. Trust — Decentralization narrative, institutional confidence

Every proposed RPIP should be evaluated against these dimensions.

The Core Three: Ship These Together

RPIP-73: rETH Protection From Underperforming Nodes

Highest priority. This directly addresses rETH yield — the most visible metric that institutional and retail holders compare against competitors. As @drdoofus put it, the current performance numbers are “embarrassing for Rocket Pool in terms of efficiency.”

If a tail of underperforming validators consistently drags down aggregate rETH returns, the decentralization narrative alone won’t drive adoption. rETH needs to be competitive on yield and decentralization, not one at the expense of the other.

rETH dimensions served: Yield, Safety, Trust

RPIP-71: rETH Withdrawal Liquidity via EIP-7002

Co-priority with RPIP-73. This is potentially the most transformative change for rETH’s competitive positioning. Currently, rETH redemptions depend on: (a) the withdrawal buffer having sufficient ETH (~1% of TVL), or (b) node operators voluntarily exiting. If neither works, rETH trades below NAV.

EIP-7002 allows the protocol itself to trigger validator exits to refill the buffer — making rETH trustlessly redeemable at NAV. This will be a key distinguishing feature of rETH that can serve as a key marketing point and is almost certainly the #1 concern for institutional stakers evaluating the product.

rETH dimensions served: Peg Stability, Liquidity, Trust

RPIP-44: Forced Exits

The enforcement mechanism. RPIP-73 identifies underperformers; RPIP-44 removes them. RPIP-71 needs protocol-triggered exits to refill the buffer. Without forced exits, both are toothless. This is infrastructure that enables the other two.

rETH dimensions served: Safety (infrastructure dependency)

Why These Three Create a Virtuous Cycle

  1. RPIP-73 improves rETH yield → rETH becomes more competitive

  2. RPIP-71 removes peg risk → institutional adoption grows

  3. More rETH demand → more borrowed ETH → more commission + voter share

  4. Higher NO earnings → more NOs join → more decentralization

  5. Eventually demand outstrips supply → then bond reduction becomes relevant

This is the flywheel. Saturn 2 should focus on getting it started.

RPIP-42 (1.5 ETH Bonds): Defer to Saturn 3

I agree with @knoshua, @drdoofus, and @Kevster.eth here. The case for deferral is strong:

1. Supply without demand is waste. Saturn 1 already dropped bonds from 8 to 4 ETH. If rETH demand hasn’t filled the 4 ETH queue, adding 1.5 ETH capacity solves a problem we don’t have yet.

2. Discourages legacy migration. As @Kevster.eth noted, many operators with legacy minipools aren’t migrating to megapools because there isn’t sufficient rETH demand to justify the move. Dangling 1.5 ETH bonds incentivize them to wait rather than migrate now — further fragmenting the operator base.

3. Increases risk per validator. A 1.5 ETH bond means 30.5 ETH borrowed per validator — a 20:1 leverage ratio. Less skin in the game per validator weakens the safety guarantees that rETH holders depend on.

4. Engineering bandwidth has higher-value uses. Every sprint spent on bond curves is a sprint not spent on RPIP-73 or RPIP-71. The opportunity cost is significant.

When 1.5 ETH becomes appropriate: Once rETH demand consistently fills the queue and NOs are waiting for assignments, then lower bonds expand real capacity to meet real demand. That’s a Saturn 3 signal, not a Saturn 2 one.

Include (Lower Priority)

RPIP-46: UARS Inflation Reduction

Less RPL inflation reduces sell pressure, which supports healthier governance token economics. This is second-order for rETH (holders don’t directly feel RPL inflation), but it’s likely a smaller scope and complements the core work. Include as capacity allows.

pDAO Parameter Guardrails

Both @knoshua and @drdoofus flagged this. Documenting and enforcing guardrails for pDAO-adjustable parameters (such as the 5%/9%/86% UARS split) protects rETH holders from governance mistakes. Low implementation cost, high trust benefit.

Withdrawal Credential UX

Faster withdrawal credential checks streamline NO onboarding. More NOs joining smoothly means more rETH capacity in the medium term. Especially if this synergizes with RPIP-71 work, as @langers suggested.

Deferred RPIPs: Correct Calls

RPIP-45 (RPL Burn) and RPIP-50 (RPL Buy & LP) — These are important for long-term RPL tokenomics but are not rETH-facing. The deferral is correct under an rETH-first framework. That said, I’d echo @drdoofus’s point that we should explicitly acknowledge this is kicking the can and commit to a timeline rather than indefinite deferral.

Don’t Forget: MEV Penalty Research

@knoshua is right that MEV theft is a latent risk to rETH yield. The dependence on Ethereum’s ePBS (currently on the devnet in Glamsterdam) is real, but “indefinitely deferring” research is dangerous. The pragmatic path: start spec/watchtower work now so we’re ready to deploy when ePBS lands. Don’t block Saturn 2, but don’t ignore it either.

Institutional Feedback

Strongly agree with @drdoofus that institutional stakers (RockSolid, signalxu, and others) should be consulted early. Their feedback will almost certainly reinforce the priorities above — yield competitiveness and peg stability are table-stakes requirements for institutional adoption. Better to hear their concerns now than discover them post-launch.

Summary: Recommended Saturn 2 Priority Stack

| Priority | Item | rETH Dimension |

| 1 | RPIP-73 — Underperformer protection | Yield + Safety |

| 2 | RPIP-71 — EIP-7002 withdrawal liquidity | Peg + Liquidity + Trust |

| 3 | RPIP-44 — Forced exits (enables 73 + 71) | Safety infrastructure |

| 4 | pDAO parameter guardrails | Trust + Governance |

| 5 | RPIP-46 — Inflation reduction | RPL health (indirect) |

| 6 | Withdrawal credential UX | NO onboarding |

| Research | MEV penalty system | Yield protection (future) |

| Defer | RPIP-42 — 1.5 ETH bonds | Premature without rETH demand |

| Defer | RPIP-45 — RPL Burn | Not rETH-facing |

| Defer | RPIP-50 — RPL Buy & LP | Not rETH-facing |

The protocol’s future depends on making rETH the best liquid staking product on the market. Saturn 2 should be laser-focused on that goal. Supply expansion (RPIP-42) and RPL tokenomics (RPIP-45/50) are important — but they’re Saturn 3 problems that become easier to solve once the rETH flywheel is spinning.

3 Likes
7

I think this should be a vote rather than just updating an informational RPIP. Kind of like we had RPIP-49 for Saturn 1 that summarized everything and those outstanding could be part of that.

You are right, ePBS/Glamsterdam seems relevant here. Verifiability (and therefore independence from oDAO) seems like another nice-to-have that we may want to de-prioritize for this upcoming upgrade so that we can address the more pressing issues faster. Agree that we are then looking at spec/watchtower work only and we may want to focus on the other things that need smart contract work first.

I didn’t put that very well, sorry. I just meant to say that we shouldn’t expect security council to act based on what RPIP-46 specified:

The security council SHOULD increment node_operator_commission_share_council_adder by 0.5% if the deposit pool is over half-full for the majority of a 2-week period

Since RPIP-78 increased the deposit pool maximum to 6 million ETH, this now means that we would need on average 3 million ETH in the deposit pool for 2 weeks for anything to happen.

Agreed. I think it makes sense to work a bit on design but stay very open to defer/drop it depending on how queue length goes and how complex of a change it looks to be. I will start a #research thread on it later this week.

Yep, all sounds good on coordinating between team and community.

2 Likes
8

Prioritize rETH demand above all else.

Unless trivial to develop and implement, defer Burn or Buy and LP.

Defer 1.5 ETH bonded validators until rETH demand is fixed or until the vast majority of minipools successfully close exit.

1 Like
9

Thx @drdoofus for the ping to post here. We laid out our priorities in DIscord a while ago: Discord

I think @ken’s post pretty much nailed it on the technology front.

I’ll just add one thing. Force exiting underperforming will help rETH APR and combining that with force existing to free up withdrawal liquidity are both EXCELLENT.

BUT, I don’t know where the APR actually lands after those… I think the DAO should do whatever it takes to get the APR >= 0.1% better than stETH for a 6 month period. As soon as rETH has a more favorable spread, it will attract a LOT of minting demand from loopers.

With my node operator and RPL holder hat on, I would take 0% commission for 6 months to light a fire under rETH demand.

2 Likes
10

Great summary of priorities with clear linkages to the key factors that underpin rETH value and demand. I’m supportive of what you’ve laid out, and it looks consistent with what most folks have posted so far.

11

I 100% agree with this sentiment.

12

I’ll give you a few insights and points to discuss from from the average-Joe node operator POV.

I switched to Rocket Pool from solo-staking in January 2024 after running a single minipool since July 2023. To cover RPL cost, I swapped quite some ETH to RPL, mainly believing the rewards calculator on Rocket Pool’s website. RPL price was at ~0.012 ETH back then, so over 10 times higher as it’s today. I guess there’s no need to have the discussion that the tokenomics and the assumption, stakers would just buy more RPL to keep the collateral limit up with RPL price going down, was mad then already. Anyway, it didn’t take long for me to lose any RPL staking rewards as the RPL price was dropping and I didn’t had funds to cover additional RPL. So effectively, my yield was shrinking. The staked RPL on my node were dead capital. No way out without exiting.

Fast forward, Saturn 0. RPL price now is at ~0.0041 ETH. But, Saturn to the rescue! Let’s drain the deposit pool, get RPL staking rewards for everyone back and kick off long discussions on Saturn 1 and 2 to solve the tokenomics issue long-term. RPIP 45, 46 and 50 looked promising to me as there’s a long-term strategy to get RPL price back up.

Now, after we launched Saturn 1, the situation looks, well, not that nice to me:

  • RPL price currently is at ~0.00093 ETH, so the RPL I swapped from ETH to enter Rocket Pool is worth 92.25% less than it was when I started.
  • The protocol took away my RPL staking rewards soon after I started, leaving dead capital for months.
  • Since Saturn 0, RPL staking rewards are restored, but are planned to be phased out over the next months to “incentivise” me to switch to Megapool validators. The thing is: there’s no reason for me to switch to a Megapool right now, as I’d only be filling the Megapools of others by exiting my Minipools. I’d be left with no validators at all (or dead capital in the queue). This leaves me in a tricky situation: I can’t swap my legacy RPL to new RPL without a Megapool contract I’m not able to fund without the ETH from my Minipools.

Honestly: I feel a bit screwed over. Saturn was always promoted as the much needed “we fix the tokenomics!” upgrade, also including competitive features like lower staking bonds to compete with programs like Lido CSM. Saturn 0 basically sent RPL to hell, as there was only a very little incentive to buy the token while keeping the inflation. Don’t get me wrong: the filled deposit pool was a huge problem back then and it’s always better to cut off an arm to safe the body compared to dying. But a lot of Rocket Pool node operators are in the same situation as I am - stuck with RPL bought for a high price believing in basically DoA tokenomics. Was I naive to believe and just put my skin in the game? Probably. But the downsides don’t get discussed enough while rewards calculators and enthusiastically written Medium articles might transport a wrong impression.

I’m therefore quite surprised by the “Let’s defer the RPL fixes to… later” sentiment I get from this thread. I acknowledge that rETH demand has the highest priority right now, but without a fix for RPL, a lot of node operators get screwed over, as soon as the legacy RPL staking rewards stop, again. Even considering the second step of the bond curve to 1.5 ETH over fixing RPL feels like a slap in the face.

My priority list would therefore look like this:

  1. Focus on rETH demand to enable everyone to switch over
  2. Kick off final RPL tokenomics rework to be included in Saturn 2
  3. Forced exits (RPIP-444 and 73, there are a lot of good arguments already in the thread)

Things we can definitely defer:

1.5 ETH validators. As Kevster and drdoofus alredy pointed out, there’s not even nearly enough rETH demand to lower the bonds even further.

On a different note: the switch to Megapools with Saturn 1, considering the long exit queue, and actually getting your validators back, required quite scientific methods. That’s stuff you don’t read in the Medium article that launched a few days prior the upgrade. The article makes it sound as it’s an easy and done deal that you can switch to a Megapool after the upgrade without any interference. It leaves out the entire section that rETH demand basically needs to more than double, considering additional node operators coming in through the regular queue, before everyone could migrate over. I needed to do my own in-depth-research and annoy people on Discord to find that out, leaving me with quite a disadvantage as described above. Some people are smart enough to understand the background and needed actions to profit from the upgrade out of the box, but the average node operator like me doesn’t have the time and nerves to go through all that. What’s left for us is a Medium article that doesn’t include important stuff like this and can even mislead into a huge disadvantage. I don’t think that this was intentional, but still needs to be addressed. My day job is communications; I’m happy to help.

13

I think there is a disconnect here what a potential RPL burn or buy and LP does. It’s not fixing RPL tokenomics, it’s just changing them. There is no consensus at all that either is better than status quo for RPL tokenomics.

Status quo is that part of commission of megapools is distributed to node operators based on how much rpl they have staked, so this is node operator exclusive. RPL burn would mean that those funds are instead used to buy and burn RPL, which would benefit non node operator RPL holders as well. Arguably going to burn would be “screwing node operators over".

14

Thanks for your reply.
Saturn 1 went a long way to trying to fix what it could of RPL tokenomics by turning on the fee switch. It’s just that we need:

  1. more rETH for more megapools
  2. some megapools to actually get through the queue.

The entrance queue was not something that was foreseen, it popped up really at the very end just before launch and an entrance queue that huge hadn’t happened before. Your number 3 on your list, exits and those rpips, are what we hope gives us more rETH demand. So your #1 and #3 are the same thing.

As knoshua said, the parts of RPL being put off, LP/Buy & Burn were not necessarily going to help your RPL. Reducing inflation, which is being prioritized, is supposed to help RPL. You lose rewards but hopefully gain value since inflation dilutes the token value.

1 Like