RPIP-86: Saturn 2 Upgrade

Governance
1

Current Status

  • the dev team has reviewed and workshopped the RPIPs and sees no blockers
  • all of the RPIPs are in the main repo
  • Saturn 2 forum post and informal polls to gauge community sentiment and figure out vote structure (this post)

Next Steps

  • either iterate on RPIPs to get them to a place where pDAO is happy with them or start formal vote process

Abstract

This informational RPIP provides an introduction and overview of the Saturn 2 upgrade and its likely contents.

Saturn 2 is the second major phase of the tokenomics-driven roadmap, originally outlined in RPIP-49, and follows the Saturn 1 upgrade. Whereas Saturn 1 focused on deploying megapools, the first stage of Universal Adjustable Revenue Split (UARS) and other supporting mechanics, Saturn 2 is centered on three broad themes: protocol-level rETH liquidity, protection of rETH from underperforming validators, and adjusting protocol economics. It also includes some governance improvements.

This RPIP briefly describes the RPIPs that are planned or considered for inclusion in Saturn 2 and how they fit together. It also explains which components originally earmarked for Saturn 2 in RPIP-49 have been deferred, and why the pDAO’s position on them has evolved.

This RPIP represents the current state of an ongoing effort, and the final contents of the Saturn 2 upgrade are for the pDAO to decide and may differ from the set described here.

Overview

At a high level, Saturn 2 is intended to:

  • Provide protocol-level rETH withdrawal liquidity by allowing rETH holders to request withdrawals that automatically trigger validator exits when necessary, subject only to Ethereum’s exit queue.
  • Protect rETH yield from long-running underperformance by introducing an on-chain, permissionless mechanism to eject badly performing validators.
  • Include minipools in both of the above as far as possible by introducing a penalty system.
  • Increase megapool bond requirements so the protocol can reach a megapool-only state more quickly while still fairly treating node operators whose minipools may be exited to honor rETH withdrawals.
  • Reduce RPL issuance to 2.5% and end ongoing rewards for node operators.
  • Improve and extend the protocol in several smaller aspects: speed up the creation of new validators, enable pDAO spending of treasury ETH, and enable on-chain pDAO signaling votes.

The following items that were included in the original Saturn 2 scope of the 2024 Tokenomics vote will be deferred:

  • Lowering the bond requirement per megapool validator to 1.5 ETH after the second one.
  • Implement a more sophisticated revenue share model (e.g., RPL Burn or Buy & LP).

The sections below group the Saturn 2 components by theme and then summarize the individual RPIPs.

rETH Withdrawal Liquidity and Underperformance Protection

RPIP-71: rETH Withdrawal Liquidity via EIP-7002

Status: Draft; Not yet voted on.

The goal of RPIP-71 is to make rETH more attractive by giving a liquidity guarantee to rETH holders and minimizing the times of rETH trading below its peg. It defines a path for rETH holders to redeem rETH for ETH in-protocol, when validators are exited for that purpose, and how these validators are selected.

  • rETH holders can place their rETH in a withdrawal queue, at which point it stops earning rewards.
  • The withdrawal queue gets prioritized over new validators, and rETH burns outside the withdrawal queue.
  • When the rETH in the withdrawal queue reaches a threshold that justifies it, validators are exited.
  • RPIP-71 depends on RPIP-80’s exit-request framework.
  • In a first phase, the oDAO selects minipools, higher commission first, to align withdrawal liquidity with the desired transition to megapools.
  • In a second phase, megapool validators are selected in a trustless manner.
  • The pDAO still needs to decide on a concrete exit criterion for megapools. Options discussed so far include:
    • Lower RPL stake first
    • first in, first out
    • together with increasing bond requirement, exiting from megapools, the furthest below the bond requirement
    • biasing towards larger nodes
    • biasing towards not hitting the same node again

RPIP-73: rETH Protection From Underperforming Nodes

Status: Draft; Not yet voted on.

RPIP-73 introduces a permissionless on-chain challenge and exit mechanism for validators that perform significantly worse than expected over long durations. It focuses on protecting rETH yield by removing validators that are consistently offline or otherwise severely underperforming, rather than on one-off performance incidents.

  • Timely target attestation rate is used as a proxy for performance.
  • Anyone can challenge underperforming validators, and the correctness of challenges is ensured with proofs against on-chain beacon chain data.

Exit and Entry Infrastructure

RPIP-80: Exit Requests, Triggering Exits, and Minipool Penalties

Status: Draft; Not yet voted on.

RPIP-80 defines the common exit-request abstraction that underpins both rETH withdrawal exits (RPIP-71) and underperformance exits (RPIP-73).

  • Validators that ought to exit are first given an opportunity to do so via the consensus-layer exit route, without incurring gas costs. This process is expected to be automated via smartnode.
  • For validators that don’t respond to these requests in time, anyone can trigger an exit.
  • Minipools that cannot be exited instead incur a penalty each time they fail to respond to an exit request, providing an economic incentive to exit.
  • Accounting for ETH expected to exit, or already in the process of exiting, ensures we don’t exit more validators than necessary for rETH withdrawals.

RPIP-44: Integrating Execution Layer Triggerable Exits

Status: Included in 2024 Tokenomics Rework vote

RPIP-44 provides node operators with an alternative way to exit megapool validators from the execution layer without requiring the validator’s keys. It also enables exiting validators in case a megapool has debt from MEV penalties or a shortfall due to exited validators.

RPIP-79: Faster Withdrawal Credentials Check

Status: Draft; Not yet voted on.

RPIP-79 speeds up validator onboarding and removes the dependency on the entry queue for the second deposit, while still guarding against withdrawal-credential front-running in megapools. In the context of exiting underperformers (RPIP-73), this minimizes churn from replacing them with better-performing operators.

  • Currently, creating a megapool validator requires a beacon-state proof to verify that the withdrawal credentials are correctly set before the second deposit (31 ETH) can occur, which can only be done once the first deposit (1 ETH) has passed through the beacon chain queue.
  • Under the proposal, the design is flipped: A proof can be provided to show that the withdrawal credentials are set incorrectly.
  • If no such proof is provided within a reasonable time, the second deposit is allowed to proceed.

Economics

RPIP-49 originally framed Saturn 2 in terms of several tokenomics components: the remainder of the bond curve, RPL inflation reduction, and Universal Adjustable Revenue Split (UARS) completion, with the implementation of the revenue share strategy. Saturn 2, as described in this RPIP, maintains some of that scope but defers or reprioritizes other parts.

RPIP-46: Universal Adjustable Revenue Split

Status: Included in 2024 Tokenomics Rework vote. Partially implemented in Saturn 1; RPL inflation change targeted for Saturn 2, revenue-share decision deferred.

Saturn 1 introduced UARS with a configurable split of ETH commission between node operator commission, voter share (vote-eligible RPL), and rETH share, while extending RPL issuance rewards to all staked RPL… For Saturn 2, RPIP-46 specifies that:

  • RPL inflation is reduced to 2.5% per year, down from the historical 5%. (Initially RPIP-46 targeted 1.5% inflation. RPIP-81 changed this to 2.5%.)
  • RPL issuance rewards to node operators are eliminated. Voter share provides an incentive to stake RPL.
  • All RPL inflation is directed to the DAOs: 95% to the pDAO and 5% to the oDAO.
  • The outcome of a revenue share vote is implemented, potentially RPL Burn or RPL Buy & LP.

The RPL inflation-related changes are still planned for Saturn 2. The current view is that, at this point, rETH demand-related work has higher priority than implementing complex new RPL value-capture mechanisms, and that detailed revenue-share strategies can be revisited after the rETH-focused work of Saturn 2 is delivered.

RPIP-42: Bond Curves

Status: Included in 2024 Tokenomics Rework vote. Partially implemented in Saturn 1; parameter conversion targeted for Saturn 2, removing lowering of bond from Saturn 2.

For Saturn 2, RPIP-42 specifies that base_bond_array is converted to a pDAO parameter with initial value [4, 8].

RPIP-42 also specifies that reduced_bond is lowered to 1.5 ETH with Saturn 2. While this further improves the efficiency of megapools and is safe with the introduction of RPIP-44, it is unclear whether the rETH demand will be sufficient to support 1.5 ETH validators immediately. The current thinking is not to lower reduced_bond until there is rETH demand that justifies it.

RPIP-83: Increasing Bond Requirement

Status: Draft; Not yet voted on.

RPIP-83 instead proposes increasing the required node-operator bond for each megapool validator to 6 ETH. This change is motivated by the current lack of rETH demand, the desire to reach a “megapool-only” state sooner, and the goal of keeping our large node operator set intact with exits for rETH withdrawal liquidity under RPIP-71. Specifically, RPIP-83 specifies:

  • Require 6 ETH per new validator in megapools.
  • Allow node operators to top up their bonds to match the new 6 ETH-per-validator curve.
  • Megapool rewards are used to increase the bond below the bond curve rather than being paid out directly.

Governance

RPIP-82: Enable pDAO Spending of ETH and ERC-20

Status: Draft; Not yet voted on.

RPIP-72 introduced a pdao_share to UARS (set to 0) that will allow the pDAO to collect a share of the ETH earned by megapool validators in the future, but there is currently no way to spend such ETH in the treasury. RPIP-82 adds this functionality and also allows spending any other ERC-20 token in the treasury.

RPIP-85: On-Chain Signal Voting

Status: Draft; Not yet voted on.

The Houston upgrade introduced on-chain pDAO voting for parameter changes and treasury spending (RPIP-33), but the pDAO still relies on Snapshot voting for other governance votes. This RPIP lays the foundation for on-chain signal voting that, together with a voting frontend, will support arbitrary vote types, including weighted voting (used for IMC and GMC elections), ranked-choice voting, and approval voting.

RPIP-87: pDAO Parameter Guardrail Revisions

Status: Draft; Not yet voted on.

This RPIP updates the guardrails for several pDAO parameters to reduce systemic risk and increase flexibility for future governance decisions.

Possible Vote Structure

If the pDAO is generally happy with the proposals in their current form, we next need to figure out how to structure the votes on them. I’m generally a fan of having separate votes for separate topics, which in this case would mean having individual votes for each RPIP and each decision to deviate from the 2024 Tokenomics vote. This would currently translate to 11 separate votes.

Alternatively, if there seems to be broad consensus around most of the proposals, I could see having a few votes on the contentious parts before moving to a vote on the Saturn 2 package as a whole. For example, this could mean individual votes for:
- RPIP-71: Choice of megapool exit criterion
- RPIP-42/RPIP-83: lower bond to 1.5 ETH, keep at 4 ETH or increase to 6 ETH
- Include on-chain signal voting in the Saturn 2 package

We will definitely need the vote for megapool exit criterion. I am anticipating that the bond decision could be contentious. With RPIP-84 solving the Snapshot dependency in the short term, some people may feel like that on-chain signal voting is less of a priority. I’m open to add more individual items or entirely different ideas, see the poll below.

6 Likes
2

How deep are you into the topic? (Multiple Choice)

  • I’ve not read anything
  • I’ve read the above explainer (RPIP-86)
  • I’ve read all the RPIPs
  • I’ve read some of the discussion on Discord
0 voters
  • Votes are public.

How well would you say you understand the proposals?

  • Low level of understanding
  • Medium level of understanding
  • High level of understanding
0 voters
  • Votes are public.

If you’re struggling to get a grip on this after trying to read up on it, it’s more likely to be my fault than yours. I want to hear from you, either in the Saturn 2 thread, or via DM.

How are you feeling about the proposals?

(this is not a formal sentiment check that can trigger a vote)

  • Very positive
  • Fairly positive
  • Neutral
  • Fairly against (please comment)
  • Very against (please comment)
0 voters
  • Votes are public.

How should the Saturn 2 votes be structured?

(this is not a formal sentiment check that can trigger a vote)

  • individual votes for mentioned items + vote for Saturn 2 package
  • individual votes for some other items (please comment)
  • 11 votes for every new RPIP and every change from 2024 Tokenomics vote
  • something else (please comment)
0 voters
  • Votes are public.

I used @LongForWisdom Tokenomics Rework polls as a template.

1 Like
3

I’d vote for a package w/o RPIP-83 and separately for it.

I can’t see RPIP-83 as a clear win for the protocol and for me personally it can become a total disaster.

1 Like
4

Havn’t followed the scoping process too much over the last year. bit bummed that 1.5 eth pools and the revenue share model is out of scope now as those are the most flashy ones imo. but im sure there are good reasons?

everything else reads fine and as expected.

5

1.5 ETH validators are a way to scale the protocol to meet more rETH demand. The rETH demand simply isn’t there yet. Absent the demand, 1.5 ETH validators just mean that more people need to stay on minipools for longer and we really want to avoid that because that means they don’t contribute to revenue share and we can’t upgrade them. That said, bond is one of the things we’d vote on explicitly. And if the rETH demand shows up, we can always lower the bond with a simple settings change after Saturn 2.

Revenue share just didn’t seem like a priority for neither design/RPIP work nor implementation work. As long as we don’t have the rETH demand to allow transition to megapools, there is no significant revenue to share and how we do it doesn’t matter. So the idea was to focus on rETH and get those upgrades out sooner.

2 Likes
6

First - thanks for the work @knoshua. It takes a huge amount of self-motivation to get all these ducks in a row. :saluting_face:

Re the discussion on 1.5 vs 6: I think “do nothing” is probably the worst choice. I’d like to frame the thinking more between “keep the efficient 1.5 and increase reth share by reducing share to NOs/voters” and “increase to 6E to allow for and prioritize a large/diverse NO set”. This is akin to trying to stimulate demand vs trying to adapt to the current state of demand [note: as knoshua says below, it moves in that direction but the current demand is still insufficient]. I’m not fully settled in my thoughts here, but I do think the general LST softness at the moment leans me towards the latter.

2 Likes
7

I think that framing makes sense, though we need to be clear that with current level of demand 6E still doesn’t work. Adapting to current state of demand would be increasing to 8E (or even more to account for 16E minipools), so I view 6E more like adapting to a more achievable, but still significantly higher demand.

2 Likes
8

I will not vote for rpip-83. Its just as bad as EIP-8361. All it will do is slow down the transition to megapools. All it would make me do is keep my minipool and withdraw my megapool. I’ll wait in the queue anyway.

9

Since we’ve already voted in bond curves last year, I see RPIP-83 as a complementary temporary measure and I am in favor of it if that’s the case. As an NO it feels bad but I still have not used my express tickets due to the massive queue.

Either way, from a cursory read it seems that the other rETH improvements in this package will ease the transition to megapools. I feel like the worst thing for the protocol at this point would be another hotly contested split like the pETH/nETH debate.

1 Like
10
RPIP 71:

The oDAO SHOULD select minipools by prioritizing higher-commission minipools and SHOULD ignore any minipool that has received a did_not_exit_penalty within the last did_not_exit_cooldown (defined in RPIP-80).

I think this is probably not appropriate. Commission is frequently node clustered, and this language means that all minipools of multiple nodes will be exited before other nodes are even touched. When making a change in the tokenomics i think as much as possible the negative effects should be spread as widely as possible.

Additionally, exiting 14% minipools before 5% minipools also means that a large amount of RPL that would be previously locked will be free- since there would be no way to make new megapool validators i assume this will be sold; that has negative impact.

Additionally, you will have to exit >two 20% validators for every 14% validator, so loss of TVL is going to be more than double. The marginal benefit of 20% vs 14% is not worth it.

All this is to say, I think exiting higher commission minipools is marginally better, but not enough to be picking winners and losers when making tokenomic changes.

I stand by (the unpopular argument) that I think megapool and minipools should both be eligible simultaneously, because megapools are a very small group of NOs (who tend to be elite in RP in some way), and specifically protecting them from negative repercussions risks appearance of non-neutrality. Additionally, less TVL needs to be removed per rETH for megapool vals.

The oDAO MAY use time until the next validator sweep as a tie-breaker between minipools with equal commission.

I can see why you would suggest this. However, to me it is possible this can be gamed by the oDAO, and also runs afoul of potentially exiting all minipools/megapool vals of a single node (many created at one time so would be grouped in validator sweep). The benefit is relatively marginal (a few days) and not worth risking concentrated negative repercussions of this vote.

Exit Hysteresis

This is currently targeted at rewards ~5 days; i would increase that. The token can always be sold immediately, and I think an amount above breakeven makes sense.

RPIP 73:

I think this is great. Overall, the tactic of the RP releases has been to trust NOs to make financial decisions in their own best interest; this has not been incredibly effective. Exiting NOs for performance is definitely less desirable than NOs improving performance. I think this would be a good place to request the RP team to prioritize additional notification options that are done more simply/seamlessly through smartnode, to avoid churn, bad feelings, and diminished decentralization.

The other small question is whether there should be an upper guardrail on the performance threshold- is there any theoretic time when exiting (let’s say) 97% effectiveness validators for performance will be needed without being willing to wait for oDAO hotfix?

RPIP- 80:

Looks good I think. Is the

did_not_exit_base * did_not_exit_backoff ** i

intended to be exponential? Is there a reason for this, and more generally why would you increase the amount on the 2nd or 3rdattempt?

I personally think that the 0.1E penalty is too low. A rough calculation is that a 14% minipool will earn about 0.11 E more than rETH each year, so by purposely avoiding exits it’s likely a minipool will come out ahead except in the case of complete protocol collapse (ie multiple exit requests in a year).

RPIP 44: looks good

RPIP 77:

seems good as written, trusting the implementation/audit. Is this intended to be an oDAO duty, as 12 hours is short for manual community member checks. Or is someone already planning to automate proofs “permissionlessly”? While the threat of repercussions remains, it’s toothless without an implementer.

RPIP 46:

agree that alternative use of voter_share is more of a “nicety” rather than a must have. Can be done later. I assume this needs an explicit RPIP addendum to specify why the previously voted-on action is not being performed?

RPIP 42: bond decision to decrease to 1.5 will need to be explicitly addended out.

RPIP 83:

So I strongly approve of the motivation here.

I think i disagree with a permanent setting here, for the same reasons of UARS- we don’t know what the optimal amount is, and 6 might be correct or might be wrong. I think that a pDAO setting between 1.5 and 8E is reasonable. Similar to the ideas of < Options forum thread - #7 by epineph > Preferential queue for higher ETH bonded minipools , it’s challenging for us to determine in advance what the demand would be. I think limiting changes to 1E every ?3 months? is likely to be able to find the sweet spot for migrations without perpetual RPIPs.

Additionally, I’m not knowledgeable enough to know how well this short RPIP plays with the rest of the protocol- ie, when your bond is going up each time a distribution happens, how does that affect smoothing pool generation (like is the rETH/NO bond when reward tree is generated, or is it calculated based on where node bond was during each attestation)? Is it possible to go above node bond, and in that case how do you receive your ETH reimbursement?

It seems that there will still be a substantial benefit for nodes that have already gotten 4E minipools compared to others for a decade. Adding additional bond would increase your earnings by less than solo staking (if i’m calculating correctly), why would people would do that? We may have to be more aggressive with underbonded nodes (eg, calculate all rewards based on a bond of reduced_bond regardless of the actual bond. However, if being below bond is more punitive and people exit megapools to hit bond requirements, is that a win?
I think this is a tricky topic, I’m not sure the correct number or the full reprocussions, so I think generally smaller iterative changes are preferable.

RPIP 82: Seems necessary for ETH, reasonable for the others if not terribly complex.

RPIP 85: I think this is low priority. Signaling with votes don’t need the high fidelity of on-chain, i think this is “nice to have” but would not want it to delay other rpips.

RPIP 87:

RPL Inflation: I wonder if a more granular, lower frequency inflation change is better- eg, keep 1% but make it so it can only be raised every 14 days.

Proposal quorum: I agree with lowering the guardrail; I would disagree with lowering the setting.

Upgrade veto: I disagree that a lower quorum is not inherently less secure - there are risks and tradeoffs. In this case, a single malicious member could veto a hotfix in perpetuity if security council is under 10 members. i don’t know if removing a member is veto-able, but seems like 10% is low. On the other hand, what is the point of setting veto threshold to >50%? I can see risks, but no benefits.

:grinning_face:
I’m also going to make another pitch for exit fee for liquidity exits. I realize this is seems unlikely to gain traction, but as always I’d prefer to say my piece than to see something suboptimal be rolled out. It’s a pretty rough proposal, so please attribute any inaccuracies to stupidity rather than malice.

Liquidity exit fee

This fee is going to be indexed to the queues- essentially charging the exiting rETH holder the opportunity cost of both the exit and the entrance queue. A central idea is that if there are large queues to enter or exit, the asset shouldn’t be expected to trade at NAV, but should tolerate small fluctuations.

Negative ramifications of no fee:

  1. stakers may choose to exit rather than sell into liquidity for a miniscule difference, or none at all. Like 100rETH on cowswap is currently -0.09% swap; if exited . However, the difference to the protocol and NOs is substantial between that sale (which has no effect on TVL/income) and exiting 4-7 validators.

A discount does have some harm for the seller, but also an opportunity for the buyer if the system goes to NAV. So assuming it is not extreme, it should be tolerated.

2 If TVL in a few weeks after liquidity exit is lower, there is no harm to the protocol. However, if TVL either remains stable or rises then there is a direct injury to all rETH holders that aren’t selling, which can be calculated by ((2)entry wait + exit wait)/365 * staking percentage, or about 0.5%. As the RPIP currently written, the fee is approximately (exit wait)/365 *2, or about 0.02%. As the queue decreases, those injuries drop.

  1. A new source of (near) arbitrage would be available for bots to buy the discount that is accepted by sellers and use it to exit validators, keeping the profit; any negative deflection from NAV> ~0.02% would do. This is not necessarily a service to the protocol- obviously the sellers were still selling despite having the ability to request exits themselves.

  2. A possible source of significant griefing becomes possible, which (to me) doesn’t seem explained in your repeated mint/burn: An actor could mint 1 million ETH and then request exit for 1 million ETH, reducing rETH APR by 2/3 for 3 months while gaining more than gas prices in rETH appreciation (estimate 0.33% appreciation with 0.05% cost).
    Even repeated small malicious actions would appreciate in ETH terms despite the cost (ie holding rETH for 7 days breaks even in ETH terms). repeating this 52 times in a year would cause no loss of principle to the malicious actor but 26% loss to the protocol of whatever principle was used. Obviously these “small” actions would still need to be well above the 100E level.

My conclusions:

I don’t think a small exit fee will have a negative effect on rETH demand, most particularly returns for [all rETH] remains the same- while some will be less, some will be more. Or if you assume that some people will not buy rETH because they may get additional fees when exiting, you should also assume that some people will buy rETH because they will get additional fees while holding. Additionally, there is a benefit to NOs/protocol/rETH holders for people choosing not to exit but rather to sell.

Other possibilities:

The fee does not go to rETH holders, rather it acts as incentive for minting (hence keeping TVL the same)

2 Likes
11

RPIP-71

I hear that you aren’t happy with prioritizing minipools and that you aren’t happy with using commission for minipools. I am not sure what you are suggesting instead. I don’t agree with spreading negative effects as widely as possible, especially not if that means increasing negative effects for the protocol overall. I’m not sure why you want to base decisions on TVL.

Regarding time to exit as tie-breaker for oDAO exiting minipools: Expected outcome is that oDAO automates this duty. I’m not worried about the team implementing it in a way that allows gaming as watchtower is open-source. I’m not worried about the oDAO doing anything other than running watchtower and if they did, we could tell. Do you have a different suggestion?

For exit hysteresis, what’s your suggestion and how do you explain it?

RPIP-73

You are asking for additional notifications in the smartnode for underperformers. In the past, team has questioned if pDAO has a role to play in smartnode. I also don’t see how this is linked to the protocol upgrade, why can’t these notifications exist now? Can we just talk to the team about this and if necessary have a separate RPIP that can be implemented independently?

Honestly, I haven’t thought a lot about guardrails. Upper guardrail on performance threshold could make sense. On the other hand, there are serious discussions about EIP-8363, which would ramp up importance of performance exponentially with staked ETH. So being able to exit 97% effectiveness might mean doubling rETH APR and we’d probably need that option to have any chance to keep the protocol viable.

RPIP-80

Initially the penalty was fixed to 0.1 ETH and the cool-down after penalty was 28 days. The team worried about the redemption process being delayed if a significant number of node operators ignore exit requests and cannot be force exited. They suggested a backoff process to address this, meaning that the delay between exit requests increases:

Another such proof and penalty SHALL only be possible once did_not_exit_base * did_not_exit_backoff ** i days have passed

The penalty now increases as well so that penalty per unit of time stays approximately constanst and does not become insignificant over time.

As far as penalty size, given that the proposal is to exit minipools first and based on comission, someone that gets a penalty will go straight to highest priority validator to exit after the backoff period mentioned above. So the second exit request will likely happen within about a month of the first and the 0.1 ETH base penalty works out to 1 ETH or more per year, they definitely will not come out ahead by not exiting.

RPIP-79

No, this is not intended as an oDAO duty. It requires no trust and there is a reward for the prover, so there really is no need to make it one. The expectation also isn’t that people check this manually, this is better suited for automation. I expect that the team will have an interest to have this available in smart node or at least run a prover on their own to start with.

RPIP-42 and RPIP-46

Based on how the votes above went, the plan is to have a specific vote on the bond decision and have the decision to not do voter_share as part of the Saturn 2 package vote. So if your question is if this will be voted on by pDAO, the answer is yes.

RPIP-83

Bond size is already a pDAO setting and not a permanent one. This also means that the protocol needs to be able to handle the value changing anyway, regardless of this RPIP.

I agree that existing megapools with 4 ETH validators would be advantaged and that relying on the rewards flow to top up isn’t enough. That’s why I’m in favor of using bond as megapool criterion for liquidity exits.

RPIP-87

On inflation: To be very clear, there is no “keeping” 1%. The current guardrail allows changing inflation to 3865% with a single vote. I don’t see the point of a granular mechanism. Trying to do this has already failed due to complextiy and you are asking for even more complexity (time component). If you think 25% inflation isn’t enough (or too much), lets just use a bigger (or lower) value or make a very good case why extra complexity is needed here.

Upgrade veto quorum: The pDAO has full control (no SC veto) over both this setting and members of the security council. A single malicious member can’t stop an upgrade in perpetuity, just for the duration of a pDAO vote.

Liquidity Exit Fee

I’m trying to move this conversation to the RPIP-71 discord thread.

1 Like
12

So first, thanks very much for your responses and for all the hard work you’ve put into this upgrade, as well as your organization of these votes.

I hear that you aren’t happy with prioritizing minipools and that you aren’t happy with using commission for minipools. I am not sure what you are suggesting instead. I don’t agree with spreading negative effects as widely as possible, especially not if that means increasing negative effects for the protocol overall.
I’m not sure why you want to base decisions on TVL.

I’ll put my support of equalizing megapools/minipools exits on a low priority, so can ignore that.

To me, the major stakeholders are RPL holders, NOs, and rETH stakers, so from my perspective, removing two EB 16 NOs (32 nETH) rather than one LEB8 NO (8nETH) over a difference of 0.1% APR on 28 ETH doesn’t make sense. It’s not a net positive for the protocol, it’s a net loss, but the RPIP as written mandates this because it is a small net positive for rETH holders. To me, the “point” of Rocket Pool, if there is one outside of maximizing profits, is to gain a higher market share of validators to decentralize Ethereum- this is governed by total TVL rather than rETH amount.

Combined with the fact that many nodes are highly correlated to a single commission (20%, 15%, 14%, 5%), by not spreading out the negative effects you make it much more likely to decrease the overall node operator diversity.

My point is that overall i think it’s worse to exit LEB 16s than LEB4s, but I’m pretty sure it’s not a clear winner to choose EB16s over LEB 8s at 14%, so pick a metric for exit that is more random over the whole set of nodes.

That being said, there doesn’t seem to be much of a vocal minority that agrees with me on this point.

RPIP-73

You are asking for additional notifications in the smartnode for underperformers. In the past, team has questioned if pDAO has a role to play in smartnode. I also don’t see how this is linked to the protocol upgrade, why can’t these notifications exist now? Can we just talk to the team about this and if necessary have a separate RPIP that can be implemented independently?

absolutely. I think there’s always tension between trying to get everything you want in one place and keeping it focused. I think this is a/the major route of rETH Protection From Underperforming Nodes so would fit thematically. My thought was along the line of a (really rough) “rocket pool team SHALL workup additional methods of notification for underperforming node operators”, ie broad guidelines, and the RP team can decide the specifics of implementation.

RPIP-80

As far as penalty size, given that the proposal is to exit minipools first and based on commission, someone that gets a penalty will go straight to highest priority validator to exit after the backoff period mentioned above. So the second exit request will likely happen within about a month of the first and the 0.1 ETH base penalty works out to 1 ETH or more per year, they definitely will not come out ahead by not exiting.

yes i can see now how that would definitely injure a node operator IF we had persistently declining TVL over a year, although still not if that validator was at 14% (where there are ~200,000 rETH of liquidity exits possible). However, as mentioned above I think ordering by commission isn’t optimal. So i think >0.1E is still recommended.

13

The best way to maximize TVL of rocket pool is to make both rETH and being a NO competitive and that’s not compatible with keeping the less efficient model (lower leverage subsidized with higher fee) around. I think it’s shortsighted to look at immediate TVL impact of an exit decision instead of the impact on efficiency of it. You are advocating for keeping rETH commission higher and I think that will hurt TVL by making rETH less attractive.

I agree that if we are going with a different ordering, we would need to think about penalty sizing in that context. The RPIP as written has the flexibility to change the penalty through a pDAO vote and since the oDAO would be responsible for picking minipools to exit, changing the minipool criterion could be done through a future RPIP that doesn’t require smart contract changes as well.

14

That being said, there doesn’t seem to be much of a vocal minority that agrees with me on this point.

Oh, I’ll be fully voting against RPIP-71 and if it passes, I’m gone. I have no desire to participate in a system that exits validators that have been with the protocol for years and always performed nicely.

But majority seems to just want whatever boosts rETH and protocol adoption. So, there seems to be no value in raising opposition, they don’t value loyalty and reliability, they want growth under any circumstance.

If this passes, I will never suggest Rocket Pool to anybody anymore, that’s how opposed I am!

15

The best way to maximize TVL of rocket pool is to make both rETH and being a NO competitive and that’s not compatible with keeping the less efficient model (lower leverage subsidized with higher fee) around. I think it’s shortsighted to look at immediate TVL impact of an exit decision instead of the impact on efficiency of it. You are advocating for keeping rETH commission higher and I think that will hurt TVL by making rETH less attractive.

I do agree with you in the event of a massive rETH run (like if our node set is 3 EB16 and 2 LEB8s, i’d definitely want to exit the former 3 first), but to me in the current system the difference is very small for rETH holders but substantial for NOs.

  1. The benefit of liquidity exits (this RPIP) is almost entirely independent of the commission (like we can get the vast improvement in QOL for rETH holders without choosing winners or losers here).

  2. The distinction for different commissions is not being made for poor performing minipools (ie, if rETH APR is what matters most in exit ordering, an LEB 14 at 90% is “better” for rETH than a 20% EB at 94%). It seems counterintuitive to me to say commission is a factor that cannot be considered for the one RPIP but must be considered for the other.

  3. If commission is felt to be that crucial, there’s no reason to think the pDAO would not favor exiting minpools even without liquidity needs as there is plenty of megapool demand, once queues decrease.

  4. EB 16 are still safer for rETH than LEB8. Black swan events and abandoned validators. Like it sucks that it may take 30 years for it to bleed out, but you won’t have bad debt with them. It’s not worth 6% of rewards, but it’s worth something.

Anyhow, that’s all I have to say on the subject, i think this is kind of a small part of a needed RPIP and I appreciate the back and forth!

1 Like
16

So as I see it, either someone needs to be exited (an efficient orderly way) or there gets to be a large enough discount that NOs exit to try to benefit (an inefficient way that has significant downsides for rETH). Both sides have equal loss of NOs. The major issue is that force exiting is a one way street, since megapools are so efficient and rETH demand is shrinking. If there was a pathway to re-entry, I think that would soften the blow, and that’s what i feel like the combination of the RENTRY QUEUE from RPIP 71 and INCREASE BOND to 6 in RPIP 83 provides.

Optimally, the ability to request exits induces demand rather than scares it away, although who can predict some things.

17

Or we could require RPL to run a megapool or at least to join the queue. See my other post.

18

I think that’s a fair point and if we want to be consequent we should include performance. I’m not sure that the added complexity for oDAO is actually worth it though.

19

Alright, I just closed the polls above. Since pDAO seems mostly positive about the proposals and on board with proposed voting process, I’m getting sentiment polls going for the individual items. They will run for 7 days.

To recap, we are now going forward with the following structure for voting on Saturn 2:

  • first, separate votes on open questions
  • then, one vote on the Saturn 2 package as a whole, with the open items resolved according to the outcome of the first voting round

This lets the pDAO express clear preferences on the tricky parts, while still deciding on a coherent Saturn 2 bundle afterwards.

These are sentiment polls that are necessary to create a rocketdash vote (formerly snapshot vote). The sentiment poll itself isn’t meant to express preference on the question at hand, just if you agree that we should proceed with the vote. Then, in the following rocketdash vote, you should vote based on what version (if any) you want included in the package.

Below are the sentiment polls. These are the steps if all goes well:

  • Step 1: 4 sentiment polls ← we are here
  • Step 2: 4 rocketdash votes on RPIP-71 in/out, RPIP-71 deets, RPIP-85 in/out, bond size
  • Step 3: sentiment poll for package vote
  • Step 4: rocket dash vote for Saturn 2 package

RPIP-71: rETH Withdrawal Liquidity

Decide if the Saturn 2 package should include RPIP-71

  • Support moving to vote
  • Oppose moving to vote
  • Undecided
0 voters

RPIP-71: Exit Criterion for Megapools

Decide (via ranked-choice vote) if exit criterion for megapools in RPIP-71 should be either:

  • random
  • lower RPL stake first
  • first in, first out
  • together with increasing bond requirement, exiting from megapools the furthest below bond requirement
  • biasing towards larger nodes
  • bias towards not hitting same node again
  • Support moving to vote
  • Oppose moving to vote
  • Undecided
0 voters

RPIP-42/RPIP-83: Megapool Bond

Decide if the Saturn 2 package should include either:

  • megapool bond lowered to 1.5 ETH (keep RPIP-42 as is)
  • megapool bond stays at 4 ETH (overturn this part of RPIP-42)
  • megapool bond raised to 6 ETH (include RPIP-83)
  • Support moving to vote
  • Oppose moving to vote
  • Undecided
0 voters

RPIP-85: On-Chain Signal Voting

Decide if the Saturn 2 package should include RPIP-85

  • Support moving to vote
  • Oppose moving to vote
  • Undecided
0 voters

Next Steps

  • If the above sentiment polls pass, start pDAO votes on rocketdash
  • Incorporate outcomes of the votes into the RPIPs
  • start voting process for the Saturn 2 package vote
2 Likes
20

I am not 100% sure I will vote to include all these in the Saturn 2 package, but I do think it is time to create that package to vote on, so I am voting to move all these to a vote.

1 Like