Oracle Infrastructure

Oracle operations on Liquid Collective report on consensus layer data

Members

The Oracle holds a list of the Oracle Operators' members who are expected to periodically report Consensus Layer data. These addresses can be checked via an off-chain naive search request.

The Oracle contract is configured such that a representative subset of those Operators are required to report the same Consensus Layer (also referred to as Beacon Chain) data before the Oracle contract reports to the River contract.

Quorum Synchronization

The Oracle is set to report Consensus Layer data to the River contract at configurable Consensus Layer epochs. For each reporting epoch, the Oracle contract expects a quorum of Oracle Operators to report the identical Consensus Layer data before reporting to the River contract.

Epochs

The Oracle contract is configurable so data is reported from a starting epoch and then for every epoch at a given interval.

In the current deployment, this interval is configured so consensus layer data is reported approximately every 24 hours.

Quorum

The Oracle contract holds a configurable quorum value that indicates the minimum number of Oracle Operators that must report identical Consensus Layer data before reporting the data to the River contract.

At each reporting epoch, every Oracle Operator is expected to collect Consensus Layer data and report it to the Oracle contract through a transaction. The Oracle contract counts the reported consensus layer balance sum of Liquid Collective validators, the reported count of validators, and the number of similar reports from Oracle Operators, along with the count of report variants.

Any changes to the quorum, such as removing Oracle Operators from the members list, clears all of the reporting data for that epoch. Remaining Oracle Operators that had already submitted reports for that epoch would need to report again for the same epoch.

Once receiving a quorum of identical reports, the Oracle contract publishes the data to the River contract, at which point the River contract can compute and distribute network rewards.

Reports

The Oracle contract aims to report the following data to the River contract:

• Epoch - The epoch for which the Consensus Layer data corresponds to.

• Validators Count – The count of active Liquid Collective validators on the Consensus Layer (either in status active or active_ongoing). This is necessary so River can compute the number of validators in pending status that have been staked to on the Deposit Contract but are not yet active on the Consensus Layer.

• Validators Balance – The total ETH balance of active Liquid Collective validators on the Consensus Layer.

Sanity Checks

The Oracle contract is responsible for performing certain sanity checks on the reported data, providing a layer of security to the protocol in case Oracle Operators behave maliciously.

First, the Oracle contract makes sure that the Oracle Operator's reported transactions are for the correct expected epoch.

Second, it makes sure that the validators' reported balances are coherent. In particular, the Oracle contract:

• Forbids Oracle Operators from reporting earned rewards that would exceed some configurable upper bound of APY. This upper bound takes into account the APY delta between updates extrapolated on a yearly time frame.

• Forbids Oracle Operators from reporting a balance that would have decreased more than some configurable lower bound of fees or penalties. This lower bound is based on the relative balance decrease.

The execution layer fees are taken into account in these sanity checks as they are the product of a Node Operator's work, just like consensus layer fees.

Oracle Data

The Oracle contract receives reports from the Oracle Operators and updates the following data for the River contract:

• Validators Count – The count of active Liquid Collective validators on the Consensus Layer (either in status active or posterior). This count is necessary to compute the count of Liquid Collective validators in pending status that have been funded and deposited to the Deposit Contract but are not yet active on the Consensus Layer.

• Validators Balance – The total ETH balance of active Liquid Validators on the Consensus Layer.

Each time a new report is processed, if Liquid Collective's validators have collectively earned a positive network reward, then this network reward is distributed between parties involved in the Liquid Collective protocol by increasing the Conversion Rate for LsETH.