Research Summary: A First Look into DeFi Oracles

TLDR:

  • This paper compares the design of the DeFi price oracles about their price volatility, deviation, and error rate.
  • They propose oracle design guidelines including (1) transparent source, (2) action accountability, and (3) ways to prevent transaction failures.

Citation

  • Liu, Bowen, and Pawel Szalachowski. “A First Look into DeFi Oracles.” arXiv preprint arXiv:2005.04377 (2020).

Link

Core Research Question

  • What is the state of current oracle design and how can they become better?

Background

  • Decentralized Finance (DeFi) implements traditional financial logic in blockchain smart contracts, but smart contracts cannot access data out of the network such as real-time market price.
  • Oracles are third parties that provide data from the real world to smart contracts.
  • Price deviation happens when the price reported by the oracles is different from the real world.
  • Stable coins are cryptocurrencies designed to minimize the volatility of the price, usually 1:1 USD pegged.
  • MakerDAO: the most popular decentralized lending protocol
    • Platform mechanism: Users deposit crypto assets in a special smart contract to generate the DAI token, which is their stable coin. However, if the value of the deposited asset is under 150% of the borrowed DAI, the asset will be liquidated.
    • How Oracles are used: Get real time prices of the deposited assets to determine whether liquidation should take place.
    • Oracle design: A number of whitelisted oracle addresses sending prices periodically to an aggregator smart contract, which takes the median of the prices. MakerDAO’s governance token holders can vote to add or remove the whitelisted oracle addresses and other parameters for aggregating the prices.
    • Risk: The oracle price can be maliciously manipulated by governance token holders. It assumes more than 50% of the oracles are honest.
  • Compound: decentralized lending and borrowing platform
    • Platform mechanism: Users deposit crypto assets to the Compound smart contract and borrow from it. The smart contract matches the borrower and lenders. The interest rates or collateral factors can be updated by voting from the governance token holders.
    • The use of oracles: similar to MakerDAO
    • Oracle design: similar to MakerDAO, but the price will not be updated if the difference between the new and old price exceeds 10%.
    • Risk: similar to MakerDAO but more manageable as the price will not fluctuate too much.
  • AmpleForth: a stable coin with supply volatility but not price volatility
    • Platform mechanism: The AMPL token is a stable coin that adjusts the total supply of tokens as the demand changes. The price per token does not change. Specifically, the balance of AMPL in a user’s wallet may increase or decrease once a day based on the market demand of AMPL.
    • The use of oracles: Get the price of an inflation-adjusted US dollar
    • Oracle design: similar to Compound, but with an expiration date on the reported price. The oracles report every 12 hours.
    • Risk: There is no voting mechanism. All system changes are controlled by a multisig contract, which means the users should assume the AmpleForth team is trustworthy.
  • Chainlink: a decentralized oracle network that provides smart contract API
    • Platform mechanism: It provides API for smart contracts to access external data. Developers can access pre-approved data sources, such as market price, flights, and shipping data. They can also leverage Chainlink’s API to add any custom external data.
    • Oracle design: Similar to MakerDAO, they use aggregator smart contracts to aggregate the price from multiple oracle sources.
    • Platforms using it: AmpleForth, Synthetix
    • Risk: The risk is diversified and reduced since there are multiple price sources.
  • Synthetix: a platform for creating and exchanging synthetic versions of assets
    • Platform mechanism: Users can deposit SNX, the Synthetix’s native token, in the Synthetix smart contract to create synthetic tokens. sUSD is the token on the platform that is always valued at 1 USD.
    • The use of oracles: Get the price of USD for sUSD
    • Oracle design: There is an independent Chainlink aggregator for each asset. The oracles update the price every 5 to 10 minutes.
    • Risk: similar to ChainLink

Summary

  • The authors explain oracle designs deployed in practice.

  • They systematically investigate the deployment of four popular DeFi oracles platforms: MakerDAO, Compound, AmpleForth, and Synthetix.

    • They compare oracle design
  • They measure the price volatility of stable coins.

  • They measure the price deviation between the oracle’s reported price and the real market price.

  • They investigate oracle price outliers (sudden changes in real-time price or mistakes by oracles themselves).

  • They investigate Oracles’ failed Ethereum transactions or if Oracles revert themselves.

  • They measure the behaviors of oracles by transaction graph analysis.

  • They compare the deployed platforms in terms of the oracle design, updating frequency, and decentralization.

  • They suggest guidelines for future oracle design and measure the average cost (transaction fee and gas) of an oracle operator.

  • Finally the authors discuss related works and oracle design and research.

Method

  • To measure a stablecoin’s price stability within DeFi protocols, the authors summarize daily changes of the market prices from coinmarketcap.com. The stability of these stablecoins are important because DeFi protocols rely on them to provide services, such as DAI and AMPL.
  • To measure the price deviation between oracle and the market, they use Ethereum’s BigQuery database to get all the on-chain oracle transactions. The market prices are obtained from multiple exchanges (Coinmarketcap, Bitfinex, CoinbasePro, Kraken, Bittrex).
  • To perform transaction graph analysis, they crawled the entire transaction history of oracles by using BigQuery, built transaction graphs, and investigated the common addresses interacting with the oracles.

Results

  • The price volatility of stable coins:
    • Stableness: DAI > AMPL > SNX
    • Note:
      • SAI is no longer functional as of May 12, 2020
      • SNX is not a stablecoin.
  • The price deviation of different platforms:
    • Deviation: Synthetix < MakerDAO < Compound < AmpleForth
    • AmpleForth has low deviation because their oracle prices are averaged over a longer period (12 hours).
    • AmpleForth may have the largest deviation due to the measurement inaccuracy, as they do not provide APIs for accessing real time prices.
  • The outlier deviation of price oracles
    • Synthetix < Compound < MakerDAO < AmpleForth
    • AmpleForth has a historical deviation of around 270%, which may be due to the inaccurate entries in their oracle.
  • The types of oracle failures
    • Out of gas
    • Transaction reverted (may due to incorrect input from the oracle itself)
    • Unstableness of the oracle sources (some oracles do not respond to requests)
  • The transaction activities related to oracles
    • AmpleForth and Synthetix
      • Most activities use Chainlink’s aggregator contracts, other transactions are for testing purposes.
    • MakerDAO and Compound
      • Only their oracles report prices

Discussion & Key Takeaways

  • This paper exhaustively studied four platforms with oracle and provided some insights
    • Price volatility of stable coins: DAI > AMPL > SNX
    • Oracle decentralization: Synthetix > AmpleForth > Compound, MakerDAO
    • Price deviation of oracles (mostly below 5%): Synthetix < MakerDAO < Compound < AmpleForth
    • Outlier deviation severity: Synthetix < Compound < MakerDAO < AmpleForth
    • Oracle source transparency: Compound, Synthetix > AmpleForth > MakerDAO
    • Average gas cost for oracles: Compound < MakerDAO < AmpleForth < Synthetix
  • Recommendations of the oracle design
    • Oracle sources should be publicly visible

      • Problem: A lack of transparency may lead to undetectable oracle behavior.
      • Solution: Define a manifest smart contract interface for all oracles to specify their updating frequency, the data sources, etc.
    • Oracles should be accountable for their actions

      • Problem: Oracles may submit the wrong data
      • Solution: The oracles first deposit crypto assets to an accountability smart contract, which will punish the misbehaviors given enough proof. The manifest smart contract mentioned above allows the misbehaviors to be proved.
    • Oracles should be robust and send few failing transactions.

      • Problem: Some oracles transactions have out-of-gas errors and may delay price reports.
      • Solution: Oracle operators can increase the amount of gas to avoid out-of-gas errors and increase gas price to let a transaction be processed in time.
      • The suggested gas amount and gas prices:

Implications & Follow-ups

  • From the observations, the more decentralized an oracle design is, the more expensive gas prices and the least outlier deviation severity it will have.
  • The authors provide a comparison between their proposed oracle design guidelines and Chainlink’s. However, some design guidelines such as the punishment and reward scheme for oracle operators are included in Chainlink’s decentralized oracle.
  • The authors further calculate the reward for the decentralized oracles considering the surveyed gas cost.
  • Although there is price deviation for the oracles, most of the difference is only within 1% to 5%, and the price outliers rarely present (only 2 for each platform). This implies that the four platform’s oracles are stable and should be safe to use.

Applicability

  • This paper presents a comprehensive way to measure and evaluate oracle designs, which can be applied to analyze other existing platforms. It also provides future developers an overview of what kind of oracle design will yield to what results.
  • To sum up, if an application requires less price deviation severity (all below 10%) and is willing to pay more on the gas, they may leverage decentralized oracles such as Chainlink. Otherwise, if they prefer a lower gas price and can tolerate slightly larger price deviation, they can consider implementing their own oracles.
  • The survey of oracle’s gas cost can provide the oracle operators an overview of what gas limit and gas price can guarantee the price updating transaction to be successfully executed in time.
2 Likes

Great writeup Tina, thanks for sharing. It also provides a killer snapshot of where we were even a year ago.

In terms of gas costs, one of the updates to Chainlink that I’ve been looking forward to is the upcoming release of Off-Chain Reporting (OCR), which should give a ~90% gas cost reduction for pushing a price update, which allows for even narrower deviation thresholds. Here’s a solid overview into the protocol. The long and short of it is that instead of every node publishing their results to be aggregated onchain, a random node in a network of nodes will be the “reporter”, and the other nodes will submit their answers to be aggregated and reported by that node.

1 Like

Thanks for sharing this Eric! It seems like a good solution for reducing gas price.

1 Like