Rocket Pool — Staking Protocol Part 2
By: David Rugendyke
Tags: Ethereum, Staking, Proof Of Stake, Rocketpool, Blockchain

Oracle DAO Duties

Ethereum in its current state is operating with two separate chains, the ETH1 mainnet chain that everyone knows and loves, plus the relative newcomer, the ETH2 beacon chain where validators spend their time earning rewards for people who have deposited into the ETH1 deposit contract.

These two chains aren’t connected (yet) and they might never be in a way that would allow a smart contract on ETH1 to know about the state of any validator on the ETH2 chain — such as if that validator had been staking well earning rewards or performing badly by being offline regularly.

So how does a decentralised staking protocol for ETH2 based on ETH1, handle such a task when these two chains are separate?

This is where the Oracle DAO comes in. It helps bridge this gap and helps provide valuable oracle services + network liveliness for the protocol and all its users, both stakers and node operators alike.

Being a member of this DAO means you’re operating as a group. Any data reported back for any of these duties requires majority consensus. So if data reported to the protocol is not agreed upon by more than 50% of the members, it is not accepted. This helps prevent malicious behavior, nodes that go offline and helps to ensure the integrity of the reported data.

1) Oracle Tasks

There are two main oracle duties required by the Oracle DAO members, both of which are integral to the protocol. These are:

Minipool Validator Balances — Each validator in the protocol is referred to as a Minipool. It contains 16ETH from the node operator and 16ETH from the deposit pool. The performance of these validators needs to be monitored so the protocol can calculate the performance of all the validators in the decentralised network and allow users holding rETH to exchange it for ETH + rewards at the correct exchange rate.

— Each validator in the protocol is referred to as a Minipool. It contains 16ETH from the node operator and 16ETH from the deposit pool. The performance of these validators needs to be monitored so the protocol can calculate the performance of all the validators in the decentralised network and allow users holding rETH to exchange it for ETH + rewards at the correct exchange rate. RPL:ETH Ratio — When depositing 16ETH as a node operator, you are required to deposit a minimum 10% of that ETH’s value in RPL as an insurance promise to the protocol. The more RPL you provide as insurance, the more RPL rewards you earn. To make sure this amount of RPL is correct, the current RPL:ETH ratio must be reported and agreed upon by > 50% Oracle DAO members.

2) Service Tasks

Oracle DAO members also must also perform daily services for the protocol. These include:

Minipool Validator — Mark validators as exited/withdrawn when they perform these actions on the beacon chain.

— Mark validators as exited/withdrawn when they perform these actions on the beacon chain. Protocol Liveliness — Make sure the protocol is always lively and staking as much ETH from the deposit pool as it can to help generate rewards value for rETH holders. Oracle DAO members can create unbonded minipool validators that don’t require 16 ETH to be matched by themselves.

Importantly, to maintain decentralisation in the above scenario, unbonded validators are only ever selected for ETH assignment from the deposit pool if there are no bonded node operators available, as they always have priority. There is also a cap on the amount that members can make and that can be changed should > 50% of members agree to change it.