Oracle Operators

Why oracle?

As of today, the state of the consensus layer is not available on chain. This needs to be monitored using the beacon node api. The MEV boost ecosystem is also off chain and fee recipient changes can be monitored through the relay registration api. For this reason, an oracle is needed to push that information to the smart contract. For now, this is the way. There are improvements coming which may allow us to eliminate the oracle network. For more information, see EIP4788 and this proposal put forth by Alex Stokes.

Oracle operators

We’re excited to announce our Oracle Operators, a coalition of trusted community members and entities (and Kody and Noah):

• Anthony Sassano, Founder of The Daily Gwei

• EthStaker

• Cryptomanufaktur.io

• Aestus Relay

• Kody Sale (Founder of Smoothly)

• Noah Figueras (Co-founder of Smoothly)

Nitty gritty

The operator node is a cli program that works as an oracle which monitors the beacon chain state, validator registration api, as well as interactions with the smart contract: withdrawals, exits, registrations.

This node computes and saves the state using a Merkle Patricia Trie implementation with levelDB on disk. This implementation allows us to track all of the previous states since deployment and share the state with the smoothly pool contract in order to enable withdrawals and exits through merkle proofs.

Anyone can run this node to verify that the state is updating correctly in real time. However, in order to propose a rebalance vote with the new state for the pool you must be an approved operator.

Approved Operators listed above are whitelisted in our poolGovernance contract and propose a vote on rebalance with the computed root hash of the new state. The poolGovernance contract then makes sure that all approved operators reach a consensus of at least 66% before updating the state of the pool contract.

To make this sustainable for operators, they will share a 1.5% fee of the total rewards of that rebalance. This is intended to cover gas and server costs associated with running the oracle, not to enrich the operators.

Rewards Cycle ("rebalancing")

Because of ethereum gas costs, we only update the state of the contract once every period of time. This happens every 21 days on Mainnet. During this state update, rewards are distributed for claiming, validators status is updated, exits are processed, and penalties are issued.

Monitoring the beacon node

In order monitor validators proposals, we listen to the beacon node using the HTTP API for new finalized epochs. Next, we query all of the slots on the epoch and look for validators that missed a slot, exit the beacon chain voluntarily or propose a slot with the wrong feeRecipient, and act accordingly.

Smoothly Pool event listeners

The node is subscribed to a series of event listeners in the pool contract as a way to store all user interactions on chain and retrieve them to update the state of all validators.

State

State is stored on disk, using levelDB which stores all of the data of the Merkle Patricia Trie. Data is stored as key-value mapping being:

key: validator index

value:

export interface Validator {
  index: number,
  eth1: string,
  rewards: BigNumber,
  slashMiss: number,
  slashFee: number
  stake: BigNumber,
  firstBlockProposed: boolean,
  firstMissedSlot: boolean,
  exitRequested: boolean,
  active: boolean,
  deactivated: boolean
}

Website Sessions and Transaction Finalization:

We would like to bring to your attention some crucial information about how our website manages sessions in relation to the monitoring of finalized epochs on the Beacon Node API:

1. Session-Based Updates: Our dashboard updates are tied to individual user sessions. This means that any transaction you initiate will be reflected on the dashboard during your current active session.

2. Finalization Time: Your transaction is generally included within 1-2 blocks after submission, but, since our oracle operators listen to finalized epochs, they wont pick up the tx for approximately 12 minutes.

3. Reconnecting Sessions: If you disconnect your wallet (thereby ending your session) and then log back in, you might not immediately see the transaction you previously submitted. This is normal and is due to the time required for epoch finalization.

4. Avoiding Duplicate Transactions: To prevent any potential loss of funds, please refrain from submitting another transaction for the same action if you have already done so in a previous session. Duplicate transactions might lead to unintended consequences, including the loss of funds.

5. Checking Transaction Status: If you are unsure whether a transaction was successful, we recommend waiting for at least 15 minutes before re-attempting any action. Alternatively, you can check the transaction status on a block explorer using your transaction ID.