The Rated Oracle powered by UMA (ROPU), is a fault tolerant mechanism that allows high fidelity data transfers from the Beacon Chain to the Ethereum Execution Layer.
The ROPU is meant to serve EVM application builders that want to reference composite Beacon Chain data (such as operator performance and its derivatives) in their applications. At the moment we think that (i) liquid staking pools (e.g. Stakewise vaults) and (ii) insurance applications (e.g. Nexus Mutual), can benefit the most from the ROPU’s utility.
At a high enough level, the ROPU brings all the flexibility of the Rated API, on-chain, in a secure and fault tolerant way, with very high probabilistic guarantees on data integrity and fidelity.
Here’s a simple request flow: the user asks for aggregate data for a set of validators (e.g. a list of pubkeys, a deposit address), for a given time window (e.g. last 30 days, all-time etc). For example, a user could ask for the aggregated statistics of Chorus One (operator) validators under Lido (pool) for the last 7 days.
The array of data that could be returned, on-chain, include:
The oracle the fetches the data from the Rated API and serves it to the Ethereum Mainnet Execution Layer.
<aside> 💡 In reality the possible set of data exposed could be as wide as anything that is exposed on the rated.network front-end, and then wider. It all depends on the user’s preference
</aside>
The Rated Oracle is leveraging the UMA Optimistic Oracle mechanism to make the data transfer secure and fault-tolerant. At a very high level, the Optimistic Oracle is a mechanism that allows for (i) a dispute window to be effected as the data comes on-chain, (ii) a bond that proxies the level of security and data integrity required of the data producer/proposer, and (iii) a dispute resolution mechanism when inquests to the integrity of the data are raised.
Rated Labs acts as the sole proposer of the data—i.e. the agent responsible for bringing the data requested to the Execution Layer. Once an array of data is requested, together with fetching the array, the proposer posts a bond that stands to get “slashed” should a successful dispute be raised. If the disputer is proven to be right, then the slashed bond is distributed to the disputer, the voters that arbitrate the outcome of the dispute, and the original requester of the data. That way, not only is Rated incentivised to always push correct data on-chain, but also if bad data is pushed and proven so, then there is an insurance-like kickback due for the data requester, to compensate for the consequences of the poor data push.