RPL Reserve Pool

Summary

After receiving feedback on RPIP003, one of the main pieces of feedback was providing a means for RPL holders who are not node operators to receive rewards. This post is an extension of RPIP003.

The Reserve Pool provides RPL holders who aren’t node operators with the opportunity to stake, participate in governance and receive a portion of inflation rewards.

Abstract

RPL staked to a Reserve Pool acts as a backstop of last resort in a situation where validators are entirely slashed for malicious behavior, and the total amount of RPL collateral staked to the infringing validators is insufficient to re-capitalize the user deposit pool.

The Reserve Pool will:

  • Receive RPL inflation as an incentive to provide liquidity.
  • Be implemented as a Balancer liquidity pool.
  • Require stakers to deposit Reserve Pool Tokens representing their liquidity position to be eligible for inflation rewards.
  • Grant stakers governance weight relative to their liquidity position.
  • Be capped at 90% of RPL staked to validators to ensure that governance weight cannot be captured by large token holders who aren’t running validators

Motivation

The Reserve Pool providing a means for RPL holders who are not node operators to service the network and receive rewards.

A Reserve Pool provides Rocket Pool with an added insurance fund should the protocol become under capitalized, making it one of the more secure places to confidently stake ETH.

The chance of the Reserve Pool being utilized is extremely low, but adds a strong foundation for RPL holders who are not node operators to capture a portion of inflation and participate in governance through a value-added service.

If the pool was implemented simply as a smart contract holding RPL, this RPL would sit idle until an ultimately unlikely slashing event occurs. By implementing the reserve as a liquidity pool we are able to:

  • Provide additional collateral to secure the user deposit pool.
  • Provide RPL/ETH liquidity used by node operators to acquire RPL with minimal slippage.
  • Provide a native price oracle for RPL/ETH used to calculate the required RPL stake for validators.

After researching and investigating several options for the implementation of this pool, we’ve concluded that a Balancer Smart Pool (either Balancer-native or a forked iteration) is most appropriate for the following reasons:

  • Minimized impermanent loss - Using a pool which is heavily weighted towards RPL minimizes the risk of impermanent loss incurred by liquidity providers.
  • RPL Weighting - Using a pool heavily weighted in RPL decreases the need for users to deposit ETH.
  • More customization - Balancer allows us to define more pool parameters and tailor the pool to our specific needs.

We’re working with the Rocket Pool team to determine whether the best course of action is to simply utilize a Balancer pool structure as-is or fork the Balancer pool contracts and fine-tune for our specific application.

This post was created as an addition to RPIP003. We invite the community to give feedback on all the above content to formalize the specific parameters of the Reserve Pool and its placement in the Rocket Pool ecosystem.

7 Likes

What is the added benefit to use a homebrew price oracle when there are solid implementations out there? How would this price oracle work with other liquidity providers that may contribute to the RPL/ETH pair (DEXes like Uniswap, Kyberswap, etc.)?

It is possible that arbitrage bots can contribute to maintain the price across LPs but it all depends on the volume we are talking about.

After some more thought and actual mapping out and development of the contracts, the network will launch using the trusted node DAO to feed price information from multiple exchanges in order to minimise the risk of attack whilst still in launch/growth phase.

The reserve pool will also not be implemented immediately at launch, instead will be rolled out once the core components have been implemented and we feel ready to bring in additional complexity without jeopardising the stability of the network!