Mapping The Oracle Decentralization Layer

Oracles are a significant piece in the link for blockchains to access real-world data, but several other components are required as well. What other parties are involved in getting off-chain data, on-chain, through an oracle?

Oracles are a system with multiple levels. Bridging the gap between off-chain data and on-chain data requests requires entities at different layers to “communicate” effectively. Like any system, decentralized or centralized, oracles require someone to build that system. Goracle will be the team to build a decentralized oracle system on Algorand, organize the critical infrastructure, set up data standards, create incentive mechanisms, and more.

Take the example of a perpetual DEX. For a perpetual DEX to operate, it must use a price feed from an oracle, such as Goracle’s Price-Pair feed. The DEX relies on a price from an oracle for trade execution rather than having its price discovery mechanism. The DEX will pull its price from an oracle, but where does an oracle pull its price?

Data flows through several layers in an oracle system. Raw data sources, data aggregators, node operators, and lastly, consumers. Each one of these is crucial to the oracle system and its security. Let’s dive into each layer so you as the end user can have a more holistic understanding of how data is funnelled to your favourite protocols!

Data Sources

Data comes from a specific data source. For a weather feed, it could be various weather stations. For a sports results, it could be different referees or even commentators. For a price feed, it would be multiple centralized and decentralized exchanges.

The data sources must be reliable to build an accurate price feed. That means the centralized or decentralized exchange needs to have efficient price discovery. If efficient, their price reflects the “true price”. The accurate price is a function of liquidity and volume, meaning that prominent exchanges such as Binance/Coinbase/Kraken for CEXs and Uniswap/Curve for DEXs are the most reputable. These exchanges would provide raw market data to data aggregators for processing. But what if a specific data source has incorrect data due to a bug? That’s where Data aggregators come in.

Data Aggregators

Data aggregators collect the raw market data and then process them to build refined datasets. Raw market data could originate with institutions such as AmberData and Kaiko or retail data providers such as CoinGecko and CoinMarketCap. You can read a bit more about institutional vs. retail data aggregators here.

At this point, you may be thinking, why can’t they send the data from the source straight to the node operators? Why do data aggregators need to process it? Even though oracle systems only choose data from reliable data sources, an accurate data feed would give increased weighting to more reputable data sources. For example, Binance has the most volume out of all centralized exchanges, so their data should be more critical (given a higher weighting) when constructing the data feed. A method called volume-weighted average price (VWAP) achieves this by pulling prices from several data sources, which are averaged together but weighted proportionally based on the pair volume.

In addition to calculating a VWAP, a data aggregator has to account for other price considerations, such as the spreads (the difference in price in which you can buy and sell an asset), as oracle data requesters only want to receive one price point per asset. In addition, data aggregators have to spot anomalies such as flash crashes (when the price of an asset rapidly drops due to low liquidity) or wash trading (when the same entity trades between themselves to increase the volume, which would artificially increase their weighting in a VWAP). A data aggregator makes their refined price dataset available through an application programming interface (API), often at a small price.

Node Operators

Node operators connect with the APIs of several data aggregators. Every time an oracle needs to update its price, node operators will call the APIs, and a random node will propose what they think the accurate price is. A node operator could calculate the precise price in a few ways, but most often, they would take the median value from all APIs to remove potential outliers. The node network will then vote on whether they think the proposed price is accurate.

Consumers

Lastly, there are consumers, which are individuals or protocols, that need real-world data to integrate into their smart contracts. Consumers pull price feeds by calling an oracle smart contract with details of what they want the contract to perform, e.g. pull the price of ETH/USDC right now. Their request will also have a callback function to which the oracle sends the response to. Oracle node operators own these oracle contracts.

That is it! As you can see, it takes many steps to get accurate pricing data securely into your favourite protocol on-chain. It is more complex than a data source sending raw data and an oracle spitting it out on the other end.

Each layer needs to have strict mechanisms in place to ensure data reliability. Building out a reliable oracle system is more challenging than you think, from choosing the correct data sources, verifying data aggregator processes, and ensuring node operators have the experience and infrastructure. Goracle will ensure that our oracle system is built to the highest quality and reliability.

If you are interested in what Goracle’s approach is to each oracle layer, check out our documentation.

For more information about Goracle, visit our Linktree.