Theory of Operation

Different oracles may submit different 
data.  How do we get a representative 
value for the next random block?

Data streams on a decentralized blockchain are inherently difficult

Setting aside the obvious issue of trust, providing accurate streaming data to the blockchain can be costly both in terms of transaction costs and in terms of computing and storage resources.  In addition, blocks may be relatively infrequent and they represent an interval of time rather than an instantaneous snapshot, meaning that there may not always be a singular data value for a given block.  In some cases, network issues such as latency or blockchain forks may cause disparities.  In a decentralized system, different oracles may submit differing opinions on the correct value at any given instant. On top of all that blocks always arrive at random time intervals...

The concept of a data stream on a blockchain is “fuzzy” by its very nature.

Data quotes on a Microtick data feed account for these challenges by allowing oracles to place a data quote accompanied with an “accuracy window” within which the oracle expects the data to stay over a corresponding time duration. Rather than update the blockchain with every incremental change (or tick) in data, the oracle can now choose the best median representation and specify a window of time and value the quote is expected to stay within.  Quotes can still be updated as the real-world data moves away from the quoted median value, but these updates can now happen less frequently.  This saves both gas and blockchain resources.

Every data quote submitted to the feed is backed by its oracle with an amount of Ether.  This backing is an escrowed amount of value attached to the quote used to assure other market participants that the data is believed to be accurate.  It’s a measure of confidence in the data.

In addition, each quote can be either a bid or an ask depending on whether the data is expected to stay within the accuracy window or not.  A "bid window" specifies a data range that the oracle expects the data is likely to exceed over the time duration of the quote.  An "ask window" specifies a range within which the data is expected to stay within over the time duration of the quote.  This bid / ask window spread provides the basis for a marketplace on the data quotes submitted to the data feed (more on how this works later).

All data quotes (both bids and asks) from different oracles are averaged using a weighted average technique for every block, creating one single consensus value per data block. This consensus average value changing over time becomes the basis for a data stream.

The resultant data stream is available for free to any smart contract in the Cosmos ecosphere, anytime, on demand.

The pricing methodology for Microtick trades is based on well-known financial option pricing models.  The accuracy window and time duration for a quote can be used to calculate an expected volatility for the underlying data.  This volatility estimate can be used to calculate the fair value for an option with a strike at the block consensus value.

In the diagram below, the original quote had an accuracy window of +/- 0.8 @10.  This translates to a volatility estimate of about 0.2 and from that we can obtain a fair call price at any spot value, as shown by the curved blue line.  If the market consensus was @9, the quote would be valued (as a call) at approximately 1.4, while @11 the quote would be valued less than 0.5 as a call.

The act of placing a trade transforms the quote into a call or a put, at the trader's choice. Because the data provider has no control of which direction of trade they might end up on (call or put), their motivation is to be as accurate as possible and profit instead from commissions over time.

NOTE: The strike price for the trade is always at the feed's consensus value. The option expiration is the current block + the quote duration. Time is always measured in blocks and time doesn't start counting down on the quote until the trade occurs.