Protocol Design
Last updated
Last updated
The point of input for outside data into the protocol is the feed provider. A JSON API's URL can be used to specify a feed source. One Oracle request might include the aggregated data from many feed sources. As long as they offer a JSON API that the general public may use, feed providers don't need to be familiar with the Metaoracle protocol. Feed providers can place a proprietary piece of middleware in front of their JSON API if they wish to charge a fee for supplying data on Metaoracle. This middleware confirms that the API provider has received payment for the use of the API's data.
Consumers use events to communicate with the protocol. Each event is generated by sending a blockchain request of the corresponding event type to the main Metaoracle contract. Events trigger various actions within the node runner and update the protocol state.
Request: Request events are used to trigger single non-recurring blocks, for example to get the outcome of a one-time event, or to execute a computation.
Subscription: Subscription events are used to register recurring requests, they are a superset of request events and contain additional parameters to specify when a new request is generated as part of the subscription.
With several important exceptions, nodes operate in a manner similar to Algorand participation nodes as the network's skeleton. Peer-to-peer Metaoracle nodes use a customised gossip protocol to spread information throughout the network. It is expected that node clients being used by node runners are compliant with the protocol standard. Nodes are in charge of monitoring blockchain-based Metaoracle events, reacting to them by starting new blocks if necessary, and keeping the protocol's state.
