RPIP #003 - RPL Staking, Inflation and Governance

Status:

Currently up for community feedback and discussion before implementation alongside mainnet launch.

Abstract:

Rocket Pool has seen many changes over its lifetime, several caused by shifting goal posts regarding ETH2.0 and scaling solutions; others caused by wider token sentiment.

As the next step in this development & evolution, :fire:_ :fire: proposes RPIP #003, which outlines key changes for the RPL token (both mechanism & distribution), the introduction of RPL community governance, and the introduction of slashing protection for the user deposit pool.

RPIP #003 proposes a number of changes around the usage of the RPL token, the introduction of community governance and RPL inflation, and a variety of mechanisms to incentivise protocol growth and protect against system failure states.

We presented the first iteration of RPIP #003 to the Rocket Pool community on Discord a couple of weeks ago, and after gaining community feedback, we then shared the proposal with the wider Ethereum community via a blog post.

The changes introduced after gathering community feedback include:

  • Introduction of passive RPL staking to allow users to participate in governance and receive RPL inflation rewards.
  • Introduction of the overflow pool to further protect the user deposit pool from slashing.
  • Introduction of caps on both the number of validators and the amount of ETH that can be deposited into the user deposit pool to ensure a safe and stable launches for both the Rocket Pool and ETH2.0 networks.

The following changes will be added to this post over the coming weeks as they are finalised:

  • Breakdown of RPL inflation between different stakeholders.
  • Introduction of token mechanisms to incentivise value-added behaviour such as providing rETH/ETH liquidity, participating in governance, and contributing to the growth and development of the Rocket Pool community and network.
  • Changes to the structure of the Rocket Pool DAOs and governance.

More details surrounding inflation breakdown, incentive structures and the specifics of Rocket Pool DAOs will be released in the coming weeks.

RPIP #003 is now nearing the final stages of development so we welcome any further feedback on the proposal and the mechanisms it introduces!

Issue:

RPIP #003 is a pre-emptive solution to drive protocol adoption & growth rather than aiming to solve one specific issue. Encouraging protocol usage (Minipool deposits & Rocket Pool validator creation) and correct protocol governance are two factors that will drive value accrual to Rocket Pool and RPL.

Four core improvements that RPIP003 is looking to address:

  • Validator RPL stake requirements - collateralisation & governance weight.
  • RPL rewards & sustainability - RPL validator rewards, native RPL inflation.
  • Rocket Pool Governance - Rocket Pool DAO (Protocol & community governance).
  • Trusted Node DAO - governance of the trusted nodes which provide ETH2.0 oracle data to the Rocket Pool network.

Rocket Pool 2.5 introduced tokenised staking and the ability to run a Rocket pool validator without staked RPL. This proposal aims to build upon RPL 2.5 and continue to develop towards RPL 3.0 mechanics - Building clear & concise RPL value and security for the protocol.

Solution:

RPL Validator Staking:

Node operators will be required to stake between 10% and 150% of the value of their 16 ETH deposit per validator. The utility of this stake is three-fold:

  • Provides security for the 16 ETH of user pool funds in the event that a > 16 ETH slash is actioned against the validator (consensus attack).
  • Provides one of the metrics used to calculate governance weight in the Rocket Pool DAO.
  • Provides one of the metrics used to calculate validator rewards, proportional to their RPL stake and performance.

The RPL staked by node operators is an overarching stake for all validators they are currently running. For example, if a node operator is running 5 validators (80 ETH in total) they require at least 8 ETH worth of RPL to be staked in order to receive rewards and maintain the operation of all validators.

Validator RPL Slashing:

In the case that a validator is slashed beyond the 16 ETH node operator deposit (due to a consensus attack), the equivalent of the lost ‘user deposit pool value’ is slashed from the validator’s RPL stake and sold for ETH using a pre-established contract or AMM. This ETH is then used to re-collateralise the deposit pool (and therefore rETH).

  • It is likely that in the case of consensus attack, all validators operated by a single node operator would act in the same way.
  • It is also likely that in the case of consensus attack, the RPL stake would sit at the minimum 10%.

If the slashed node operator’s RPL stake is equal to less than 100% per validator, the entirety of their RPL stake is slashed and the overflow pool is used to recollateralise the remaining user deposit pool deficit. If there is insufficient liquidity in the overflow pool, the loss is democratised across the entire user deposit pool.

Initial caps on Validators and Deposit Pool ETH:

In order to ensure the stability of the protocol in the bootstrapping stages, there will be caps on the amount of validators which can be running and on the amount of ETH which can be deposited into the deposit pool.

  • The initial cap on validators will sit at 1000 (TBC) validators.
  • The initial cap on deposit pool ETH will sit at 120% of the validator cap, to ensure that there is sufficient ETH available to be redeemed by burning rETH and that rETH holders receive sufficient rewards.

RPL staking to the Overflow Pool:

Users (rETH holders, passive RPL holders, etc) are able to stake their RPL to the overflow pool in order to:

  • Further protect the rETH pool from validator slashing.
  • Gain governance weight in the Rocket Pool DAO.
  • Receive RPL inflation rewards.

Allowing RPL holders to stake RPL without needing to operate validators democratises governance weight in the Rocket Pool DAO, allows users to take part in Rocket Pool governance and provides additional security for the deposit pool and therefore rETH.

  • In the case that >16 ETH slashing event occurs due to a consensus attack by validators, and the total staked RPL by malicious validators is less than 100% of the ETH staked to those validators, RPL is slashed from the overflow pool to recollateralise the deposit pool (rETH).

RPL Inflation:

RPIP #003 proposes inflation sitting initially at 5% of total token supply per year to incentivise four key actions within the system:

  • Incentivising ETH2.0 staking - Building native inflation incentives for node operators gives Rocket Pool a competitive edge compared to other ETH2.0 staking options.
  • Incentivising RPL stake to protect against slashing - Introducing RPL inflation drives more node operators to stake more RPL, better protecting the deposit pool funds from being slashed.
  • Incentivising Trusted Nodes - These nodes sit in a meta-group above normal Rocket Pool validators, and transmit ETH2 data back to the ETH1 chain. Incentivising the correct relay of this data is critical to the early phases of Rocket Pool development.
  • Providing funding for the Rocket Pool DAO - The Rocket Pool DAO will govern an ecosystem fund which can be used to support a number of initiatives which add value to the network and community. For example, creating deep liquidity for rETH to be leveraged inside the DeFi ecosystem.

Rocket Pool Governance & DAOs:

The Rocket Pool DAO will continue to evolve with community feedback, starting with ‘minimal viable decentralisation’ along with the launch of rETH and RPL staking. This will mark the first step of Rocket Pool governance, starting with a set number of parameters and over time expanding to full protocol upgradability & governance.

Stakeholders:

  • Node operators automatically join the DAO when staking RPL against their validators.
  • Users join the DAO through staking RPL to the overflow pool.
  • Trusted Nodes may participate in wider protocol governance through running staked validators in addition to their oracle duties.

Initial Governable Parameters:

  • Min/max bounds for validator commission rate
  • RPL inflation:
    • Overall inflation rate
    • Allocation of inflation between different areas:
      • RPL staking rewards
      • Trusted Node rewards
      • rETH/ETH liquidity
      • Community incentives

Trusted Node DAO

  • This DAO governs the group of ‘Trusted nodes’ which act as an oracle from the ETH2 beacon chain. This DAO will govern various mechanisms & decisions including:
    • Admission of new trusted node operators
    • Requirements for trusted nodes:
      • RPL stake requirement
      • Amount of validators each node operator must run
      • Other requirements related to oracle duties, data transmission, etc
    • DAO Parameters:
      • Quorum
      • Majority
    • Dispute resolution between trusted nodes:
      • RPL stake slashing for malicious behaviour
      • Ejection of malicious trusted nodes from the DAO

Perceived Benefits:

The benefits of the changes proposed by RPIP #003 include:

  • Stronger incentives to stake to ETH2.0 through Rocket Pool: RPL inflation creates a second-layer incentive to stake using Rocket pool as node operators will receive RPL rewards as well as ETH2.0 staking rewards and commission fees.

  • Enhanced security for users depositing ETH to Rocket Pool: The deposit pool will be better protected from ETH losses caused by malicious validator action (consensus attack on ETH2). The likelihood of this happening is obviously low as the validator would essentially need to be willing to lose their own 16 ETH stake, but the additional RPL stake on validators as well as the overflow pool protects the Rocket Pool network against being used as a collective attack mechanism on the ETH2.0 network.

  • Decentralised control of the system: By implementing a v1 governance system, we can begin to decentralize control over key aspects of the Rocket Pool system. Experimenting with community governance alongside the launch of ETH2.0 Phase 0 gives Rocket Pool a unique opportunity in token governance as well as driving ETH2.0 decision making.

  • RPL value mechanisms: RPIP #003 introduces a number of RPL incentive mechanisms including:

    • RPL stake being required to stake as a node operator as protection against deposit pool abuse.
      • This RPL stake is also used to proportion rewards; more RPL staked = more security for the user deposit pool = more security for rETH = more rewards.
    • RPL staking available for non-technical users through the overflow pool.
      • Allows users to both participate in protocol governance and receive RPL inflation rewards.
    • RPL inflation to grow the Rocket Pool ecosystem.
      • RPL inflation will be used to directly incentivise Rocket Pool security, growth, liquidity, governance, etc.
    • Intrinsic governance value.
      • DeFi systems are only just beginning to experiment with decentralised governance, governing composible token mechanisms with a total addressable market of ~$10b (DeFi). Rocket Pool is currently the only ETH2 minipool provider with an addressable market of ~$40b (Ethereum).

Perceived Drawbacks:

The drawbacks of the changes proposed by RPIP #003 include:

  • Additional complexity introduced in implementation: Adding inflation & community governance will create new challenges for the Rocket Pool community & technical implementation of the Rocket pool system.
  • A token swap will be required as well as the development of a governance portal and updated contracts to include the proposed RPL incentives.

Variables:

Variables involved in RPIP #003 include:

Validator RPL stake:

  • Validator RPL stake is a variable which is chosen by the node operator when instantiating a validator. There will be both minimum & maximum bounds for this stake level, initially set by RPIP #003 and in the future determined by community governance. (RPL Stake = x > y)

RPL Inflation:

  • This proposal outlines a native RPL inflation rate that is initially set at 5% per year - moving forward, this inflation rate will be governed by the Rocket Pool DAO. The breakdown of inflation between different stakeholders will be determined in the same way.

Commission rate:
There are two potential methods for determining the commission fee:

  • Node operators can choose to set their commission rate anywhere between the upper & lower bounds. They are incentivised to set their commission rate as low as possible to gain standing in the queue and have their validators picked up first by the user pool.
  • The commission rate is determined programmatically based on the supply of ETH in the user deposit queue and the supply of available validators ready to pick up user ETH and begin staking on ETH2.0.

If node operators set their own commission rate, the level at which they set it provides part of the inflation reward calculation. A validator with a high RPL stake and low commission rate would receive the highest RPL inflation reward. Inversely, a validator with a low RPL stake and high commission rate would receive the lowest RPL inflation reward.
The minimum & maximum bounds for commission rates is another variable which will be controlled by community governance.

TLDR

RPIP #003 proposes a number of changes around the usage of the RPL token, the introduction of community governance and RPL inflation, and a variety of mechanisms to incentivise protocol growth and protect against system failure states.

Four core improvements that RPIP003 is looking to address:

  • Validator RPL stake requirements - validator collateralisation & governance weight
  • Opportunity for non-technical users to stake RPL; contribute to protocol security, participate in governance and collect RPL inflation rewards.
  • RPL rewards & sustainability - validator RPL rewards, native RPL inflation, user RPL rewards
  • RPL Protocol Governance - Rocket Pool DAO (Protocol & community governance)

RPIP #003 proposes a new system where node operators:

  1. Align validator incentives to protect the user deposit pool against slashing.
  2. Protect the entire Rocket Pool protocol against being leveraged as a collective ETH2 attack mechanism.
    • Staked RPL is automatically assigned Rocket Pool DAO governance weight and has proportional voting power used to determine protocol parameters.

Validators are rewarded based on:

  1. Staked RPL
  2. Set or be assigned a commission rate
  3. Liveness (validator performance)

These rewards are introduced by native RPL inflation (proposed at 5% annually) which directly incentivises Rocket Pool security, growth, liquidity, governance, etc.

The introduction of RPL inflation allows value-added actors to accrue the most RPL tokens and therefore, play an active role in the protocol governance and its future growth.

Node operators collecting inflationary rewards via validators they have instantiated introduces a clear-cut demand mechanism for existing RPL in line with the growth of Rocket Pool validators in ETH2.0 and the requirement for RPL as collateral.

All elements & exact numbers from this proposal are still under development and are yet to be confirmed. We encourage feedback from all members of the Rocket Pool community to further ideate and develop robust incentives to underpin the Rocket Pool ecosystem!

10 Likes

Quick follow up - We’ve heard all the amazing feedback in Discord and are in the process of presenting follow-ups and deeper details on all of the above (plus much more) very soon!

Be on the lookout for more from the :fire:_:fire: early next week :rocket:

2 Likes
  1. Asking validators to stake RPL but determining the amount in terms of ETH staked requires an oracle. Do you plan to query Uniswap or chainlink? Is oracle-dependence a good idea for a project that aims to grow explosively?

  2. Constraints have been placed to limit growth of pools, is this a good idea? Shouldn’t we aim to grow rapidly? One could create formulas to determine things rather than hard caps.

  3. More constraints/complexity also lead to gas inefficiency, has this been studied?

  4. RPL’s primary uses are staking and governance (ideally requires staking too, snapshots have weaknesses). If most RPL is staked, this could lead to illiquidity of Uniswap pools especially in early stages. This could possibly lead to rapid price swings and validators having to quickly respond by staking/unstaking.

1 Like
  1. Can we consider a more rapid but short-lived inflation schedule? This project needs an early critical mass of users to grow, so we could maybe run a 50-100% APR inflation schedule but run it only for a month after launch. Total inflation will be the same but it’ll be offered in a shorter span of time instead of longer over a year.
1 Like
  1. Can we consider time-locking of tokens for governance and reward accrual?

This project as it currently stands, does not really need a token. You could just ask validators to stake 10% more ETH, and you could let all current validators vote to change collateral requirements and other things proportional to their stake.

If the objective is to align short-term participants with long-term participants, then a token by itself does not achieve this, validators can just buy the same token and continue pursuit of their short-term goals.

Timelocked tokens however solve this problem.

2 Likes
  1. What is the base for the collateral value percentage? E.g. the node operator’s initial deposit (16 ETH), the validator’s total initial balance (32 ETH), or the validator’s current balance (including staking rewards or penalties)?

  2. What would be the practical use of overcollaterization on a node? If a node is slashed/penalized for more than the node operator’s share of ETH, will the node operator lose just the RPL value that isn’t covered, or will the entire RPL stake be slashed?
    If the former (RPL stake is only reduced by the difference in value) then overcollaterization doesn’t actually provide extra security to the network, does it? In which case it should also not earn extra rewards above 100% collateral.

  3. Staking a large RPL collateral comes with an opportunity cost - if above 16 ETH in value, the node operator could have run another minipool instead. How can the operator evaluate whether this is worth it compared to the additional RPL rewards of this extra collateral? And how can we provide enough incentive for such a large collateral?

  4. What happens if, through RPL market price fluctuation, the RPL collateral value drops below 10% or rises above 150%?

1 Like

1. Asking validators to stake RPL but determining the amount in terms of ETH staked requires an oracle. Do you plan to query Uniswap or chainlink? Is oracle-dependence a good idea for a project that aims to grow explosively?

With the introduction of the Reserve pool for passive RPL staking, we are planning to implement this pool as a liquidity pool (80/20 RPL weighted Balancer-style). This serves several purposes which will be detailed in upcoming documentation but one of these is to provide a native price oracle which removes the need to depend on an external party such as Chainlink. This pool will be incentivized and likely become the primary source of liquidity for Node Operators moving between RPL and ETH.

2. Constraints have been placed to limit growth of pools, is this a good idea? Shouldn’t we aim to grow rapidly? One could create formulas to determine things rather than hard caps.

Constraints on both the amount of ETH which can be deposited by users and the amount of validators which can be live on the network at launch have been introduced as protection against failure states both on the Rocket Pool network and the overarching ETH2.0 network. While we want to grow Rocket Pool & ETH2.0, we don’t want to expose either network to risky levels of growth at launch, being purposeful about network launch and growth is an important step for the safety of both networks. This has been discussed at length between fire eyes, Rocket Pool core team and ETH2.0 client teams.

3. More constraints/complexity also lead to gas inefficiency, has this been studied?

We’re aware of introducing unnecessary complexity into the smart contracts and have had ‘technical sanity checks’ often as we’ve moved through this process. We’ve been incredibly impressed by the Rocket Pool team’s ability to rapidly develop and iterate on the required smart contracts and technical elements of the network. These are still in the works and will be audited and presented to the community in the future.

4. RPL’s primary uses are staking and governance (ideally requires staking too, snapshots have weaknesses). If most RPL is staked, this could lead to illiquidity of Uniswap pools especially in early stages. This could possibly lead to rapid price swings and validators having to quickly respond by staking/unstaking.

As mentioned above, the introduction of an incentivised, native liquidity pool which is used for passive RPL staking solves for much of this issue. We’ll also be allocating a portion of RPL inflation to ecosystem incentives which include external RPL/ETH and other RPL/XXX pairs’ liquidity. More detailed discussion and research into the levels of liquidity required to ensure the stability of both the native price oracle and the wider system are being carried out currently.

5. Can we consider a more rapid but short-lived inflation schedule? This project needs an early critical mass of users to grow, so we could maybe run a 50-100% APR inflation schedule but run it only for a month after launch. Total inflation will be the same but it’ll be offered in a shorter span of time instead of longer over a year.

Rocket Pool has been under development both in technology and community for over 3 years. We believe that the incentives proposed in RPIP #003 will be sufficient to grow Rocket Pool at a healthy and stable pace in line with the various phases of ETH2.0 launch. A rapid ‘defi-esque’ 50-100% inflation schedule is likely to lead to us attracting the wrong kind of actors to the network who will not be aligned with the long term goals of Rocket Pool and ETH2.0, as well as a potential mass exit of participants when an incentive program like this winds down.

6. Can we consider time-locking of tokens for governance and reward accrual?

This project as it currently stands, does not really need a token. You could just ask validators to stake 10% more ETH, and you could let all current validators vote to change collateral requirements and other things proportional to their stake.

If the objective is to align short-term participants with long-term participants, then a token by itself does not achieve this, validators can just buy the same token and continue pursuit of their short-term goals.

Timelocked tokens however solve this problem.

At the time of ETH2 launch there will be multiple different staking as a service providers - by time-locking RPL rewards we directly reduce incentives for node operators to choose to run their validators using the Rocket Pool network. Getting rewards in the hands of early node operators as soon as possible continues the growth loop of the network - node operators earn more RPL, giving them more collateral to spin up more validators and further the growth of the network.

RPL inflation is proposed to sit at 5%, the majority of which will go to node operators - unlike the DeFi tokens currently emitting huge percentages of their market cap, Rocket Pool is only distributing a small amount of RPL here, locking this allocation is unlikely to have much of an impact on RPL.

3 Likes

i’m from brazil wanted to know if the roeckettera ambassadors community can promote rocketpool among other things?

1. What is the base for the collateral value percentage? E.g. the node operator’s initial deposit (16 ETH), the validator’s total initial balance (32 ETH), or the validator’s current balance (including staking rewards or penalties)?

The base is the 16 ETH deposit coming from the Node Operator. The validator’s current balance is not used in these calculations.

2. What would be the practical use of overcollaterization on a node? If a node is slashed/penalized for more than the node operator’s share of ETH, will the node operator lose just the RPL value that isn’t covered, or will the entire RPL stake be slashed?

The 150% figure is essentially protection against volatility - if the value of RPL drops against ETH, a Node Operator with 150% collateral will be protected for ~30% price drops and maintain full collateralization. If a slash occurs for the full 32 ETH and the Node Operator is over 100% collateralized, only the value of the 16 ETH deposited by the user deposit pool will be slashed from the node operator’s balance.

3. If the former (RPL stake is only reduced by the difference in value) then overcollaterization doesn’t actually provide extra security to the network, does it? In which case it should also not earn extra rewards above 100% collateral.

Again, the 150% figure has been decided as a protection mechanism against volatility. At any point when the ratio is over 100% this RPL is not technically providing additional security, but in any case where the RPL price drops, this additional collateral becomes important. For example, if a validator is only 100% collateralized and the RPL price drops by 15%, the validator is then only 85% collateralized. Having additional collateral protects against this scenario. As the economic security and stability of the network increases, this 150% figure could be adjusted by governance.

4. Staking a large RPL collateral comes with an opportunity cost - if above 16 ETH in value, the node operator could have run another minipool instead. How can the operator evaluate whether this is worth it compared to the additional RPL rewards of this extra collateral? And how can we provide enough incentive for such a large collateral?

We don’t expect all Node Operators to maintain a collateralization ratio of 100% or more, the option to do this allows Node Operators to secure the network more if they want to, and receive additional rewards for doing so. We’ve modelled out the proposed inflation schedule and think that the incentives are sufficient to incentivize this opportunity cost. Models and further research will be released to the community over the coming weeks/months!

5. What happens if, through RPL market price fluctuation, the RPL collateral value drops below 10% or rises above 150%?

If a Node Operator’s collateral drops below 10%, they are unable to claim rewards for that period. A trailing rewards claim system is being developed currently, and incentivises Node Operators to maintain their collateral at above 10%. They will be able to top up their collateral at any time. It’s also worth noting that with the introduction of the reserve pool, there is additional security for the user deposit pool and it is not a huge concern if Node Operators themselves aren’t collateralised by at least 10% at all times.

Similarly, if the collateral ratio is over 150%, the node operator will only receive rewards for the first 150%. Any collateral (caused by RPL price appreciation) outside of the required 10% to claim rewards is able to be withdrawn at the time of rewards claim, subject to a cooldown period.

2 Likes

@ghosts_in_the_code @Pieter - Thanks for all of your feedback and questions! This is an iterative process and your input helps us to build a more secure and healthy Rocket Pool network!

Be on the lookout for more detailed documentation on the above in the coming weeks! :rocket:

3 Likes

Thanks a lot for the detailed reply.

This form of collateralisation + oracle model hasn’t really been tested before. I guess that has both pros and cons, we’ll only know when it’s actually live.

  1. One more problem I see is validators having to quickly stake or unstake in response to price movements, since the most of the RPL is sitting with validators and not as liquidity. Staking/unstaking will happen a) to meet collateralisation requirements using minimum capital b) to trade RPL or minimise exposure to RPL price. When RPL price goes up they will want to book profits, when RPL price starts go down they might want to sell and exit for a while till the whole drop occurs. The frequent staking / unstaking will also lead to many voluntary exits which could potentially be a problem for ETH 2.0

  2. I was suggesting timelocked tokens not necessarily for the node operators themselves, but for anyone who wants to participate in governance, or earn more fees. If node operators themselves are the main RPL holders, and these tokens are not timelocked, it becomes possible for them to change commissions to prioritise their own short-term gain over long-term sustainability. A few whales could buy up a lot of RPL and influence the future of the project (while simultaneously dumping), this has already happened in protocols like Curve and SushiSwap.

You could go for a decision-based timelock like Uniswap but then that makes more sense for a mature protocol that doesn’t have to react quickly to anything.

In any case, please don’t use snapshots. Atleast mandate timelocking for a couple hours. Snapshots allow people to buy or loan the assets pre-vote and sell after.

was seeing for those who have 16 eth is it possible to make staking but for those who have less than 16 eth will it be possible to make this staking process be a stakers in the main network?

I notice that there hasn’t been any community discussion on the “liveness” or validator performance aspect of RPL rewards. Looking at the Discord discussions of beta testers on Medalla it is clear that there is every variation of admin expertise ranging from complete noobs on home computers through to sophisticated systems administrators.

While the node operator requirements for ETH and RPL guarantee to a great extent against loss of ETH from negligent operations there seems to be little protection against node operators who are not as sharp as they could be eg not keeping their clients up to date, running systems which perform poorly by missing attestations etc but not so badly that their ETH balance goes backwards.

Because rETH earnings performance is RP network wide it could be that it underperforms compared to a highly efficient proprietary staking farm. This could be detrimental to the public perception of RP as a preferred staking option.

I would like to see a significant proportion of RPL rewards go to well run validators producing the highest returns for the RP network. Ideally this would see a small well run node operator be able to expand their service via re-investment of RPL rewards. Perhaps there could even be a node operator competition with RPL prizes for those doing the best job for the network.

4 Likes

excellent analysis everything has to be discussed now in the beta phase because it is easier to implement

1 Like

Likewise! The detailed diligence is awesome and helps us to build a stronger system :tada:

  1. There isn’t a super simple answer here, if validators are planning to sit at the minimum 10% collateralization ratio then they’ll essentially be risking losing rewards if their collateral drops below the threshold.

Regarding topping up/withdrawing RPL as a node operator:

  • Topping up RPL can be done at any time.
  • Withdrawing RPL can only happen once per *period at the time of rewards claim, and is subject to a one month cooldown delay. (Exact timeframe for the cadence of rewards isn’t confirmed yet!)

The delayed withdrawal mechanism was introduced due to:

  • Technical complexities involved in allowing withdrawals at any time.
  • To address the issue of validators constantly depositing/withdrawing to maintain rewards exposure with minimal capital.
  • To prevent governance attacks caused by node operators acquiring large amounts of RPL to swing governance votes before dumping immediately after the vote.

Regarding exits from ETH2.0, validators will keep running if their collateral drops below 10%, they just won’t be eligible for RPL rewards. There is no need to exit from ETH2.0 unless a node operator plans to offload all of their RPL and stop staking through Rocket Pool altogether.

  1. We’re still working on the finer details around timelocking tokens for governance, as mentioned above, the cooldown period after voting and/or withdrawals for node operators is in place to address this. For reserve pool stakers, we’re working on additional mechanisms which will prevent governance attacks, as well as the cap on overall deposits to the reserve pool which prevents the governance weight of these stakers from becoming larger than the node operator group.
2 Likes

When we roll out Genesis Governance, only the RPL stake will influence RPL rewards and governance. This is primarily for simplicity in the implementation and will be updated to include the liveness score as governance matures. The liveness score will have significant influence on rewards when it is implemented in order to incentivise node operators to do the best job possible!

The idea of competitions and prizes around liveness and other performance/value provision metrics is a great one and something we’ve discussed, introducing ‘soft’ incentives like these to reward value-added participants such as well-performing node operators, engaged community members and other individuals/teams integrating Rocket Pool or rETH is on the agenda for community governance for sure!

1 Like

Suggestion: Make the staking RPL optional, but still provide the benefits in RPIP3, such as governance rights, to users who do stake RPL.

I thought the reason that forced RPL staking was originally removed was because the added friction this added to on-boarding node operators. If I am an ETH2 node operator, and rocketpool doesn’t require RPL staking, then making my validator available through rocketpool is a no-brainer, as I only stand to gain more money through providing staking as a service to others. Once RPL staking is required I now have to to analyze the costs and risks of buying RPL and assuring this remains up to the minimum collateralization ratio. This is no longer a no brainer. Below is an aside on how I think about the role of RPL staking:

RPL Staking is Essentially Insurance
The rocketpool nodes provide a service, staking for others and providing the skills and knowledge of running a validator. For this they get paid a slight premium by the passive stakers. This is their reward for running a rocketpool validator. Staking RPL is essentially now providing an insurance service to reduce risk for passive stakers. For this service, a rocketpool validators reward is inflation RPL. Staking RPL is more capital inefficient for the validators, thus they expect higher rewards for this service. Since their reward for this insurance is inflation RPL, this fee for this insurance is essentially paid for by the passive RPL holders. This is all good, as RPL holders should be providing a some positive value add to the rocketpool protocol, or paying for others to do this. Checks out for me, I like this model.

If we allow validators to join without providing staked RPL, perhaps we can give them a smaller percentage of the RPL inflation (when compared to validators with RPL staked) based on good performance. This way they can eventually enter the staking ecosystem without providing extra capital they might not have at first (which is why they may have wanted to to join rocketpool in the first place). They are still providing value to rocketpool ecosystem thus the RPL holders shouldn’t mind paying a small fee to them for entering the ecosystem. Once they earn enough RPL they can either sell it or stake it and provide extra value to the ecosystem and be paid even greater by the RPL holders.

This creates an even greater win-win for people and keeps the no brainer aspect to joining the rocketpool ecosystem, while still using token economics to encourage behavior that benefits all actors. Part of the success of Uniswap was how easy it was be a LP without having to deal with anything else. It should be that easy for validators to provide their services to rocketpool. What is everyone’s thought on this?

I believe that inflation makes sense to reward value-add actors.

However, I believe that the value of RPL needs to be directly backed by the underlying protocol token ETH.

If RPL has its value resting on the sentiment of the public (those to whom RPL may be sold), then the value of RPL is actually NOT something that value-add actors can bank on.

My proposal is to rest the value of RPL upon the actual value it is creating, the ETH rewards it is minting and the ETH commission which is being collected.

I propose that the inflation rate of RPL be pegged directly to the rate at which this value is being created. Let RPL be minted as a tokenized representation of the actual value-add: rewards+commission.

In keeping with the fat protocol theory, a token who’s value is puffed above the base protocol by speculation and sentiment will be flattened over the long term.

Allow RPL to settle to its most stable and flat value, let it represent the rewards and commission of Rocketpool.


Here is how the inflation rate would operate:

RPL is minted and given to node operators, in DIRECT proportion to the ETH rewards and Commission being accrued by that node. For example: if the network is accruing ETH rewards at a rate of 6% APY plus 10% commission ( .06% APY ), then RPL is minted at a rate of 6.06% and given directly to the node operators in proportion to their stake and pool.

RPL may then be redeemed via smart contract for the rewards and commission they represent. A base-price will be payable when liquidity is available, based on the value-add of RP network (.0606 ETH per RPL in the above example)

The specific value of RPL compared to ETH can be above this base price when agreed upon by open market forces, and if so, there is an incentive for Rocketpool to retain the value RPL represents, as the base price payout cannot beat other opportunities available to an RPL holder. If RPL price rises above the minimum payout, RPL will be used elsewhere and Rocketpool will retain the ETH within its pools.

The current market price may rise above this value-add minimum based on usefulness, sentiment, and function in other DeFi projects… any price above this base network-derived minimum price will be relayed via Oracles, and the excess market price may be informative to the smart contract in many ways, such as the minimum RPL stake required to achieve the elevated status of Oracle or Trusted Node.


RPL is burned when it is redeemed for ETH and the coin remains flat and stable, sentiment only plays a very small part, therefore the fat protocol theory is respected.

If RPL is kept and instead re-staked by a node operator, a larger proportion of RPL rewards are given. In this way, incentive is given to re-stake RPL and allow value to grow within Rocketpool and the other DeFi projects which happily accept a backed coin.

RPL re-staking may also be incentivized by the governance weight it provides, all while being backed by the actual base layer protocol token, ETH.

An added benefit of this model is that RPL will have a “base value” represented by the network value-add, and will not be at risk of dropping through the floor if every validator exits. If every validator exits, all of the ETH they have staked will return to them, all of their ETH rewards and commissions will be fully liquid and may be claimed at the minimum, most recent value-add price of say .0606 ETH per RPL via smart contract. This also means that rETH remains unaffected and fully backed.

RPL value in this model has a stable base in RP value-add but may also capture the value of its use in other DeFi projects, the open market will decide what it will be worth.

To be clear, in this proposal model, when a validator exits, they are given ONLY THE AMOUNT OF ETH THEY ORIGINALLY DEPOSITED. The rewards and commission are given to the entering queue and overflow/exit ETH pool in order to back rETH and RPL, and to protect against slashing.

1 Like

I agree that requiring a minimum stake of RPL introduces friction and a barrier to entry. Your suggestion to provide a small baseline of RPL rewards even to validators who do not stake RPL, based on their performance, sounds great to me.

One complicating factor here is network security though. We want to avoid attackers to be able to leverage the Rocket Pool network to attack ETH2. Since a node operator gets 16 ETH from the Rocket Pool network, they could leverage that extra 16 ETH for an attack. The lower the minimum extra RPL requirement, the greater the leverage for such an attacker, so this has to be carefully considered.

Generally agree with @ZkZak’s notion that the primary community that needs to be incentivised is that of the node operators - and we should be focused on enabling them to onboard without any difficulty. In that sense, it may make sense to have some notion of vesting in terms of RPL rewards for validators - and maybe some of this could be held in the reserve until claimed.

Additionally, (in conjunction with the work on Internet Bonds by Collin and Mara) - it might be conducive to amp up the inflationary rate of RPL rewards to at least match the pre-genesis discount rate of 20% in order to boost additional validators to join the RPL network as an early moat until we have a milestone of 1000 validators (with maybe an additional buffer); feel that network dynamics would be a nice way to control the inflationary mechanisms (as suggested by @TwoCanSpam) but this would still take time to pan out given how early we are in the cycle.