Smart Contract Oracles and Price Feed Centralization

The critical vulnerability DeFi projects face today

Published in

Band Protocol

6 min readJul 1, 2019

In light of the recent Synthetix Oracle Incident, we took the opportunity to take a closer look at the potential issues with the oracles that many of the existing DeFi applications responsible for over half a billion locked collateral rely on today.

What is an oracle and why are they important?

Blockchains inherently do not have anyway to access data from outside its own system and network. An oracle is a technology that interfaces external data sources and APIs into compatible form to be used within a blockchain. It acts as a digital agent that finds and verifies real-world data and submits this information in a cryptographically secure way for a smart contract to utilize. This allows smart contracts to define state changes and trigger events on a blockchain based on outside external events and interact with the outside world.

For many applications built on blockchains, interaction with the outside world and responses to external data points are crucial for operation. For example weather, lottery results, real world news events, IOT data and essentially any interaction with web APIs will need oracles for the application to effectively use the data.

In the context of the most successful decentralized applications to date in decentralized finance, exchange rate price feeds are particularly important, such as the feeds for the management of collateralized debt positions in MakerDAO that ensure liquidations and effective risk management needed for Dai to maintain its 1:1 USD peg.

The problem with oracles

The problem with oracles is that they create centralized points of trust into systems that are meant to be trustless and decentralized. Since an oracle controls the input data into a smart contract, it therefore controls the operation of the smart contract as it responds to the input data. This presents a significant vulnerability and central point of failure, as a compromised oracle essentially means the entire smart contract is compromised, eliminating the majority of the decentralization and its benefits in an application.

It is for this reason that applications using oracles typically must build in redundancy within their design to accommodate multiple oracles for the one data point, build methodologies for handling multiple data sources and reconciling data when there is conflicting information (such as an Oracle being manipulated maliciously).

The impacts of a vulnerable oracle system can be quite severe, especially with DeFi applications that manage significant amounts of staked and lent capital, and often exchanging with significant volumes. One unfortunate recent security incident involving the use of oracles in DeFi was the Synthetix oracle incident which you can read about in more detail here.

To summarise briefly, Synthetix is a multi-tier issuance platform and exchange that permits any user to mint synthetic crypto assets such as cryptocurrencies, fiat currencies to derivatives using cryptocurrency as collateral. These synthetic assets replicate the price of their real counterparts and rely on price feed oracles to constantly update the exchange rate. (The Block’s summary of how the Synthetix protocol operates can be found here)

In this particular case, the API for a fiat currency pair was offline meaning that only two oracles were providing data, with one of these feeds providing incorrect pricing data, arbitrage trading bots quickly traded huge volumes acquiring large amounts of synthetic ETH.

Improving upon existing oracle solutions

While the Synthetix issue was resolved and additional measures are being implemented to prevent a future occurrence, it serves as a reminder of the potential susceptibilities that applications using oracles face in their use and areas of their design that have room for improvement. Some important points that this incident raises are:

The importance of redundancy

Since oracles are a central point of failure, as demonstrated by the Synthetix incident, it is clear that multiple oracles are needed to be used for the one data source. API data sources often can go offline, produce incorrect values or be manipulated (e.g. price feed from low liquidity trading pair).

For Synthetix, it is evident that three separate oracles per data feed probably isn’t enough. Conversely Maker utilizes a set of 14 oracles for its price feeds, but this produces more overhead, design complexity and expenses that could impact the performance of an application. It is also important to note that the majority of these oracles use the same scripts, meaning that the oracles are not completely independent. If the oracle script has a critical bug, it’s possible that all of the oracles could fail together.

Solutions which reduce the complexity and cost of implementing and utilizing multiple oracles will allow decentralized applications to be built with greater redundancy. Both ChainLink and Band Protocol incentivise participants through various direct rewards systems to create more available oracle options that are competitively priced and simple to implement into existing smart contracts. As a result it will be more economical and practical to increase redundancy of oracles in applications and therefore increase their robustness, particularly compared to other solutions that don’t require the participant to have anything directly.

How do we manage and govern the use of oracles in decentralized systems?

Since oracles rely on external parties to a decentralized application, there must be some kind of governance process for deciding upon how oracles are incorporated into a design, where those data sources are from and who manages those data sources.

For Synthetix, the team controls the implementation as this is the most practical solution at a smaller scale, especially in early stages of development of the protocol as changes can be made more swiftly. However this means that the system is centralized around the team, providing the community relying on the data feed with little control over how it behaves. (The team recognises this and is moving to a more decentralized model)

Conversely for MakerDAO, there is an intricate governance system, requiring community voting and participation to make changes to the oracle implementation which can be a slow and cumbersome process, prone to low participation rates and incentives that are often indirect.

Within Band Protocol we have developed a framework for oracles — Token Curated DataSources (TCDs) which serve as a robust data feed from a network of data providers governed and incentivised by dataset token holders as participants in each particular data feeds dedicated token curated registry — which prices these tokens directly according to the quality of data. Band TCDs can either be incorporated as another oracle into existing oracle structures or used entirely as a dedicated solution. Either way, it will provide a more transparent and simple alternative for oracles to be managed in decentralized applications.

What level of trust can we put into data providers and how can we mitigate this trust?

Another factor to consider in the use of oracles is that even if we can build in greater redundancy and more effectively govern their usage, there is still a question of trust regarding external API sources. A decentralized application using an external API feed in their oracle still has to trust the data source of that API which might behave incorrectly or abruptly change their formats without notice.

While ChainLink is emerging as one of the most promising solutions to the oracle problem, it too still suffers from this problem of trust, with only market mechanisms to ensure that the participants who take data from the sources are honest, while the actual data source (e.g. CoinMarketCap) have only reputation at stake and no direct economic impact for malicious behaviour.

With Band Protocol TCDs, the governing process of verifying data sources via community will become a streamlined and simple process. Token holders directly vote and stake on who they trust most to provide data as well as data providers also needing to stake to participate in the system. Users are directly incentivised with rewards distributed directly to participants providing utility to the system, which ultimately lead to better outcomes in the management of data sources and reduce overall trust needed in systems that use oracles.

Importantly, Band Protocol and ChainLink systems can tolerate up to 1/3 of malicious data providers, similar to BFT-family consensus. As long as we trust the system that less than this number of providers can be compromised, we can safely trust the oracle.

At Band Protocol we will use the lessons learnt from the Synthetix incident to evaluate how we can improve our systems such that we can assist others to create more effective and secure oracles and decentralized applications. Currently our tools and docs are available for development on Ethereum testnet with availability on mainnet expected in Q3, 2019. Any parties interested in incorporating a Band TCD please reach out, our team is happy to guide teams on integrations and open to collaborations.

Soravis Srinawakoon, CEO Band Protocol

About Band Protocol

Band Protocol is a protocol for decentralized data governance. It operates as an open-source standard and framework for the decentralized management of data. Build and manage off-chain oracles, reputation scores, identity management systems, token issuances and token curated registries.