How it works
A page dedicated to describing the the key components of the ROPU
Last updated
A page dedicated to describing the the key components of the ROPU
Last updated
The Rated Oracle has two distinct parts; (a) the “proposer” and (b) a smart contract suite. The proposer is an off-chain daemon responsible for bringing data on-chain, while the smart contract is responsible for the following three things: (i) holding the data brought by the proposer in escrow while they remain in an unfinalized state, (ii) creating claims on the UMA optimistic oracle, and (iii) being able to return the finalised data to the user via getters.
For the first production version of the ROPU to hit the Ethereum Mainnet, 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 pushing bad data on-chain.
Each time new data is brought to the Rated smart contract via the proposer, a new claim is made on the Optimistic Oracle. The newly submitted data will be held in escrow until the associated claim is finalised. This means that the data is held securely and can only be accessed when the optimistic oracle certifies that the reported data is accurate.
The parameters of the claim, including the length of the dispute window and the bond size, can be adjusted at will.
The core mechanism of the Smart Contract is designed to hold in escrow the data reported by the proposer and create a claim on the Optimistic Oracle upon receiving a new report.
On top of this core mechanism are the user facing functions. The user-facing functions consist of getters, which retrieve finalised reports, and requests, which enable users to trigger new reports of data from the proposer. Requests functions are not always necessary, particularly for recurrent data reports.
The design allows us the flexibility to customise the user facing part of the contract to best serve downstream integrators' data needs on chain. Get in touch via hello@rated.network or ping @GAstieres on Telegram to discuss your needs.
The Rated Oracle has been developed to fulfil two distinct use cases in terms of time frequency; (a) predetermined time cadence and scope reporting (e.g. every 24h) and (b) ad-hoc requests for arbitrary complexity queries–meaning that the data report can be triggered by the user on the Rated smart contract or by a specific on-chain event based when specific requirements are met or simply when the user elects to.
