The Crypto Pricing Oracles 3.0

In the crypto world oracles are fundamental to every web 3.0 dApp. Previously, we’ve covered general oracles, explored how these data streams will expand the opportunities available on the blockchain and explained some of the use-cases.

With crypto pricing oracles the story is a bit different. Almost everything on the blockchain uses a crypto pricing oracle. Pricing of various crypto assets is just a fetch-and-set action where the oracle provider fetches the data from point C through it’s nodes (for validation) and updates the smart contract (oracle) or more accurately it’s state (value) on the blockchain. The data point C which can be the price of Bitcoin is fed from various sources. It is converted from different currencies (markets) such as: BTC/Japanese Yen, BTC/British Pound, BTC/Russian Ruble, BTC/Euro and then converted to a single currency which is almost by default — USD. This converted price already carries two issues:

• Foreign exchange rate differentiation
• Foreign exchange update time — the average dApp user doesn’t know when the BTC/Japanese Yen market pricing has been updated nor is aware of how many seconds it takes for the data to become too stale
• Which sources were used to fetch these market pricing updates

At this point, the converted pricing still needs to be averaged out by VWAP (volume weighted average pricing) or some obscure algorithm known to a very few number of people/entities who control the data point C. This creates a massive, multi-billion-dollar unethical practice of front-running available to a few selected individuals/entities. From a financial security perspective, many crypto users just aren’t aware of this and unfortunately it’s legal in many cases even on traditional financial markets. We’ve seen this exploited through some bots recently open sourced on github.
The next step is to update the smart contract state. By the time this happens the crypto pricing data from point C is already xx seconds old. It can be faster but then it’s more expensive for everyone — in every case the cost is completely shoved to the end-user.

ORAO crypto pricing oracles take a different approach. Customers can specify which of the 37,000 markets are relevant, which of the more than 200 sources should be taken into account, they can specify the slippage and staleness, update latency and their oracle will be created, maintained and fed with data by ORAO.

For the end user of our Customers’ dApp the differences in flexibility and customization is key. Customers can acquire the pricing data which is customized and curated for their users. The decentralized apps smart contract fetches the fresh and ready to use pricing data from ORAO crypto pricing oracle. This data is used for execution of the smart contract and to settle the transaction. This is the most accurate way to use crypto pricing data, it provides minimal price differences. Especially when market conversion differences explained in the first paragraph are taken into account. A few cents here, a dollar there, multiplied over thousands transactions, it really adds damage to your wallet quickly.

This is why ORAO is different. By using customizable oracles we can overcome this problem that nobody is paying attention to, whether it’s intentional or just clueless.

Geographically speaking, somebody in the UK who on-ramps and off-ramps crypto doesn’t really want the Bitcoin Price in British Pounds which was derived from various markets and then from various sources. This Customer requires 1 market — BTC/GBP by default and sources which trade in the UK. For example — an OTC desk, a crypto desk at a mall like the ones in Croatia who use Bitstamp and Kraken.

The customization doesn’t stop there. Slippage / Pricing tolerances need to be adjusted even for a few crypto exchanges and fetch-latency needs to be adjusted as well. Perhaps a market on either one of this did not update the pricing as the order books haven’t moved that second.

As the last step before getting the oracle setup on ORAO end the Customer can select the delivery blockchain.

In the next article we’ll explain how we deal with the flash crash, a black swan event or a fat finger on the orderbooks.

Also check out our newest article about Russian Ruble and Oracles.
Follow us on Twitter.