An Overview of DeFi Price Oracles

What is an Oracle?
Oracles are the middlemen that bridge the gap between real-world (off-chain)
services and blockchain (on-chain) protocols. Oracles retrieve off-chain data
and post this data to the blockchain for smart contract consumption. They
also relay messages and instructions from a smart contract to off-chain
external systems. In addition, oracles must also ensure that the data that they
provide is accurate and resistant to manipulation.

The ideal price oracle should embody the following:

A high-level accuracy – The price oracle values should reflect the current
data.

Non-gameable – The oracle should be resistant to manipulation.

Timeliness – The data from the price oracle should provide accurate data on a
timely basis, preferably every block.

Decentralized – The oracle price is verified in a decentralized and

permissionless system.

On-chain vs Off-chain Oracles

DeFi oracles can be classified as on-chain, where the prices come from an on-
chain source (e.g. Uniswap), or off-chain, where the prices come from an off-
chain source. Beyond this, oracles can be further categorized as centralized,
where the data is validated by a single operator (e.g. Compound), or
decentralized, where the data is validated by an independent operator (e.g.
MakerDAO).
There are several advantages and disadvantages to using off-chain or on-
chain oracles. The main issue with on-chain oracles is their susceptibility to
manipulation. DeFi has several examples of exploits where on-chain oracles
were combined with flash loans to exploit protocols – Harvest Finance (Oct
2020), yVault (July 2020), bZx (Feb 2020). These exploits led many protocols
to integrate either off-chain or hybrid price oracles into their smart contracts
to reduce the exploitability of their oracles.

Breakdown of Top Ethereum DeFi Oracles

This breakdown covers the most widely used protocols and oracles in DeFi.
Linda Xie has a more in-depth breakdown of DeFi Oracles on her Github.
Chainlink Oracles (Hybrid decentralized)

Chainlink uses a decentralized oracle network of at least 7 independent

node operators. The node operators are responsible for retrieving off-chain
data and providing it to a requesting smart contract. Node operators provide
data in two ways. The first is via Chainlink’s Standard API Model where the
node operators are a separate entity from the data source. The prices
provided by the node operators are aggregated on-chain by the
FluxAggregator into a single response that is used to update the on-chain
Price Reference Feeds. These updates occur when the price deviates from the
off-chain more than the contract deviation threshold or with a minimum time-
based update, the heartbeat threshold. The second model is the Origin Signed
Data Model which occurs when a data provider (e.g. Kaiko) operates their
own node. The provided data is signed with a unique private key and
delivered directly to the smart contracts making the data feed Sybil resistant.
Further, each node operator submits data from a public address which
enables nodes to be evaluated based on their reputation, sometimes termed
“security through transparency”.

MakerDAO v2 Oracles (Off-chain decentralized)

The Maker Protocol uses price oracles, each called a Medianizer, to

determine when to liquidate a Vault and to calculate how much Dai a specific
Vault can generate. Each oracle generates a reference price for a single asset.
Oracles receive data from independent feeds provided by individuals and
organizations.

The v2 version of MakerDAO uses a number of whitelisted addresses as

Feeds. Each Feed pulls the median price from a set of exchanges using a tool
called Setzer. The median price is pushed to the Secure Scuttlebutt
Network that aggregates the price data and sends the reported median prices
to the Medianizer. The Medianizer takes the median of the reported medians
and publishes it as the reference price if 1) the new reference price is greater
than 1% of the source price, or 2) the last price update was more than 6 hours
ago. The reference price is delayed by the Oracle Security Module before it
is used by the other Maker smart contracts.
The Medianizer also controls the addition or removal of whitelisted Feeds
which are voted upon by MKR holders. Each Feed can configure Setzer to
pull from any exchanges of their choosing. The Medianizer contract also sets
the minimum number of valid feeds required for reference price validation.
Because of the MKR voting control over the Medianizer, there could
theoretically be a 51% style attack to manipulate the oracles.

MakerDAO’s price oracles failed during Black Thursday, March 12, 2020, as
high gas prices prevented the Medianizer from updating prices on a timely
basis. ETH fell 43% that day and when MakerDAO’s price oracles were
finally able to update prices, the large price changes led to massive
liquidations where entire vaults were emptied. GlassNode has a really great
write-up detailing the different failure points of MakerDAO on Black
Thursday.

Uniswap v3 Oracles (On-chain decentralized)

Uniswap v2 attempted to remove price oracle manipulation of v2 with the

use of a time-weighted average price (TWAP). The price of the last trade of
the previous block is recorded at the beginning of the block before any trades
occur. An end-of-block cumulative price, the sum of the Uniswap price for
every second, is added to the end of the block which enables users to calculate
accurate TWAPs. TWAPs increase the cost of manipulation since the costs
grow linearly with liquidity on Uniswap and also with the length of time for
the TWAP.

Uniswap v3 is expected to roll out May 5 for Ethereum and May 12 for
Optimism. The team claims it will utilize the same time-weighted average
pricing (TWAP) oracles from v2 with the following upgrades:

The accumulator checkpoints are internal which allows external contracts to

compute on-chain TWAPs over recent periods without storing the previous
accumulator values.
V3 tracks the sum of log prices where users compute the geometric mean
TWAP versus V2 the cumulative sum of prices where users compute the
arithmetic mean TWAP.

A liquidity accumulator is also tracked so users can decide which pools have
the most reliable TWAP.

Users who want a Uniswap v3 price would call the accumulator and take the
values at t1 and t2and calculate the weighted geometric mean price via the
following equation.

The new improvements to the TWAP allow for cheaper calculations for
moving averages and for outlier analysis. The liquidity accumulator also
allows smart contracts to determine which oracles are trustworthy based on
their liquidity. This should reduce the volatility of Uniswap’s price oracles
and reduce mispricings in the smart contracts that utilize them.

Compound Oracles (Hybrid centralized)

Compound uses a mix of off-chain and on-chain price sources for their
oracles. Authorized price sources (“reporters”) can be centralized exchanges,
DeFi protocols, applications, and OTC trading desks. The aggregator contract
receives prices from reporters and verifies them before calculating the median
value. The median value is then published to the Compound market. The
aggregator’s verification logic checks if the new price is within an upper and
lower bound anchor price provided by the anchor contract. If the new price is
outside of those bounds, then the new price is discarded and the reference
price is not updated. Compound holders control the administrators which set
and change the parameters of the aggregator - minimum number of reporters
required to update a price, the address of the anchor contract, and tolerance
rate to determine the upper and lower bounds. Compound holders also dictate
the collateral factor, source of the oracle, and any interest rate model
adjustments.
Synthetix Oracles (On-chain centralized)

As of September 2020, Synthetix has migrated all of their price oracles to

Chainlink oracles. Synthetix instruments include FX, commodity, index, and
cryptocurrency products. Prices for the inverse Synth contracts are calculated
using their partner ‘long’ contracts. Prices for indices are calculated off-chain
by Chainlink then published on-chain. Because Chainlink’s updates occur
only when prices move by 1% or every 6 hours, Synthetix contracts are
subject to potential front-running on their oracle updates. To combat this,
Synthetix created a queuing mechanism where Synth exchanges occur only
after the oracle updates prices. The Syth exchanges are placed in a queue
along with the current blockHeight and can be processed by anybody at any
time. However, the exchanges in the queue are filled only when their source
and destination are updated by an oracle first, thereby eliminating any front-
running possibilities.

Coinbase Oracles (Off-chain decentralized)

The Coinbase price oracle uses the Coinbase Pro API as the source of the
price data. Anyone can publish the prices on-chain since the data is signed
with Coinbase’s private key. This enables users to verify the data authenticity
using Coinbase’s public key. Coinbase also implements an off-chain filter to
reject extreme data points that deviate from the expected volatility range of
prices. It also uses the Compound open oracle’s ‘anchor’ contract as an on-
chain check. If the price of the oracle is too far away from the anchor price, it
is rejected and not pushed to the blockchain.

Compound uses the Coinbase price oracle as a Reporter in its View

Contract. The Coinbase prices are anchored by Uniswap to generate a robust
data source.

How Are Oracles Used in DeFi?

While the main usage of oracles in DeFi is in relation to lending protocol
liquidations, there are several other uses for pricing oracles.

Liquidation of under-collateralized loans – Lending protocols (i.e. Maker,

Compound, Cream, and Aave) rely on price oracles to determine when user’s
loans should be liquidated. If a user’s collateral drops below a certain
threshold, the account is available for liquidation.

Derivative pricing – Derivative platforms (i.e. Synthetix, Perpetual, Hegic) use

oracles to calculate the value of crypto assets - options, futures, synthetic
assets.

Index pricing – Index platforms (e.g. Set) use oracles to retrieve the prices of
the index components.

Insurance protocols – Insurance protocols (e.g. Nexus Mutual) utilize oracles

to verify claims before they are reported to the blockchain and the claim is
released.

Prediction markets – Decentralized prediction markets (i.e. August and

Gnosis) rely on oracles for off-chain event settlement.

Beyond Ethereum Oracles

Oracle solutions exist beyond the above-mentioned Ethereum solutions.
Julien Thevenard and Nikolaos Kostopoulos both review several other
blockchain oracles in their respective articles. Below is a quick overview of
other blockchain oracles that are beyond the scope of this report.

Conclusion
Each oracle, on-chain or off-chain, has its own benefits and weaknesses.
Whether or not Ethereum price oracles will suffer another Black Thursday
MakerDAO meltdown is still yet to be determined. When evaluating oracles,
it helps to keep in mind the following attack vectors:

51% attack: Does a single entity own or a group collude to control a majority
of nodes? The majority can then control which price feeds are used and what
data is considered the absolute truth.

Mirroring attack: Can an oracle node share its data to other nodes that it
controls? False information can spread easily like a game of telephone.

Data manipulation: Are the oracles receiving data from trusted sources?
External data providers could be sending manipulated or bad data.

Liveliness issue: Are the oracles or nodes pushing data on-chain in a timely
manner? Oracle or node updates could be halted either intentionally or
unintentionally causing devastating effects to the smart contracts that depend
on them.

As crypto protocols continue to grow, the importance of accurate on-chain

and off-chain data will increase. Further, as these permissionless protocols are
integrated further with external systems, IoT devices, and other software, the
need for accurately communicating external data to blockchain networks will
garner significant attention. Different use cases may demand specific oracle
designs, and result in protocols or companies selecting specific solutions based
on the aforementioned tradeoffs.