Hi Mikey,
I wanted to show some support for your / 1kx contributions here. There are some novel ideas here, that I think deserve deep consideration. I want to specifically +1 your contention that Rocket Pool should not entirely remove the requirement to stake RPL at this time. I suggested the same when I wrote about the tokenomics changes back in March. Note: the proposals have changed somewhat since then so my writeup isn’t up to date, but the broad strokes remain.
I’d need a bit more time to go over in more detail whether I agree with some particular items. I think Samus mentioned this, but a flat number of RPL staked seems a bit of an odd choice. Might an entry ticket of a particular percentage of protocol ETH make more sense? Seems like you could more easily reason about its relation to future rewards.
I agree that we should let Houston play out before so fundamentally changing the Rocket Pool protocol in pursuit of TVL, and some of your proposals may serve to expand what’s possible now that Houston is here.
I think too many believe we have no hope to scale without acquiescing to those that have not supported the protocol to this point, whereas I think we should enable and incentivize the operators that we have, and that will only serve to attract more Node Operators. I think there’s also a real centralization vector with ETH-only minipools, as I wrote about in my doc. Some think there’s a power law when it comes to ETH staking and centralization is inevitable. That may or may not be true, but we certainly don’t need to lean into it, we should endeavor to lean away when practical.
I think it’s also critically important to keep things simple. The community should have their eyes open on how long it took to get Houston fully complete, and how long “Rocket Pool 2.0” would take to implement in Saturn. I think the scope in front of us is not realistic in any timeframe that the community is thinking. At the same time, we should be developing alongside the core protocol changes. I think Rocket Pool’s next release should be as closely following Pectra as possible, just as Atlas was with Shanghai.
It’s the start of 2024 H2 already. I don’t believe a single RPIP in the proposed canonical set is realistic for 2024, which means we’re likely bumping up with Pectra. As part of our commitment to Ethereum we should be evolving with Ethereum, and leveraging the features being implemented in Pectra.
I’d like to remind the community these items from the pDAO charter:
6. The pDAO SHOULD prioritize the health of the Ethereum network
7. The pDAO SHOULD prioritize decentralization
Building Megapools atop MAXEB (EIP-7521) should be seen as a must IMO. Allowing Rocket Pool to help collapse the validator set as we scale will be an important narrative, and it will be a negative if other LSPs are collapsing their validator set, while we expand it.
Collapsing the validator set will tend to reduce network computational load. This opens the door to work on Single Slot Finality, and is also (for a different reason), in the critical path for Enshrined Proposer Building Separation. It could also improve validator performance.
My points on MAXEB may seem out of place in a discussion on tokenomics, but this should be considered for Saturn. We only get so many Rocket Pool releases per year (i.e., one). We should not lose the Ethereum forest for the tokenomics trees.
Lastly, I’d like to thank you again for the input from one of our largest node operators. To get any input from a large node operator and investor perspective is important, and it’s one I think should not be minimized, just because it arrived a bit late and a lot of work has been laid on a particular set of tracks.
Thanks,
Chris Rock