As you can see above, chunking splits users deposits into chunks of ‘4 ether’ and distributes them between available smart node operators in the network. This reduces single point failures for larger deposits significantly.

Smart Nodes

Also seen above are smart nodes. In order for a deposit to earn interest, a full Ethereum node must be kept online 24/7 to help keep the network secure. In the Rocket Pool network, these are nodes which can be run by anyone, users or businesses alike. They are called smart nodes as they run additional software which makes them compatible with our smart contracts, allows them to receive deposits and more.

For providing this service, all smart nodes in the Rocket Pool network can stake their own ether fee-free and also earn extra ether by receiving a network-determined fee which is awarded to them as extra income on top of their own interest earned. Oh did we mention you only need a minimum of 16 ether to solo stake if you do it in Rocket Pool’s network as opposed to 32 outside? Well we have now :)

A pretty good deal all round if you want to solo stake!

RPL Token

Rocket Pool utilises several tokens; RPL is our main utility token and is what makes the new decentralised infrastructure network possible.

In Rocket Pool 1.0, the RPL token was designed to be allocated to a smart node’s etherbase account as a signal of that nodes resources using a 1:1 ratio with ether. This way our smart contracts could identify what a node operators confidence was in their node’s resources and assign them the appropriate amount of deposits. Imagine you had a hugely powerful AWS server that could handle staking for more deposits than someone running a node on their tiny laptop in their granny’s basement - obviously the prior user would load up their node with more RPL so they could gain more users, and hence, more additional income.

This was a good approach but some shortcomings were identified, particularly with the change in Casper’s staking requirement from 1,500 ether to 32 ether. A few of these main issues are described below.

Too Many Nodes: With the reduction of Casper’s ether requirement from 1,500 ether to exactly 32 ether, a new attack vector was identified. A whale with a lot of ether and RPL could prevent current node operators from ever receiving new users by adding a large number of underutilised nodes to the network. To ensure fairness and a decentralisation, node operators are assigned deposit chunks via random selection. With a very high number of nodes with lots of capacity, users would not be able to begin staking for a long time - if ever - due to a lot of idle nodes in the network with excessive capacity. A new take on the often mentioned denial of service attack. With the new mechanics describe below, it gets progressively more expensive in terms of RPL required to add underutilised nodes to the network.

Incentivising Nodes: Imagine a huge exchange decided to use Rocket Pool in the background to provide staking services for their users — how would the network automatically incentivise new smart nodes to join or existing ones to add available capacity quickly? The new RPL formula allows the network to self-regulate; incentivising new node operators to join quicker when needed.

RPL now serves as a measure of the entire network’s resources rather than that of an individual node’s, and allows it to respond to capacity requirements dynamically as well as fending off attackers attempting to add underutilised nodes to the network and stalling staking for users.

When a node operator wants to add their smart node to the Rocket Pool network, they must make a deposit of their own ether to be matched with deposits assigned to them from regular users. This ensures they have as much to lose as the users assigned to them if they misbehave or become malicious. The node operator also requires RPL to make their deposit and start being assigned users, the amount of RPL for this deposit is determined by the current network’s capacity.

RPL:ETH ratio formula for node operator deposits.

Above is a visual representation of this formula where:

x-axis: the current Rocket Pool network utilisation (0–100%).

the current Rocket Pool network utilisation (0–100%). y-axis: the amount of RPL per ETH required for a node operator deposit.

As you can see, if the network has a lot of capacity for new users and network utilisation is low (0–5%), it gets exponentially expensive in terms of RPL to add more capacity to the network, either as a new node operator or an existing node operator making additional deposits. This mitigates the Too Many Nodes issue outlined earlier.

As deposits enter Rocket Pool and smart node operators come online, the RPL:ETH ratio reaches an equilibrium of around 1:1 (where it flattens out above). This spot allows for peak usage jumps while still making sure the network isn’t wasting resources by being underutilised.

On the other hand, if Rocket Pool’s utilisation is very high (75–100%) and requires additional capacity to meet demand, it gets progressively cheaper in terms of RPL for smart node operators to deposit ether. This side has a gentler curve to allow more time for node operators to react to increased network utilisation and in turn increase capacity.

Rocket Pool Improvement Process (RPIP)

The Rocket Pool Improvement Process (RPIP) gives the Rocket Pool community influence over the Rocket Pool development roadmap.

It will do this by:

Collecting improvement proposals submitted by the community and providing means for discussion, refinement and documentation of design decisions.

Acquiring community consensus on proposals and prioritising them for the Rocket Pool implementation team.

The Rocket Pool Improvement Process is not an attempt to decentralise Rocket Pool governance, although it may be possible to move in that direction when on-chain governance techniques have matured.

An improvement proposal can be submitted by anyone in the Rocket Pool community. Once the proposal has proceeded through the Rocket Pool improvement process and reached the final status, it is ready to be incorporated into the Rocket Pool roadmap.

RPIP Stages

Anyone in the Rocket Pool community can propose an improvement to the Rocket Pool network. To gather community feedback on the new proposal, it will be submitted to a public discussion site such as a dedicated Discourse or Rocket Pool Reddit. The discussion phase lasts for in indeterminate period but once the idea has coalesced into a form that can be drafted it will be submitted to Github by the RP team as a draft. Here it can be marked as “Accepted” after a review process. When this occurs it will be added to a smart contract where all node operators currently staking in the Rocket Pool network are eligible to vote on the proposal. Their vote weight is equal to the amount of ether they are currently staking.

The voting process is a two-phase voting scheme: commit & reveal. During the commit period, node operators commit their vote, but it is hidden from others to ensure votes do not influence each other and a true reflection of intent is preserved.

If the proposal is passed, it is tagged for inclusion in the Rocket Pool roadmap and marked as Final. If the proposal is not passed it is marked as Not Passed.