Improvements to skipping the minipool queue

Context: current state of skipping

Right now, NOs can skip the queue by providing 32 ETH, and having the 16 ETH refunded later (after there are no minipools waiting for 16 ETH matching). A challenge is that this is most interesting to NOs when the deposit pool is low compared to the minipool queue – this implies that they may have a long wait time for their refund, which is (obviously) very capital inefficient.

The main suggestion is to allow users to provide 32 ETH, and get rETH for the ETH beyond their share of the minipool.

Flow:

  1. User provides 16 ETH for their minipool and begins waiting for 16 ETH to get paired from the deposit pool.
  2. If waiting for community ETH (from 1), user can choose to skip this queue by lending 16 ETH to the minipool.
    a. These 16 ETH will be refunded automatically once there is no minipool queue and enough ETH in the deposit pool.
  3. If waiting for an ETH refund (from 2), user can opt to receive (16*mint_ratio) rETH immediately to their withdrawal address instead of getting a later refund.

How is each stakeholder affected?
TL; DR: good for NOs, unclear for rETH holders, good for protocol TVL

Detailed stakeholder breakdown

New NOs:

  • Gain the option to instantly skip minipool queue at any time during wait, not just during initial setup. Since this is optional, this is a strict win.
  • Gain the option to instantly skip the refund queue if they wish (by getting rETH). Note this may be a taxable event depending on jurisdiction. Since this is optional, this is a strict win.
  • 16 ETH depositors are benefited by smaller queues. Since this only creates additional opportunities to skip the queue, this is a strict win.
  • I should note that, outside of the taxable event issue, it’s nearly always worth it to the NO to take the rETH. Why? If they’re willing to wait until the deposit pool is non-empty, that’s the similar to saying they’re willing to wait till rETH is valued at least as high on the market as when directly burned. This means they’re getting a full refund, at roughly the same time, with the benefit of having APR in the meantime.
  • Potential indirect benefit to RPL value via increased number of NOs (since some this decreases some perceived startup cost).

rETH holders:

  • 32 ETH depositors currently help rETH holders a good bit until their refund. They provide the protocol with the output of 32 ETH, but only take the standard rewards. This means rETH holders are getting rewards_per_ETH*.85*16 for free!
    • Insofar as there are more 32 ETH depositors (take step 2 after setup), this increases APR
    • Insofar as there are fewer 32 ETH depositors (take step 3, when they’d otherwise have chosen to be a 32 ETH depositor at setup and waited for a refund), this decreases APR
  • Potential indirect benefit to rETH utility via protocol health – healthier/larger protocols are more likely to be used in defi.

Protocol health:
Here I assume (A) greater TVL is good and (B) the deposit pool is empty with a minipool queue. When (B) isn’t true, this whole proposal is irrelevant as there will be no need to skip empty queues.

  • (B) implies there is less demand for rETH at the mint rate than supply at that rate. In other words, the market rate is lower than the mint rate.
  • This proposal incentivizes locking additional value into the protocol. NOs will want to mint rETH at the mint rate, even though it’s above market, because that allows them to start earning APR sooner. In short, we’re allowing an efficient market where NOs can choose to pay an upfront fee (by minting below market) to get extra time with active rewards.
  • What does the NO do with the rETH?
    • Sells and doesn’t do anything else RP-related. In this case, this will marginally decrease the market value of rETH.
      • Slightly negative for TVL vs being a 16 ETH depositor.
    • Holds until the deposit pool is non-empty (aka the market rate and the mint rate converge). In this case, this is very similar to a refund with the major difference being that the NO got the benefit of their 16 ETH instead of that benefit being spread across all rETH holders.
      • Significantly positive for TVL vs being a 16 ETH depositor.
      • Neutral for TVL vs being a 32 ETH depositor.
    • Sells to buy RPL. Marginally decreases the market value of rETH, but marginally increases the market value of RPL.
      • Significantly positive for TVL vs being a 16 ETH depositor.
      • ~Neutral for TVL vs being a 32 ETH depositor.
    • Sells to start another minipool. Marginally decreases the value of rETH, but locks the whole value back into RP.
      • Significantly positive for TVL vs being a 16 ETH depositor.
      • Slightly negative for TVL vs being a 32 ETH depositor.
2 Likes

I should note, this is a quality of life improvement, not something game-changing. I do think it will bring more TVL to RP, but I don’t think it’s a crazy amount.

That said, I think all the relevant components (deposit, refund queue, minting) exist, so I’m guessing the development time is on the lower end. I’d suggest including this as a small feature in a larger package rather than having this be a key driver.

Hey, I am a new Node Operator and just recently started validating with Rocketpool. I am running a normal validator alongside. I chose to stake with Rocketpool for the added commision.

What you describe is the exact same issue I am having right now. I staked 32 ETH with rocketpool. The deposit pool is quite empty and the queue gets longer. I don’t expect to get the 16 ETH refund anytime soon. Previously that wouldn’t have been a problem, because there was enough demand, but this is now different.

I would like to suggest a different Flow though. I don’t really think getting rETH would be beneficial for a NO operator.

Flow:

  1. User provides 32 ETH to skip the queue.
  2. The rETH balance stays at 0 (100% of earned eth is accrued for the NO, see screenshot)
    Screen Shot 2022-06-20 at 13.05.47
  3. Once 16 ETH is pooled, the rETH Holders accumulate from the Minipool.
  4. The NO can request the refund

This would have several benefits:

  • Running a Node with the current low demand is not punishing. I would love to spin up another rocketpool minipool but this is currently not economical.

  • Rocketpool builds up a reserve to absorb future demand better (especially because Node Operators get their ETH back and can spin up another minipool right away, once there is demand)

If the process could be adjusted as outlined, it would be a no-brainer for me to spin up more and more minipools. But currently, the opportunity cost is too high and I would rather spin up a normal validator because I don’t know when demand will return.

1 Like

How does your proposal differ from simply getting rETH in my original variant and holding it until we’re pegged again (aka, the deposit pool has ETH available)?

In either case, I believe you will earn the total rewards for 32 ETH. In your variant, this is very direct. In my original variant you get the rewards for the minipool portion (16 ETH + 15% of the rewards for another 16 ETH) and the rETH portion (85% of the rewards for 16 ETH), which should add up to the rewards for 32 ETH. There’s a detail difference in that rETH is getting rewards for 16 “average ETH” across validators instead of rewards for a specific 16 ETH, but that’s pretty minor.

If you sell the rETH once there’s money in the deposit pool, I believe this is effectively identical (it’ll be worth 16 ETH plus that portion of rewards). Again, we do have detail differences here - for example, taxes could look different.

The thing I like about the original suggestion is flexibility. Here's an example

Let’s look at a couple examples with the following assumptions: rETH currently has an ideal exchange rate of 1.0667, and a market rate of 1.0333, I have a ton of RPL staked, so that’s not a factor. Let’s say I’m looking to start 4 minipools.

Patient choice
32 ETH start minipool: 1 pool, 15 rETH
32 ETH start minipools 1 pool, 15 rETH
Wait for rETH repeg (aka, the deposit pool isn’t empty)
16 ETH start minipool: 1 pool
16 ETH start minipool: 1 pool
Total investment: 64 ETH to get 2 pools running immediately and 2 more once the peg has re-established (which due to arbitrage is roughly the same time the pool has funds).

Your suggestion
32 ETH start minipool: 1 pool, 1 refund IOU
32 ETH start minipool: 1 pool, 1 refund IOU
Wait for refunds (aka, the deposit pool isn’t empty)
16 ETH start minipool: 1 pool
16 ETH start minipool: 1 pool
Total investment: 64 ETH to get 2 pools running immediately and 2 more once the pool has funds. Note that this is pretty darn similar to the “Patient choice” above.

Impatient choice
32 ETH start minipool: 1 pool, 15 rETH, sell rETH
16.5 ETH + 15 rETH start minipool: 2 pool, 15 rETH, sell rETH
16.5 ETH + 15 rETH start minipool: 3 pool, 15 rETH, sell rETH
16.5 ETH + 15 rETH start minipool: 4 pool, 15 rETH, sell rETH
Total investment: 66 ETH to get 4 pools running immediately (vs the ideal of 64 ETH). In your variant there is no way to do this – everyone must use the patient choice.

In the impatient scenario, I’m effectively paying .5 ETH/pool for the privilege of immediately starting the pools. Is that worth it to me? My choice. Maybe for me that’s not worth it, but it would be worth it at a smaller discount where I end up paying .1 ETH/pool. Regardless, I’m free to make the tradeoff.

This shows 2 of the 4 paths for NOs I detailed in my original “stakeholder breakdown”, but I think it’s enough to make the point that NO flexibility is nice and doesn’t cost us much here.

I agree, that both solutions work.

It’s my preference, I would rather be reducing the required tx. So wait to get the ETH back, rather than claim rETH then wait for an opportune time to exchange.

Maybe both could work together?

If there are no 16 ETH, then you can claim rETH. And you don’t earn anything on the other half of the minipool or…

…wait and continue to earn in full and claim ETH once there are enough deposits.

I would be comfortable with having the choice.

I like this. It doesn’t change the risk, nor is it unfair for any parties, and gives more agency and flexibility to the NOs.

My only concern is whether the implementation complexity and effort is worth the potential actual usage.

I think improving the NO experience and on-boarding more high quality NO’s is the highest growth priority for RP. So a plan to smooth out one of the wrinkles - like this - seems important and timely. Let’s get all the issues out of the way for new NO’s. We saw what the demand was when we aren’t in a bear (queue Sat at 99.9%+ for a long time), so we need to have systems in place to prepare for that again. I support this idea.

(Admittedly, nothing to add here but support - well proposed idea)

I put up a PR for this: https://github.com/rocket-pool/rocketpool/pull/250

Note that there’s been recent ongoing discussion on discord as to what is best from:

  • Full and half deposits, but a shared queue
  • Only half deposits
  • This proposed flow (can upgrade form half to full; full can get rETH refunds)

The main concern with this flow is that half deposit pools without the capital to upgrade might be stuck behind a large number of users that do use this flow. (thanks to @knoshua for bringing this up)

1 Like