Further to this we have put together an indicative roadmap release schedule. Although we are proposing 3 options and require direction from the community.
The DAO approved next deliverables are defined in RPIP-56 Upgrade Information Saturn 2. Since this was approved several items have been raised as potentially important to the protocol.
These include:
rETH redemptions through EIP-7002
rETH yield protection from under-performing node operators
These components are to be defined but deemed important to maintain the peg and raise rETH yield performance.
Essentially, it depends on priority and timing. We can batch up the changes (option 3) and save time on a consolidated launch or we can aim for a smaller initial release to deliver features earlier.
I am leaning towards rETH improvements followed by Saturn 2. Deliver meaningful changes step by step. Option 2.
I can easily be swayed to prefer Saturn 2 then rETH by those who are far deeper in the potential impact than I am. “Whatever is likely best for RocketPool and attracting stake, and improving liquidity”.
I am feeling very cautious about bundling the two. Timelines slip, piling changes on top of changes makes them slip harder. So I don’t know that it actually saves two months, or that shipping more, but later, is best for RocketPool.
Thanks langers and team. Similar to yorick above, I’m in favor of prioritized focus on rETH updates to give users and holders a better experience first and foremost. I believe this is urgent given the sentiment, feedback and overall environment we’re in.
I’m also in favor of option 2 (or option 1). For the protocol, I think it is best if we restore the peg and protect for underperforming nodes first to create more rETH demand. Then Saturn 2 will follow.
Not in favor of combining rETH updates and Saturn 2, since the risk for delays will be much higher.
I’m leaning towards roadmap 2, but i’m willing to be convinced other paths are better.
Improving rETH would be a bigger unlock than Saturn 2, I think. Also, it should allow us to increase rETH attractiveness which can be used for Saturn 2.
Option 2. Saturn 1 will open up ±600k staked ETH supply just from migrations. rETH demand has been unfortunately lagging after Saturn zero, so dedicated focus on improving that experience comes next. If we somehow saturate rETH supply, Saturn 1 still gives us the tools to drive value to NOs. I think it will likely be a while before we need the capital efficiency of saturn 2 (although other parts are nice).
Rpip-44 (what langers calls “Forced Exits”), only specifies forced exits when a node operator owes the protocol.
Rpip-71 would handle the case where a node operator hasn’t done anything wrong, but rETH users want to withdraw their ETH and the protocol force exits validators to meet their request
Thank you @langers for the insight. I prefer option 2. Currently rETH needs more holders and DeFi utility, offering better peg compared to our competitors will help attract more rETH holders while we continue to create rETH markets on chains such a Ronin and Unichain.
I think after Saturn 0 the market has demonstrated a lack of rETH demand which is the bottleneck for growth, so approaching from scratch I would say anything that helps improve rETH demand is what should be prioritized (especially since Saturn 1 will further increase supply, and then even more so with bond curves in Saturn 2).
This makes option 1 the least preferable to me since it would be the longest delay for rETH improvements
Looking closer at Saturn 2:
rpip-42 Bond Curves (remainder), should just be a single parameter change? (“Update reduced_bond to 1.5 ETH”). I think the reason this was left for Saturn2 had more to do with that it depends on rpip-44 (forced exits) for safety from MEV-theft rather than the amount of work it would take to implement (updating a single parameter).
rpip-45 / rpip-50 (and updating rpip-46 remainder to account for these): may not end up being approved (if “voter share only” wins, then the only thing left here is changes to RPL issuance (remove node operator RPL rewards)… so this would also be very light. Obviously if buy+burn or buy+LP is voted for that increases the scope of work. My guess is that “voter share only” is what wins but the DAO still needs to vote here.
I think that leaves the bulk of the work for Saturn 2 to be rpip-44 (forced exits)…
I’m not sure yet if rpip71 (rETH withdrawal liquidity via eip7002) or rpip73 (written as rpip-TBC: rETH protection from under-performing nodes), will depend on rpip-44 (or at least overlap on some features so that they would all have to be shipped together anyways). I had assumed at least rpip73 would require rpip44 https://github.com/rocket-pool/RPIPs/pull/348, but this is just a first draft that needs refinement / discussion
I think this topic needs further attention to help decide on the roadmap (this would interfere with “Option 2” as you have written it out)…
I think that leaves me preferring Option 3:
I don’t think the scope of Saturn2+rETH improvements is that much larger than just rETH improvements only (especially if rpip-44 has to be bundled with the other rETH improvements). So mainly I think I would question whether Saturn 2 in option 3 would actually take 3 months longer (eg, jun2026) than option 2’s rETH updates (eg, apr2026) to ship?
If you do think rETH updates (rpip71/73) by themselves could go to mainnet 3+ months faster by themselves as a standalone upgrade compared to bundling it in with the rest of Saturn 2, then I think it could be worth preferring Option 2. (And this assumes rpip-44 can be unbundled from rpip-71/73)
I’m sort of where Samus is. My preference is actually not in the listed options, but rather a hybrid of mostly #3 with a dash of #2 thrown in. Meaning, retool the the next steps in terms of the harder and easier parts of Saturn 2 and mix the easier parts in with all the rETH improvements AND forced exits. Then save Saturn 2 stuff like buy & burn (if it is going to happen, which I also doubt) for after.
im with Samus here. If there is really a big time benefit from going with 2# then im for that. but if low hanging fruits of 3# can be logically bundled in a way that has minimal additional time requirements, then im for 3#.
My vote is option 2, focus on rETH updates first. To grow the protocol, making rETH the best product it can be is essential. Saturn 1 already provides enough additional runway on the node operator side for now.
I get the temptation to look for additional low-hanging fruit here, but would be wary of scope creep. Releasing in small and focused increments is valuable.
Option 3 (the full combination) should not be done IMO. Saturn 2 brings additional uncertainty because a DAO vote regarding UARS is required, and depending on its outcome, RPL Burn or RPL Buy&LP would still have to be specced out further as well. This means timeline estimates for Saturn 2 are less certain / predictable than for the rETH updates, and this uncertainty would spill over to the combined release.
