July 2023 GMC Community Discussion of Submitted Applications

This tool supports […] RPL Holders in earning more rewards.

Why is this desirable? At small scale this doesn’t bug me, but at large scale it defeats the “dilute speculators” concept of inflation. In other words, this doesn’t grow the pie of RPL rewards, it just cuts it into more slices.

The “protected speculation” bit is already iffy justification. If this becomes widespread, I’d be quickly pushing forward a proposal to limit RPL earning to the minimum required.

RPL utility is captured only when it is staked. Correct that this does not grow the pie of RPL rewards, but it opens an opportunity for more users to allocate RPL to it’s designated location.

What happens if NO is hit by a bus or otherwise can’t close down validators? Is RPL stuck forever?

I believe this is the case in current marriage contracts. If this is a risk, I think it needs to be very clear as it amounts to a total loss. I guess leakage might eventually bail you out, but that’s years away.

Even without a bus; I think the RPL holder is stuck indefinitely, with the only weapon at their disposal being keeping rewards illiquid? NOs might not care about that factor for multiple years.

Current marriage contracts do not have protections from rogue buses. The new contract is being refactored for anyone to be able to distribute earned funds to the designated endpoint address. This however does not account for an ability to withdraw. If the NO is hit by a bus and does not have personal backup plans for their estate, we have no remediation for the RPL holders principal balance, unless and until the protocol enables its own upgrades for forced exits.

We have briefly discussed sharing a pre-signed exit transaction in json format that could be provided to both users. That is not something we are ready to implement without significant further discussion.

What other edge cases are there?

I think RPL provider griefing is limited because exiting frees things up? Still pretty inconvenient.

We are refactoring the contract to support a claim and restake method, gated for only the NO or RPL provider, as opposed to the claim method which can be called by anyone. Staking should be initiated from the Rocket Split contract.

How confident are you that things will go smoothly and safely when LEB4s roll out and there’s bond reductions available, eg. Is it possible to essentially end up in a different financial agreement than was intended?

Users are encouraged to create a new RocketSplit contract and update the withdrawal point in case of any agreement changes.

**rETH will become more in demand if more Node Operators are onboarded.**

This isn’t a question, but I disagree. We’ll be better able to meet demand, but this won’t create rETH demand.

Also, even meeting demand is only true insofar as we’re using this to meet the minimum. If I’m using this to run 2 minipools myself at 150% bonded ETH collateral and 4 more at 150% using rocketsplit to provide the RPL… I could’ve met the same demand by running the 6 at 50% myself and not involving rocketsplit.

I believe the more Node Operators will be onboarded through the safety of the “buddy system”. Many users may be interested to learn more about becoming a NO themselves but need something like this as their guided first step.