Variable minipool size w/RPL stake based on protocol ETH

This is actually the point of the idea :slight_smile:

From a protocol point of view, we want to maximize how many rETH we can mint from a given NO investment. This helps us do that. It doesn’t impose additional costs on the rETH holders (same commission), and as you say there’s benefits to the NOs.

There is some concern once the NO ETH contribution gets very small b/c there needs to be a minimum total collateral to successfully deter MEV theft. This is why there’s discussion around whether the minimum should be 4 or 6 ETH. That’s a detail I’ll leave to folks that are more expert at modeling ETH.

1 Like

Sorry, the ‘hidden’ part was tongue in cheek since i had just discovered the ‘hide details’ function of this forum

hidden

But generally emission based tokens work by bootstrapping so that early stakers (those of us who spun up at 5% commission after launch) get significant benefits, but as they mature and people are universally staked the emissions become functionally useless. One goal should be decreasing excess liquid RPL from early investors, so we should assume that our true RPL APR will dip below 0 if the project is successful. As you said, if the project is successful it will likely raise the price of RPL more than inflation is pulling it down.

So I was using a 10% NO commission assumption, which is what Ken used in the chart and what Rocket Pool devs have said is long term goal. At 10% commission, it is revenue equivalent for solo and minipools at both 16E and 4E amounts (with all those caveats about additional expenses in minipools).

Valdorff's point

So I agree with you. I am biased, I think this is a good investment. I think APR will drop and RPL value will rise. I think the bones are good, the protocol works, the team is solid. but I don’t have to convince you, me, or Marceau about rocket pool. If i went on the Solana forum, i would be told to buy their token because the price will rise- it’s an argument that works on people who are already believers. 70% cost for 70% yield increase is less salable to the public than a 10% cost for 10% yield increase, and we are already having a tough time selling our project.

What if we keep the commission at 15%?

So at 15% commission, back of the napkin you get a benefit for both 16E (4.5%) and 4E (17%) over solo stakers. So that helps. However, that cuts into rETH competitiveness over the long run if that commission can’t be dropped to 10% or lower; i personally think that’s not in the best interest of the protocol or the ecosystem (my opinion). I could see a time after mass adoption with 5% rETH commission and 35% commission for NOs- but that would require a lower RPL bond to make sense.

To me, the major problem with Rocket Pool currently is that no one outside of us wants exposure to RPL, and even some of our members question if we need it at all. I think, Marceau, you in particular are acutely aware of this from your whale mating rituals. In order to get people to want RPL, it needs to offer function. Purchase 70% RPL to get 70% extra rewards is not function. Purchase 10% RPL to get 70% extra rewards, for example, is function- the unlocking of the commission, as you mentioned. Those kind of yields can bring in small stakers, whales, and institutional investors because because they are too good to pass up despite the increased costs, risks, taxes, etc. So you are going to wind up with a lot more RPL locked up with a smaller RPL bond. To me, that’s the best viable path to growth.

I see. That sounds superficial compared to the practical benefits of simply deducting ETH first.

Using RPL comes with the need to perform an auction. This introduces

  1. A delay in trade execution, which can lead to speculation and slippage
  2. Extra complexity
  3. Large slippage if a significant amount of RPL needs to be auctioned off

These can reduce the chances of the protocol retaining integrity.

I’m coming around to your point of view.

I went looking for a reason to use RPL first and came up mostly empty.

Reward scaling was almost a reason, but nope.

I thought a good reason might be that validator rewards all scale with validator balance. See this link (thanks to @a35u for that source).

In other words, we should take RPL first, if that lets us minimize how much the validator can drop below 32. Imagine a 16+1.6 minipool. If we use 1.6 ETH of RPL as insurance and then 1.6 ETH as insurance, that would present half the drag on APR as if we first used 3.2 ETH of insurance.

However… that’s just not how it actually works. We’re not literally removing ETH, we’re just relabeling it. So in the case above, we’re decrementing NO_ETH by 3.2 and incrementing Protocol_ETH by 3.2 in the same minipool validator - the actual balance doesn’t change, so rewards don’t change.

If we leave it ETH-first, it would position RPL as having several functions:

  • Unlocking commission (this only requires the minimum effective stake, and only when starting a minipool)
  • Governance (maybe scales with a function of effective stake - see Snapshot Voting)
  • Fallback collateral (this gets stronger with more effective stake, but we believe it’s strong enough at minimum effective stake)
  • In-kind yield (scales with effective stake)

I think this is sufficient utility.

Proposal v0.2.0: Allow minipools to be started with 4-31 ETH and at least 10% of the protocol’s ETH contribution in RPL

Details:

  • Commission remains at 15%
  • Collateral use order remains unchanged (ETH first, then RPL); nobody has provided a satisfactory reason to do RPL first and @dabdab brought up some good reasons to prefer ETH first.
  • RPL max effective stake remains at 150%
  • 4 ETH min: For MEV theft, 5.6 ETH of collateral has been considered “safe”. 4+2.8 would allow a >40% drop in RPL:ETH ratio while staying at the safe level (and the lack of RPL rewards would incentivize NOs to keep their RPL up during such a descent).
  • 31 ETH max: There wasn’t much more discussion on this; went with 31 to encourage some alignment between NOs and the overall protocol.
  • See my comment above for how we could talk about the role of RPL.

I wanted to have a single concrete thing being proposed so that folks can talk to that. I’ve integrated feedback where there was feedback and my own judgement where there wasn’t.

If folks want to refer to this specific variant of the proposal, I’ve labeled it v0.2.0. The original at the top can be refered to as v0.1.0.

2 Likes

Looking at the current trends of the growing minipool queue and wait times, I think this proposal will end up exacerbating the increasing waiting time issue. My expectation is that the distribution of new pools will be heavily skewed towards smaller NO ETH / larger protocol ETH minipools–just as an example, if the average NO ETH deposit shifts to 10ETH from 16, the wait times will increase by ~38% at the same protocol ETH minting rate. The growing queue is bound to discourage new NO’s somewhat.

I think you’re a bit off on the minipool queue thought… If we get some deposit rate inflow (eg 100 ETH/day) and there’s some minipool outflow (eg 150 ETH/day). If the outflow is greater (as in this example), we’ll trend to infinite wait time. If the outflow is lesser, we’ll have no wait (and the deposit pool will fill up).

So why don’t we trend to infinity? Because folks don’t want to wait forever for their minipool to start up – it’s not fun, and it’s not capital efficient. In reality, when the deposit pool is empty, we’re gated by people’s willingness to wait in the queue (ie, NOs are self-limiting anyways). When the deposit pool isn’t empty, then having smaller NO ETH minipools helps the protocol handle the inflows more effectively – this is important because rETH minting isn’t self-limiting, it’s bottlenecked by NO availability.

Keep in mind that, for the protocol, it just matters that we have an NO to match with, not who the NO is nor how long they waited. In short, this addresses the real world bottleneck for the protocol.

Bonus: if a potential NO decides they’ll get rETH instead of waiting… the price of rETH goes up which means we move towards filling up the deposit pool :slight_smile:

Overall, I like the idea of a variable minipool size, but depending on how it’s implemented, it may slow down uptake of new half-sized minipools.

Regardless of how you look at it, someone is going to get the short end of the stick on that one:
1.) you bottleneck the NOs behind the smaller minipool if there’s < 28 ETH in the pool to be used for new nodes.
2.) you may indefinitely push smaller nodes to the back of the queue if they’re pre-empted by someone doing > 4 ETH due to available ETH in the pool.

Once the pool is large enough, the amount of ETH that would sit in the pool is actually inconsequential to the rewards AND will result in higher liquidity when burning rETH for ETH. Minipools of smaller sizes than 16 ETH wouldn’t have issues waiting or causing others to wait.

Now, we could do some kind of hybridized queuing where we weight time in queue or number of minipools larger than the smaller one getting a score based on size, queue depth, and position in queue. Though, the process of doing so fairly is not a trivial matter. Also, there is potential for clogging still if deposits stay low.

Overall, I’m in favor of having smaller pools (in fact, this was initially a point of hesitation on my part when spinning up my first minipool), but I want to make sure that we’re not disrupting the flow of pools, particularly those that have the standard half minipool (or larger) from being processed as quickly/efficiently as possible.

Not sure I follow the queue issue. Wouldn’t it just be first come first served? So if we had a 4 NO-ETH pool, then a 16 NO-ETH pool, then an 8 NO-ETH pool we’d wait for enough deposits for 28 ETH, then 16 ETH, then 24 ETH to launch each one. Are you just saying that smaller NO-ETH minipools will absorb more ETH so that’ll take longer to get through? I think that’s unavoidable since the main benefit we’re looking for as a protocol is absorbing more ETH.

The deposit pool has been depleted since May 10 and the minipool queue has been steadily increasing since, currently sitting at 236 minipools. My point is that variable size minipools will–maybe arguably–skew the average NO deposit to some number less than 16eth. This in turn (i) increases number of minipools in the queue compared to the baseline of non-variable minipools; as well as (ii) increases wait time for each minipool since greater amount of protocol eth is now needed per minipool. The overall impact is that the minipool wait time is increases non-linearly as the average minipool size shrinks.

You argue that this seemingly would not matter because “folks don’t want to wait forever for their minipool to start up”. I wholly agree–they would take their ETH elsewhere, instead of growing rocketpool. Is that an acceptable trade-off?

1 Like

instead of growing rocketpool

I think this is an important question. What is the important metric for how big RP is?

We have value locked in: staked RPL, staked NO ETH, staked ETH backing rETH (aka protocol ETH), and a minor amount in queues. In my opinion, what really matters is the protocol ETH. This is what creates our liquid staking derivative, and what generates commissions. Of somewhat less importance, I think there’s an argument for staked RPL mattering. I don’t personally see much relevance to the protocol for NO ETH – the protocol doesn’t create value with this ETH, though it is important as collateral.

If protocol ETH is indeed the right metric, then there’s no difference (to the protocol) between 7 16-NO-ETH pools and 4 4-NO-ETH pools; in either case, they allow for 112 protocol ETH of growth.

What we really care about is collateral per validator. The split between ETH and RPL is a secondary concern. There are multiple factors to consider:

  • Capital efficiency: With RPL collateral, you need to have some form of liquidation process where the liquidator gets part of the collateral. Also, ETH collateral is earning built-in staking yield. RPL collateral is inherently dead capital. You can try and make up for it with RPL rewards, which adds costs for the protocol. More ETH is better.
  • Security: 1 ETH will always be 1 ETH , but RPL can have price fluctuations. You can try and hedge against that by upping the requirement, which hurts capital efficiency again. More ETH is better.
  • Costs: RPL rewards. Also, if you want to reliably liquidate RPL without tanking the price, you will need to incentivize RPL liquidity. More ETH is better.
  • RPL value: Higher RPL requirement per minipool creates more demand for RPL. More RPL is better.

So I see significant trade offs with shifting heavily towards RPL collateral as suggested here.

Hmmm… I think the main difference in perspective is around the main role of RPL. I don’t think it’s collateral right now (there’s 16 ETH too, and they get used first). I don’t think it should be collateral for LEBs (all but the smallest will have enough ETH to make the RPL mostly un-needed; and if we wanted to really push RPL as secondary we could limit to 6+2.6 as the smallest).

I’d argue that the main point of RPL now is to grant access to commission when spinning up a minipool. 1.6 ETH worth of RPL can get you the ETH staking rewards that would usually come from staking 2.4 ETH. That’s pretty valuable.

There are secondary roles (governance, in-kind yield, speculation, and, yes, secondary collateral), but I think the commission bit is paramount. That’s why I focus heavily on “minimum percentage of protocol ETH” and “commission”, since those affect how much ETH-reward you get per ETH of RPL.

That’s certainly not how the RPL requirement has been communicated in the past, but even if we want to view it that way… It’s a significant burden on capital efficiency still. It means we need to keep commission high to even offer higher yield than solo staking and/or use token inflation on node operators, which is not sustainable.

Let me start by making the following points.
The overall purpose of the protocol must be to increase the number of protocol users and improve TVL.
Therefore before making any decision it is important to consider whether this matter will cause unnecessary trouble for the user’s threshold.

For 4+2.8,6+2.6 mechanism, it actually increases the risk greatly (RPL is a high-risk asset), which is obviously not conducive to the long-term development of the protocol.

Not sure I follow this top-level argument. The premise of LEBs (not specific to this proposal) is that they would increase TVL greatly by (A) making the investment more attractive to NOs in terms of ROI, (B) making the investment accessible to more NOs by reducing the capital needed to get involved, and most importantly (C) allowing a much larger amount of protocol ETH per unit of NO ETH. All of these serve to increase TVL whether measured at the full protocol level (NO ETH, protocol ETH backing rETH, RPL) or just at the product level (market cap of rETH).

Your point about RPL speculation risk is a reasonable one. This proposal allows NOs to choose between greater expected ROI with more exposure to RPL vs lower expected ROI with less exposure to RPL.

2 Likes

If we take these points as true, by extension we should just remove RPL from being a collateral requirement entirely and rely on only ETH. Clearly this can’t be the case, because RPL serves several key purposes within the RP ecosystem (incentives from inflation, alignment between NOs and the RP team, additional collateral requirements).

I would argue that we can not take the direction of reducing the utility of RPL within the Rocket Pool ecosystem, for at least a few reasons:

  1. It isn’t reasonable or appropriate to expect that a DAO would support a direction that reduces RPL utility/value. Such a vote would be unlikely to pass and trying to force such a direction would be strongly anti-DAO.
  2. Doing so would put the overall project at risk, because the treasury is denominated in RPL. Reducing RPL value/utility would reduce oDAO security and limit the team’s runway for operating expenses.
  3. Taking that position would set a precedent that we should continue to reduce RPL collateral requirements as new technologies unlock more capital efficiency, which isn’t sustainable given 1. and 2. above and would put RPL value on a glide-path to 0 over time.

The path forward is simple, we must at least sustain – and ideally improve – the position of RPL within the ecosystem. The only reasonable way to do that is to enshrine RPL as the primary collateral, having preference over ETH.

Separately, I disagree that ETH is strictly a better form of collateral, although you do highlight some challenges such as RPL/ETH liquidity which we should think about separately.

4 Likes

Ultimately I think that as the RP ecosystem matures, the market around RPL will improve:

  • RPL/ETH liquidity will naturally reach an equilibrium where the LP APR will approx. equal the staking APR.
  • RPL/ETH volatility will reduce as more node operators have low collateral and have an incentive to keep >=10% collateral for rewards.

This will also improve the position as RPL as a collateral asset and reinforce its position as a primary collateral.

2 Likes

One of my points is maintaining RPL value, so the consequence clearly can’t be to remove RPL as collateral completely. I agree that we can not reduce the utility of RPL. I’m simply saying that there are trade-offs to consider if we wanted to lean more on RPL collateral. Basically I am arguing for keeping RPL collateral around but not overemphasizing it.

I would push back against making RPL collateral the primary one for the reasons listed above.

Can you explain this? We are ultimately looking to insure an ETH position. Denominating it in anything other than ETH comes with a cost.

To clarify, I don’t really feel strongly whether ETH or RPL collateral is used first to cover losses. I’ve heard reasonable arguments in both directions. When I say “primary” I mean “the collateral that we should prioritize and protect from reductions in collateral requirements”.

I do feel strongly that we should avoid something like 4+0.4 (original suggestion) as that would significantly reduce the position of RPL in the ecosystem.

1 Like