Saturn follow-up votes #1

Governance
1

Hi All,

One of the things RPIP-49 notes is that we still have a handful of things to iron out before Saturn goes live. I’m proposing one vote in the “ratify something so it’s crystal clear” vein, as well as 2 tweaks.

These are currently in a pull request as 3 separate RPIPs: https://github.com/rocket-pool/RPIPs/pull/318/files

Misc ratification

This is meant to be the boring ones I don’t expect too much discussion on. That said, it’s important to review them – eg, if there’s an important interaction we’ve missed, or if something’s ambiguous, then now is by far the most painless time to fix it

This covers

  • 2 Tx deposit strategy (there had been a 2 vs 3 discussion)
  • clarifying language on how to count vote eligible RPL within a megapool
  • a guardrail on the time_before_dissolve parameter
  • removing a process that is no longer needed b/c proofs can be used instead now

Prioritizing rETH withdrawal buffer

This simply says that ETH from new rETH mints should go to the rETH contract instead of the deposit pool. They can still hit the deposit pool if our buffer overflows (currently 5090 ETH), but this means we aren’t encouraging more supply while we have oversupply. I think it also sends the right message about our priorities – making a strong LST is more important than getting NOs through the queue faster when we have an oversupply.

Permissionless dissolves

@langers noted that dissolves as written in Saturn are trustless, which in turn means it can be made permissionless (an oDAO duty can bite the dust). This suggests doing that, and providing a nominal (and configurable) incentive for the permissionless dissolver.

Please review and discuss here. It’ll depend on how discussion is going, but I suspect I’ll put up sentiment polls ~monday.

8 Likes
2

Fixed an error in both RPIP and my intro post above. The size of the rETH contract buffer before overflowing is 1% of rETH TVL, not 1% of deposit pool. That makes it 5090 ETH (instead of 180 ETH), and also means we’d have seen a larger impact on the peg since more ETH would’ve ended up as available liquidity – it’s possible that it would’ve simply avoided a significant depeg at all. Thanks to @petrus and @haloooloolo for the discord chat that caused me to look at this again and find the error.

5 Likes
3

Not much discussion here…

Will probably post all 3 sentiment polls tm and then move to finalize the RPIPs (the votes, not the underlying Saturn ones, which will stay living). Last call while editing is easy :slightly_smiling_face:

2 Likes
4

I did read through them all, but there was nothing really controversial imo, at least.

3 Likes
5

Aite – let’s get some sentiment polls going :slight_smile:
In the background, I’ll work to get the RPIPs merged and the vote text written.

Misc ratification vote

  • Support moving to vote; I think this proposal is great!
  • Support moving to vote; I think this is “good enough”
  • Oppose moving to vote; I have a specific issue I’m mentioning in the comments below
  • Oppose moving to vote; other
  • Undecided; I have a specific question I’d like clarified in the comments below
  • Undecided; other
0 voters

Prioritizing rETH withdrawal buffer

  • Support moving to vote; I think this proposal is great!
  • Support moving to vote; I think this is “good enough”
  • Oppose moving to vote; I have a specific issue I’m mentioning in the comments below
  • Oppose moving to vote; other
  • Undecided; I have a specific question I’d like clarified in the comments below
  • Undecided; other
0 voters

Permissionless dissolves

  • Support moving to vote; I think this proposal is great!
  • Support moving to vote; I think this is “good enough”
  • Oppose moving to vote; I have a specific issue I’m mentioning in the comments below
  • Oppose moving to vote; other
  • Undecided; I have a specific question I’d like clarified in the comments below
  • Undecided; other
0 voters
1 Like
6

All sound reasonable to me. I specially like prioritizing exits to the withdrawal buffer - the sooner we can get that the better, in all honesty.

1 Like
7

It’s not about exits, they already go to the withdrawal buffer. It’s about fresh mints not going to node operators anymore, but also to the withdrawal buffer.

8

Sorry for the late feedback.

Prioritize rETH withdrawal buffer

For this, it looks like we are using the rETH target collateral parameter?

This does make sense - I am just wondering whether there is a potential for the pDAO to want to control the 2 different flows independently? In other words, relax mint redirection but still include rewards / exits going to withdrawal liquidity.

From the numbers it looks like the buffer will be filled within a month or so (discount willing). Being able to adjust the flows independently may help in case we have to adjust on the fly (governance timelines willing).

I don’t have a strong opinion about it but I do see it gives us flexibility.

1 Like
9

Ok – chatted with @langers a bit in DM because I wasn’t clear on the suggestion, and got some clarity there.

The thought is whether we wanted to separately control:

  • The level at which rETH contract’s buffer overflows to the deposit pool
  • The level at which we direct rETH minting funds to the rETH contract as opposed to the deposit pool

Eg, we could have the former at 1% rETH TVL and the latter at 0.5% rETH TVL. This would mean that between 0.5%-1% rETH TVL, mints would service the minipool queue first (while rewards and exits still service the rETH contract buffer first).

I prefer just the single control on the rETH contract’s buffer size. I don’t much understand the point of splitting priorities – I think there should be one thing we value most (more withdrawal liquidity, or dequeuing minipools) and the ETH should go there. I am also leery of more moving parts (pDAO have to set two things, we need to explain a bigger decision tree to folks asking about details).

Given that preference, no comments before/after langers, and langers having no strong opinion: I am currently intending to keep it as is. I will give it another ~2 days before I ask to move to vote just in case folks really lean the other way.

3 Likes
10

Sorry for being very late to this. I don’t have any issues with prioritizing the withdrawal buffer, regardless of interaction with potential withdrawal requests since that can be changed in Saturn 2 if needed.

I have one strong reason I prefer the 3 transaction approach for deposits: probability of dissolution. Having a minipool be dissolved is currently a pain because there is 1 ETH on the beacon chain that is hard to retrieve. In addition, we’ve seen many subtle issues with either clients or Smart Node itself that cause automatic transaction submission to break.

Making pre-stakes part of deposit assignment means that any time the user side fails, the megapool validator will be dissolved in this painful state, similar to minipools now. If both pre-stake and stake are the responsibility of the user, however, the probability of this decreases massively. The first transaction would have to be submitted successfully while the second one shortly after fails. If both fail (more likely), the validator can be dissolved gracefully without a rescue process.

I think this affects both the ratification vote and the exact spec for permissionless dissolves.

1 Like
11

I’ve jumped back and forth between favouring one solution over the other. Here is a summary of my thoughts at present.

I’m going to call the 3 transaction option 3TX and 2 transaction option 2TX.

I agree on this point w.r.t. dissolutions. I don’t think it’s a massive consideration given only 0.11% of minipools have been dissolved in our history.

In terms of gas, both options would be very comparable. 2TX requires storing prestake deposit signature on chain which costs about 42k gas. 3TX requires a second transaction which requires 21k gas transaction overhead. So the difference is 21k gas give or take in slight favour to the 3TX option. Not a big enough difference for me to have a strong feeling about.

Both options will require some 3rd party fallback to perform assignments to continue the queue because assignments must happen in order and so is blocking. The minor benefit for 2TX here is that the 3rd party can bundle the assign and prestake. so it would get a validator up and running faster. Though, I don’t think this is significant either. If the node is online then it will detect the assignment within minutes and execute the prestake. So for me, this isn’t really a consideration.

Not having to prestake makes it cheaper for the watcher. So there is less to reimburse through the pDAO. The node pays for the prestake which, to me, makes more conceptual sense. The pDAO subsidising operations specific to a single node seems off to me. Whereas keeping the queue moving is more of a public good. Might be grasping at straws a little here but that’s a small point towards 3TX for me.

Not doing prestake on >32 ETH deposits also makes rETH deposit gas usage more consistent. Once again though, this isn’t a huge deal for me as the gas fee for the prestake as a percentage of the overall deposit will be minor. And >32 ETH deposits will still do assignments so it’s solving that issue entirely. But it’s still a small win for 3TX.

In terms of technical complexity, I don’t think this is a valid consideration. Consumers of the product don’t really care how it works under the hood. Maybe there is a tiny benefit of not having to explain that there is an extra step in there. e.g. “in queue”, “assigned”, “prestaked”, “staked” vs just “in queue”, “prestaked”, “staked”. And an extra step in the documentation on how to recover funds when you are “unassigned”. But this is an edge case and is, in my opinion, preferable to having to recover the prestake value from the beaconchain in that unlikely event. Being safer due to lower lower probability of dissolution puts another small benefit into the 3TX column.

To summarise. Although none of the benefits are powerful enough on their own to make one an obvious pick over the other, most of the minor benefits lean in favour of 3TX. For that reason, 3TX is the option that takes my preference.

3 Likes
12

Ok… Given the renewed discussion around 2TX vs 3TX deposit flows, I think I should pull that out of the ratification RPIP. I think the rest can move forward. Please let me know if you have any issue with this. If not, I’ll move to finalize RPIPs that way and move to vote in ~a day.

3 Likes
13

PR to finalize. From the last PR has:

  • 2 spelling/grammar fixes
  • Add a missing detail about dissolve_reward – it has to come from somewhere and now this specifies it’s the validator’s NO’s bond
  • Remove 2TX deposit strategy from ratification bullets, as it’s being discussed anew
  • Set the RPIPs to final

Expecting to take it out of draft and ask RPIP editors to finalize in 12 hours or so. Vote text drafts are in Discord.

1 Like
14

Apparently things can’t be easy :laughing:

Dissolves are being actively discussed in Discord, so I won’t be looking to finalize (or bring to vote RPIP-67) right now.