RPIP #001 - Deposit Queue System

Status

Abandoned in favour of RPIP-003.

Abstract

After talking to a selection of SaaS providers over the last few months and with a change in queue mechanics for v2.5, it’s become apparent that the process for ETH assignment from the queue to node operators could use a more refined approach to allow node operators to develop appropriate strategies for obtaining certain commission rates when deploying minipools. This proposal would help motivated node operators to generate a better ROI, have more control over the process, get staking quicker if desired and improve queue efficiency. This new approach also has several side benefits of allowing node operators to receive 100% of the rewards generated by the network.

Issue

The commission rate is determined by two main factors, amount of ETH in queue awaiting assignment and the minipool validators capacity. Whenever either of these values change, the commission rate is updated. The minipool and deposit queues are currently FIFO (first in, first out). Currently when a node operator deploys a minipool validator, they set a min commission rate they would like to receive. This is done in case the commission rate is too low for their liking by the time their minipool is due to receive a 16ETH chunk from the deposit queue. If the commission rate is below what they have set, the tx will revert.

This can make it unpredictable for node operators to know what commission they might receive unless they constantly monitor the queue and hope their minipool is created & assigned ETH when commissions are high + hope not too many minipools were already awaiting assignment before theirs. This also has the side effect of node operators not creating minipools until there is a decent amount of ETH in the queue to generate a higher commission, this potentially increases idle time of that ETH when it could be staking and generating rewards for rETH.

With the ability to now stake indefinitely on deposits assigned to a node, obtaining a deposit that is assigned to your node with a ‘good’ commission rate is inherently valuable.

Solution

Introduce a free market approach to minipool deposit assignment. This approach has parallels to the current Ethereum model of assigning a gas price to a transaction in order to get it processed quicker and with a predictable timeline from the transaction pool.

When a node operator creates a minipool, they can select the min commission required for ETH assignment to it and a fee in RPL that would see it assigned that 16ETH chunk at that commission rate (or above) over other node operators that are competing for that rate. This allows them to create strategies around deposit assignment with predictable returns. This fee in RPL can be quickly earned back in rewards if they achieve a good commission rate which incentivises them even more. With a fee paid upfront (no dev fee model), the node operators are now earning 100% of the commissions earned in the network for as long as they like helping drive rETHs value.

The RPL given in fees could be utilised in several ways and potentially split between these.

  • They could be given to a ‘DAO Fund’ which can give grants for applications built on top of RP, dev work, upgrades etc. The DAO would be created at a later period after a mainnet launch, there will be another proposal for that later on, so we’ll just stick to the topic at hand for now.
  • They could be given to trusted node operators since they are required to perform extra duties for the network (Oracles, potential withdrawal duties etc).
  • They could be given to anyone running active validators in the network.

We’re also open to the idea of burning a small amount of RPL before distribution occurs to help RPL retain it’s value over time which may benefit another RPIP in the works.

Perceived Benefits

  • Node operators have much more control over commissions and can make strategies to optimise their ROI.
  • Node operators receive 100% of their commissions, no slice of the pie is taken now which makes RP more attractive for stakers and node operators alike.
  • Node operators can deploy minipools ahead of time rather than have to constantly watch the deposit queue and only deploy when commissions reach a level they like.
  • Node operators can compete on an even playing field for high commissions which can be earned back quickly by locking in the commission they targeted and staking on it for as long as they like.
  • Node operators should in theory stake for longer across any commission rate to at least earn the fee back at a minimum.
  • Node operators need not worry about luck of the draw with deposit assignment when the commission rate goes up.
  • We can potentially (still up for debate) remove the min lockup time for nETH. We had to originally add a min lockup time to ensure node operators didn’t just keep making minipools and destroying them quickly for fear that minipool might end up with a reduced commission rate by the time it is assigned ETH.
  • Competition is good! You might get one time stakers who are happy to wait for a big commission to come in that they can stake on for a while OR you might get a SaaS provider who has less overheads and is happy to collect more of the lower commissions quickly in volume.

Perceived Drawbacks

  • More complexity added to the queue system in the smart contracts. Network capacity is now defined by ETH in queue awaiting assignment and the minipool validators capacity with the min commission required.
  • More complexity when depositing, nodes would have to do some off chain calculations (automated) before depositing to allow the smart contracts to add the users deposit in the correct ‘ranking’ among other deposits of the same rate. Smart contracts can’t work this out themselves due to the gas block limit.
  • More friction with RPL fee if you want to lock in good commissions and are happy to pay for it.
  • Fees might dry up in times of slow deposits.

Variables

  • A min fee price? Under the above model, you could make a deposit + set a commission price with 0 RPL, but chances are if it’s even in a remotely good commission range, someone could use any amount of RPL to get priority for it over you. Free market baby.
  • Uniswap integration for those who don’t already hold RPL. We already have this with version 2.0 of RP, but could be included for the above idea too. When creating a minipool and setting its commission price, you just get a total for that deposit back like ‘16.01 ETH’ required where that 0.01 ETH is used to automatically source RPL from Uniswap to cover the deposit RPL you want to pay. Reduces overall friction a lot this way as the user might not even know they’re paying with RPL.

Examples

Now let’s throw some ‘what if’ examples out there to see how this might work under different scenarios. All figures/rates used here are for demo purposes only.

What if…

  1. Queue gets a HUGE deposit and has a LOT of ETH in it, commission rate is high @ 15% (just a random figure, don’t quote me on that) and many node operators have set a min commission of 15%:
  • ETH is assigned to node operators with minipool min commission rates set to 15% and assigned from largest fee to smallest fee paid.
  • After a few assignments, commission rate drops to 14% and is then assigned to node operators with minipool min commission rates set to 14% and so on.
  1. Queue has little ETH in it and commission rate is low @ 5% and all node operators have set a min commission of 10%:
  • ETH is not assigned as there are no available minipools with the required commissions.
  • Queue will continue to grow with deposits until it reaches a node operators desired commission OR a budding node operator deploys minipools with a lower commission target.

TLDR;

A new system that would allow RPL to be used by node operators as a way to source ETH deposits that are waiting assignment at a certain commission range by using free market mechanics. Allows node operators to potentially receive 100% of the commissions in the network and a way to develop strategies for receiving ETH deposits at specific commission levels.

This is just in the ‘this could work, so what do you think stage’ and is far from approved as it still might have some big holes in it. But it’s a good time for discussion on it, so have at it :slight_smile:

1 Like