Hi Knoshua, thank you for detailed response - I appreciate the time you spent reviewing the proposal and compiling such thoughtful questions.
The 1kx ideas seem to be in a very early stage and as presented here don’t amount to a coherent proposal that can be considered for vote.
Bottom line is that there is no 1kx proposal, just some loose ideas with giant holes and there seems to be no interest to do anything productive
Our goal with our proposal is to provide an alternative choice to those who are not in favour of the rework. As per LongForWisdom’s comment:
We can make sure that the governance route we take makes space for 1kx’s proposals as an alternative or addition. ie, when we do a forum vote, we can add a poll on 1kx’s proposal + ideas, to find out if there’s desire to explore them further.
We need to ensure the community has enough information to make a choice between the proposals, but it is not necessary for every protocol parameter be fully defined in order to make a comparison. Just as we can discuss whether UARS is a good idea without knowing whether no_share is x% or y%, we can assess the components of our proposal without having every protocol parameter defined.
Some of your questions will require significant time investment to answer in full detail. We are happy to commit resources to building models and performing analysis but we first want to know if there is community support for the idea. If 90% of the community is happy with the rework direction, the in-depth analyses to define our protocol parameters are not required. The first step is for the community to select a direction. Once a direction is selected, protocol parameters can be finalised.
And speaking of timelines: we are making a decision that will affect Rocket Pool for years to come. Let’s not delay unnecessarily, but let’s also not be hasty. There is a lot of value at stake here, and rushing would be reckless.
We hope that, if the community expresses a preference for our direction, the rework proposal authors will be willing to work constructively with us to bring this to market as soon as possible. They have a lot of valuable knowledge about the protocol, and the final outcome would be stronger with their input, so it would benefit the entire community for us to work together.
We have acknowledged that our proposal is in an earlier stage, and we would need some time to finalise the protocol parameters in collaboration with the community, but there is no reason this should lead to significant delays. If our proposal is accepted, 1kx can dedicate resources (dev, data analysts, etc.) to ensure the proposal is ready for implementation within similar timelines. Many of the components (megapools, bond curves) as the same as in the rework albeit with different parameters, so implementation time for many subcomponents will be identical.
As Val mentioned there is certainly room to speed up the discussion process. We would propose weekly/biweekly community calls to facilitate efficient discussion of the protocol parameters and ensure we are ready for launch as soon as possible.
I would appreciate someone from 1kx answering these questions I had so far.
The difference in your communication style between Discourse and Discord is so striking that I had to double-check the username to ensure it was the same person.
Accusing me of “playing stupid games” when I am actually posing thought experiments to highlight flaws in your proposal is dismissive and unproductive.
LFW has lamented, more than once the lack of response to the proposal authors’ solicitations for feedback. When those who provide feedback are met with unprofessional and personal comments, the lack of response should come as no surprise. I hope you will consider how your attitude may be contributing to this lack of response and whether this lack of feedback helps or hinders Rocket Pool.
I hope the answers below help address some of the perceived “giant holes” in our proposal, and show the rest of the community that we are indeed trying to do something productive here.
Under what conditions is delegating to a node allowed?
The node must be under the max_collateral_ratio in order to receive delegation.
Under what conditions is undelegating from a node allowed?
There are no restrictions on undelegating. There are arguments to be made for limiting restrictions to smooth out changes, but this increases friction for stakers.
Undelegation takes affect at the end of the next rewards period (or on some other cadence, but after any RPL penalties have been applied).
How does delegated RPL interact with RPL the operator stakes themselves?
A NO who stakes on themselves is effectively delegating to themselves. All RPL delegated to a node is in a single pot, if slashed all delegators (inc. NO) are slashed proportionally to their share of the pot.
How is “a share of validator rewards” calculated in case of: multiple people delegating RPL, set of people delegating changing over time, when operator uses the smoothing pool, when “delegate of last resort” is active?
- Multiple people: delegates earn rewards (or get slashed) proportionally according to their amount of delegated RPL compared to the total RPL delegated to the NO.
- Changing delegates: delegation changes take effect at the end of a rewards period. At the end of each period, delegates who were active for the entirety of that period are rewarded. i.e. if you join midway through a period, you begin accruing rewards at the beginning of the next period.
- Smoothing pool: we propose requiring all NOs using delegation to join the smoothing pool.
- Delegate of last resort: incoming rewards are reduced by recollateralization_share. Remaining rewards are then divided as normal.
What happens to existing node operators when max_commission_rate is changed?
To simplify rewards calculations, max_commission_rate changes take effect at the beginning of the next rewards period.
If max_commission_rate is increased, no_share does not change, so the benefit goes to delegate_share/extra_reth_share. NO can decide whether to increase no_share.
If max_commission_rate is decreased, no_share is reduced proportionally, such that the no_share/delegate_share/extra_reth_share ratios remain unchanged.
Can the operator change no_share? Under what conditions and how?
Yes, by sending a tx from the node wallet via the smartnode interface.
Conditions would be similar to changing voter_share - the rate can only be changed one per rewards period, and the size of the change is limited to a percentage of the current value. This gives predictability to delegators, as NOs cannot rapidly and repeatedly change their no_share.
What value is proposed for recollateralization_share? How does it interact with the other shares when active?
We can provide a model for this show the effect of different values at different projected rewards levels. The value should be higher than the prevailing average delegate_share, as recollateralization should be more expensive than delegation.
In terms of interaction, it is also similar to UARS. If recollateralization_share is active, that share of the rewards is subtracted from the total rewards. The remaining rewards are then split according to the defined shares.
What does “strategically allocated between delegate_share and extra_reth_share” mean? Is there a setting? What is the proposed value?
It means that it is set according to RP’s strategic goals. If delegation is not attractive enough the ratio can be changed to send more value to delegates. If we feel delegates are being paid too much we can send more value to extra_reth_share. It is analogous to how UARS allows changing voter_share/surplus_share to incentivise different behaviours.
Yes, this would be a protocol parameter. Proposed value is open to discussion - the illustrations show 50:50. As above, we can provide a model for this to show indicative values.
How are you addressing system brittleness? How does profitability of a megapool compare to a solo staker assuming 3% solo APY and 1.5% RPL value loss per year due to supply inflation?
As with the rework, the answer here depends on a number of protocol parameters and market conditions (amount of staked/delegated RPL, prevailing delegate_share or surplus_share values, etc.). Given that the value stream is the same in both cases, and the key difference is in the distributions, you can actually assume similar profitability to UARS in comparable scenarios. For example, assuming our max_commission_rate is equal to the rework’s reth_commission, a NO with maximum no_share who has self-delegated maximum RPL will earn equivalent rewards to a NO who is earning maximum voter_share (assuming surplus_share=0).
A NO who has relied on delegates for their RPL would have a lower no_share. Their rewards would be similar to a NO under UARS who has not staked any RPL and is therefore getting zero voter_share.
Given the complexity, it might make sense to work on a shared model which allows comparison of both proposals based on the various parameters. Happy to connect you with one of the 1kx data analysts if you would like to contribute here. We have already created a model for comparing changes in staked RPL under each proposal which is linked in the steel man doc.
Even though the value stream is the same we believe this offers a better deal to all participants, because the rewards are shared between the NO, their delegates, and rETH, without the voter_share value extraction.
The “10% borrowed-ETH minimum” is something that would be enforced by the protocol over time, assuming a) the collateralization rate is set to 10%, and b) the protocol continues to earn fees.
With regards to the second component:
The market has no way to signal that they’re interested in Rocket Pool at a minimum RPL stake set at 8% borrowed ETH versus 10% borrowed ETH. All we’d see is that the market simply stops making minipools (or even starts exiting them) when the overall package is seen as unattractive
Recollateralization removes the necessity for NOs to exit validators. New NOs can still join via the “first n validators” mechanism. For ETH-only NOs, ultimately their decision will be driven by the no_share on offer, just like in the rework.
In terms of signalling, if we see many undercollateralized nodes then we can assume the collateralization requirement is too high. Similarly, if some percentage of NOs are at or near the max cap we can assume it is too low.
So we address both aspects of this, reducing the incentive to exit, and the blockers to joining.
What is no_share for nodes that are in the “first n validator” state and are collateralized with pDAO-owned RPL? If they exist, what happens with pDAO owned rewards?
We propose max_commission_rate-recollateralization_rate as an initial value, but this could be adjusted by pDAO. pDAO owned rewards are automatically restaked, just like a normal delegators rewards. pDAO-owned RPL could also be unstaked and added to treasury RPL.
Where do funds to collateralize “first n validators” with pDAO-owned RPL come from? Can we ensure we don’t run out of funds? If so, how? If not, how many “first n validator” nodes can we support? What happens after?
There is no need to purchase this RPL in advance - it is purchased using recollateralization_share of the validator rewards. Essentially the first n validators start in an undercollateralized state, and are then recollateralized as normal. This ensures that we do not run out of funds. The theoretical limit of this is the 22% self-limit.
Is recollateralization_share the only source of protol-owned RPL?
No. Protocol-owned RPL which is delegated will earn RPL yield.
How long will it take to bring a node back to minimum that has dropped to 5% for the proposed (or a range of options for) recollateralization_share?
This of course depends on the RPL/ETH ratio and ETH bond size of the NO’s validators. We can model this for a range of permutations of these values.
Please also note that staking rewards are automatically restaked. That is, RPL purchased with delegate_share is automatically restaked, further increasing the collateral on the node and accelerating recollateralisation. So the recollateralization rate is actually (recollateralization_share+delegate_share).
What happens when a node with protocol as “delegate of last resort” reaches the minimum?
Recollateralization stops. The protocol-owned RPL continues earning yield from delegate_share.
Can you provide estimates for how much RPL the pDAO would aquire over say 3 years, how that compares to total RPL supply and
Yes, we can model this. Have you already completed the same analysis for buy+burn/buy+lp options? If so please share and I’ll try to ensure we provide the data in a similar format to simplify comparison. This would be a nice thing to include in the shared model, if we build one together.
how much impact pDAO delegating to protocol-aligned operators could have?
This is ambiguous, please be specific so I can answer accurately - what do you mean by “how much impact”?
Can you share your research that shows there is further room to safely enhance capital efficiency?
Yes, I will ask our data analysts to prepare our internal research for publication.
You give an example of C(1)=4 ETH and p=⅔. Does your research show these values to be safe? Why did you call it an example? What is the proposal?
I called it an example because it is the curve used in the illustrations, and that specific p value might not be the one adopted after community discussion. There are valid arguments to be made for different values, similar to the ongoing discussion about the initial values to use for UARS.
Given that the scope is already big here and anything we can do to reduce it (or areas for disagreement) is a win, let’s defer this part for future discussion, and exclude it from our proposal for now.
The bond curves described in RPIP-42 already provide significant increases in TVL, and combined with keeping the collateral requirement, this ensures we maintain robust security while optimizing growth.
You mention pDAO delegating RPL at variable commission rates here. Is this the “first n validator” idea mentioned earlier or in addition to it?
In addition. The goal of “first n validators” is to eliminate friction for new NOs. From their perspective, there is no collateral requirement.
The goal of pDAO delegation is providing subsidies to protocol-aligned NOs.
Where is pDAO RPL for delegating coming from? How does the proposal ensure enough funds or what happens if funds run out? Any estimate of size of this programm?
Yield from protocol-owned RPL. If it runs out there will be more RPL available in the next rewards period. Size depends on amount of RPL delegated. IMO it would not be necessary to bootstrap this program - so many nodes are currently undercollateralized that, if recollateralization were enabled, purchases from recollateralization_share would immediately begin acquiring protocol-owned RPL, which would immediately begin earning RPL yield.
How does prioritization of “lowest validator count”, “lowest no_share” or “highest staked or delegated RPL” work? What happens when these values change for operators in queue?
The simplest and our recommended approach is lowest validator count. In order to game this a NO would need to exit existing validators to reduce their validator count, just so they could rejoin the queue - very irrational. Using lowest no_share could also work - it would be slightly more susceptible to gaming, but the fact that no_share can only be changed once per rewards period might be sufficient mitigation.
In both cases, no action would be required if these values change. Validator count is impractical to manipulate, and no_share likely cannot be changed frequently enough to have a significant impact.
What are the proposed changes to how RPL collateral is used? What is the proposed penalty system?
To begin with, MEV theft as defined in RPIP-42, with the addition of RPL penalties. We would consider proposing making this a scaling penalty (more validators = larger penalty). In a future separate proposal we would also propose introducing performance penalties, scaled to have more impact on larger entities, with exceptions for small stakers. We are monitoring the research on correlation penalties - if there is a trustless way to recognise correlation penalty events we could increase their effect within RP to further encourage decentralisation for large NOs.
How does it interact with the delegation system? (Multiple delegators, potentially including pDAO, mix of delegation and self stake)
The NO and pDAO are treated equally to other delegators. Any penalties are applied to the total RPL delegated to that node, affecting all delegators proportionally to the amount of RPL they staked.
Thanks again for the questions. Please let me know if you have any followups.
