The Oracle Money on Chain (oMoC) protocol queries price pairs data from crypto exchanges and sends them into a smart contract on the blockchain. This way, the reported prices becomes available for other smart contracts. Normally, Oracles are centralized services causing the risks of any centralized architecture, i.e. being prone to single point of failure and to malicious behaviour. The Money on Chain (MOC) approach circumvents these problems through a decentralized price calculation by opening the possibility to any player to run an Oracle and participate in a consensus protocol for price feed publication.
The entire architecture is composed of three components:
Centralized Oracle services involve the risk to be prone to system faults and malicious agents. The Oracle system is an essential part of the Money on Chain platform, and hence must have a very robust architecture. Therefore, the Oracle system contemplates the following aspects:
Rounds & Scheduler
The system works in periods of one month (n blocks), called rounds. During these rounds the surplus of the MOC system for the Supporter reward gets accumulated. The implementation of this concept is a tool called scheduler, which starts a new round and sets the reward counter to zero at the beginning of a new round.
The incentive to hold MOCs locked is either for the reason to become an Oracle, to participate in the Governance module, or, simply, in order to receive a percentage of the income from the MOC system as a reward in return. The MOC system generates a surplus from the system fees and from selling data provided by the Oracles to other third parties. This income stream is accumulated in one round and part (a certain percentage of the entire surplus) of it is used to pay rewards to Supporters.
Reward Distribution: MOC holders receive rewards in proportion to the time and their amount of locked MOCs in the current round the corresponding percentage of the system’s income of the previous month.
Oracles report the current RBTC/USD and RIF/BTC price taken from various cryptocurrency exchanges, whereby the same infrastructure can be easily extended to other price pairs. Everyone can become an Oracle if the user has locked enough of MOCs (there is a minimum amount), and receives, as the Supporters, a revenue for their locked MOCs. In addition to this, they also get a reward for publishing price pairs. This compensates their expenses for running an Oracle and pays an additional income.
Oracles must register as such by publishing their public address on the RSK network. Moreover, in order to be considered as an Oracle, the user must lock a minimum amount of stake. Oracles also must subscribe for each coin pair, e.g. RBTC/USD or RIF/BTC, separately to be considered in the selection for the next publishing round of these price pairs. Oracles who want to withdraw their locked stake, must first be inactive for one round by unsubscribing from all coin pairs. Once successfully unsubscribed, the same withdrawal rules as for Supporters apply to them.
Rounds & Scheduler
The Oracle system works in 30 day periods -- also called rounds -- in which the accounting for the Oracle rewards are determined. It requires an external agent, called scheduler, to effectively switch these rounds, whereby each coin pair has its own scheduler which works independently of the other coin pair price modules, and which are neither synchronized with the Supporter round. When the scheduler is run for the previous round, it sets the global reward counter to zero, and from that point onwards the produced rewards are going to be used for the current round. Moreover, each round accounts for the locked stake and the activities in the current month, i.e. in each round, the following data are saved: locked stake, the list of participating oracles, and rewards won.
Rounds can be in three different states, namely Pending, when Oracles can add more stake, Current, when Oracles publish the coin pair prices, and Finished, when the scheduler closes the round and the rewards are transferred to all participating Oracles. The following table summarizes the different states and the actions which may take place:
Consensus for Published Price Feed
Oracles have to find consensus about the correct price feeds, i.e. the RBTC/USD or RIF/USD price pairs. This is achieved by an offchain consensus in which the ten (or more generally N) Oracles participate, which have locked the most stake during the pending state of that round. Oracles’ stake count for all price pairs, but Oracles must subscribe for each price pair in order to participate in the next round. Then, during “current” state of the round, proposer election and consensus works as follows:
For each publication, only one Oracle can succeed: Only one transaction is accepted by the blockchain. After a successful publication, the block hash for the last publication changes and a new consensus is started. The Oracle system does have further important properties reflected: