ETHx Oracle Update | Tech Explainer

About Stader

Stader is a multi-chain, non-custodial liquid staking protocol on six chains, including Polygon, Fantom, BNB, NEAR, Hedera, and Terra 2.0. With over $120 Mn in TVL across chains, Stader is trusted by 70K+ wallets and a community of 150K+ members.

Stader’s mission is to unlock a passive income opportunity for 1Bn+ people through staking and DeFi. We aim to achieve this by simplifying staking & offering the best yield opportunities with our liquid staking solution across multiple blockchains.

ETHx (following Stader’s convention of an x-for-suffix for liquid tokens) is the liquid staking token for staked Ethereum offered by Stader. ETHx aims to provide Stakers with a decentralized and scalable solution with diverse DeFi integrations.

This blog series aims to give the reader a deeper understanding of the inner workings of ETHx, covering the architecture through a series of posts outlined below

1. Node Operator onboarding
2. Deposit workflow
3. Rewards management
4. Oracle updates
5. ETH withdrawals
6. Security

In this specific post, we focus on Oracle Updates. Let’s start with the basics.

What are Oracles?
A blockchain can access information that any entity has recorded on the blockchain. However, much of the data in the real world exists outside the blockchain. For instance, the current temperature in London, UK is neither inherently available nor computable onchain. For such external data to be used on the blockchain, a third-party entity, called an “Oracle,’’ sources the information and feeds it into the blockchain. The information the Oracle provides may not be verifiable onchain but is considered reliable enough to be used by blockchain applications.

Why does ETHx need Oracles?
Ethereum started as a proof-of-work blockchain and, in recent years, transitioned into a proof-of-stake blockchain. At its core, the two blockchains, Execution Layer and Consensus Layer, form the Ethereum network. The execution layer holds the contract data, and the consensus layer holds staking information (regarding validators). ETHx smart contracts make decisions based on the data from the consensus layer. Hence, Oracles are needed to bridge this gap by fetching validator data from the Consensus Layer and supplying it to the Execution Layer.

Are Oracles commonplace in DeFi?
Although contentious, Oracles are widely used across many DeFi protocols, particularly in lending markets, liquid staking protocols, and CDP agreements.

Oracle Committee

Running an Oracle client is computationally intensive, technically challenging, and expensive. Only registered Oracle operators can provide data to ETHx smart contracts. To be an eligible Oracle operator, one must follow the process outlined below.

1. Complete KYC/KYB of the individual or entity
2. Demonstrate proficiency with prior history
3. Provide security collateral determined by Stader DAO
4. Pass a governance vote for approval of Stader DAO

Each Oracle client operator is encouraged to maintain dedicated infrastructure, including an archive node, to protect against common, widespread infrastructure failures (cloud or rpc providers, etc). Oracle operators receive compensation for gas fees and operational costs from Stader treasury. Please reach us here if you want to operate an Oracle node with ETHx in the future.

To make ETHx Oracles sybil attack resistant, we limit the operator addition or removal rate to one per week. This ensures a gradual and consistent transition between Oracle operators as well.

Consensus Mechanisms

ETHx utilizes various consensus mechanisms across Oracle data feeds to determine agreed-upon values from multiple independent Oracle node operators. Some of the consensus methods employed include:

1. Majority consensus
In this consensus mechanism, more than half of the Oracle providers are  expected to report the same value for the same reporting block.

2. Median consensus
For some data feeds, where Oracle operators cannot feasibly report identical values, ETHx uses a two-thirds threshold. Once two-thirds of operators have reported for a block, the data is stored after sorting & median of all reported values becomes the consensus.

3. Deviation Threshold Consensus
Multiple Oracle operators reporting data separately on Ethereum require gas fees for each. Decentralized oracle networks like Chainlink’s compute data off-chain, updating the on-chain contract only when the new value deviates from the previous report by a minimum threshold.
The subsequent upgrades for ETHx contracts will incorporate these efficient consensus mechanisms.

Let us explore the data reported by the Oracle Committee to the ETHx contracts and how the Oracle data is leveraged.

1. Exchange rate
   The exchange rate of ETHx to ETH determines the conversion when users stake ETH to mint ETHx or burn ETHx to withdraw ETH.
   
   Computing the exchange rate requires the following three conditions:
   a. Amount of ETHx tokens in circulation
   b. Amount of ETH tokens that are staked or in the process of being staked.
   c. Ensuring that the above two conditions are reported for the same block number.
   
   The exchange rate of ETHx to ETH is defined as the total ETHx supply divided by the total ETH that is staked + in the process of being staked at any point. Stader Oracle contract sets the frequency of updating the exchange rate data. The Oracle client operators report the exchange rate through the majority consensus mechanism for appropriate blocks. Between Oracle consensus updates, the exchange rate is constant and assumed to be non-changing.
   
   An exchange rate update that meets the consensus threshold is accepted if it’s within a specific range of the old exchange rate. Inspection mode is enabled when the new exchange rate deviates significantly from the old one. In inspection mode, the Stader manager is expected to verify the validity of the new exchange rate. Anyone can also turn off the inspection mode after the verification period for the inspection mode ends. The latter ensures that anyone can continue exchange rate updates except during short bursts for verification purposes.
   
   Stader has partnered with Chainlink to provide Proof of Reserve data feeds for both ETHx and ETH supply to act as an alternative to the above. In the subsequent protocol upgrades, we expect to integrate and transition to Chainlink’s Decentralized Oracle Network (DON).
   
2. Withdrawn validators
   Once a validator’s exit message is broadcasted, the validator joins the exit queue, slowly making their way across the withdraw queue. Eventually, the validator’s entire staked balance accumulates in the validator withdrawal vault contract deployed during their onboarding.
   
   The ETH in the withdrawal vault is a mixture of:
   a. The validator’s original ETH collateral
   b. User ETH lent to the validator by Stader
   c. Consensus rewards and commissions earned by the validator
   d. Any applicable slashing penalties that are due for deduction
   
   On a validator exit, it becomes essential to promptly distribute the above ETH to various stakeholders. Furthermore, this helps facilitate quicker withdrawal requests for Stakers and Node Operators.
   Stader Oracle client operators read all validators registered with ETHx smart contracts and list all validators exited from the beacon chain. This list is submitted and arrived at a consensus, after which the distribution, as mentioned earlier, happens. The exited validators are also marked as exited on the smart contracts.
   
3. Missed attestations
   Node Operators are offered flexibility on Ethereum staking, as missing a few attestations leads to a minor penalty. When Node Operators are offline for an extended time, they do not generate rewards on the consensus or execution layer. ETHx contracts prioritize Staker rewards over Node Operator security collateral to avoid these situations. In extenuating circumstances, Oracle client operators can vote to penalize validators proportional to their historical cumulative count of missed attestations.
   A governance vote will decide the final parameters for the historical count of missed attestations at which a specified penalty needs to be applied. Stader will open a discussion around recommended values to gather community feedback before a vote.
   
4. Validator statistics
   Exit time for a validator on the Beacon chain is non-deterministic as it depends on the network state, the number of validators in the exit queue, etc.
   
   The computation entity must be aware of the following to compute the number of validators that need to be exited to meet the demand of withdrawal requests:
   a. ETH balances of slashed validators
   b. ETH balance of validators in the exit queue
   c. ETH balance of validators withdrawn since the last Oracle report
   
   Oracle client operators are expected to report this data infrequently for the exit validator list to be computed to initiate validator exits on time. The Stader DAO will decide the validator selection mechanism for exits and its enforcement through a governance vote.
   
5. Operator reward merkle root
   The permissionless pool allows operators to participate in the socializing reward contract for execution layer rewards. On the other hand, for the permissioned pool, all operators are expected to participate in the socializing reward contract.
   
   In every reward cycle, the ETH reward in both these socializing contracts is distributed to operators participating in the pools based on the following factors:
   a. The number of validators run by the node operator
   b. The number of attestations performed by each validator in the reward cycle.
   
   SD token rewards are also distributed to the same set of node operators based on the following factors:
   c. The number of validators run by the node operator
   d. The number of attestations performed by each validator in the reward cycle.
   e. Amount of SD token bonded on average per validator per day.
   
   Oracle client providers must provide the computed Merkle root hash to contracts to initiate ETH and SD reward withdrawal by node operators for past reward cycles. Node Operators are neither rewarded SD for collateralization ratio below the minimum threshold (0.4 ETH worth of SD per active validator) nor are extra rewarded for collateralization above the maximum threshold (8 ETH worth of SD tokens per validator).
   
6. SD price
   Every permissionless node operator provides SD tokens as a secondary security collateral to run an ETH validator. Hence, it is crucial to get an accurate value of SD price to ETH at all times. Oracle client operators must update the ETHx contracts with SD price periodically. A time-weighted average price (TWAP) of 24 hours is mandated to avoid SD price manipulation concerns.
   
   Given the diversity of data sources, onchain and offchain, a consensus by the majority is an impractical choice. For this Oracle feed, the SD price is considered the median value after two-thirds of Oracle client operators have reported the SD price. As with other Oracles, the SD price remains constant between consecutive price updates.
   
7. MEV misappropriation
   Node Operators can choose the execution layer reward fee recipient on every block. If a Node Operator were to guide the execution layer rewards (MEV and Priority fees) away from the ETHx contracts, Stakers would lose the yield that is appropriately owed to them. MEV misappropriation allows Node Operators to unfairly pocket all the rewards instead of just the commissions.
   
   A node operator could commit this infraction in one or more ways:
   a. Changing execution layer reward fee-recipient shortly before block proposal
   b. Choose a block order that profits a specific transaction to a third party with which the node operator may have an offchain association. This leads to a suboptimal extracted reward value for ETHx’s Stakers.
   c. Not operating an MEV relay.
   
   Recognizing MEV misappropriation is a reactive process that limits actions that can be taken to remedy the situation. With ETHx, every permissionless node operator provides 4 ETH security collateral and 0.4 ETH (or more) worth of SD tokens per validator. Effectively, 4.4 ETH is available for compensation as a counter to MEV misappropriation. Any penalty exceeding 4 ETH is offset by a flat 0.4 ETH of SD Auction. In future improvements, an accurate estimate of SD will be put up for auction with Node Operators capable of paying back penalty amount (in ETH) too.
   
   Stader is partnering with Rated Network to track Node Operators’ performance and inform of any instances of MEV misappropriation. For more details, read here.

This post covered how Oracle client operators relay essential information from the Beacon chain onto the execution chain. In subsequent posts, we will cover the other ETHx token withdrawals and security measures for our ETHx product.

For any questions you may have, please reach out to us here.

Join 17,000+ ETHx early birds now! Get launch alpha and early access to $1M in SD rewards.