Is Uniswap still an oracle protocol?

Author: Alex Kroeger

Translator: Block unicorn

In May of this year, Vitalik created a post on the Uniswap governance forum titled "UNI Should Be an Oracle Token." He argued that oracles need to provide off-chain data, and UNI is well-positioned to offer an alternative to Chainlink for high-value, latency-tolerant use cases.

While this is an interesting idea, as I recently reflected in that post, I have been thinking about how Uniswap is already an oracle protocol. It has been providing price information from the largest DEX on Ethereum. UNI is already an oracle token, and the UNI DAO has done little to capitalize on this fact, at least so far.

The History of Uniswap as an Oracle

Since v1, Uniswap has been an oracle protocol, albeit a very rough one at that time. Uniswap v1 was a series of ETH-ERC20 mining pools with a simple x * y = k pricing mechanism. You could query the value of ETH and the corresponding ERC20 token in any pool, and you had a spot price oracle.

However, v1 had many shortcomings as an oracle protocol. First, everything was priced in ETH. To get non-ETH quotes, such as the BAT price in USDC, you needed to link prices together (in this case, BAT-ETH and ETH-USDC).

Second, the price was a simple point in time (more specifically, a block's point) spot price. This was easily manipulable because "unfortunately," liquidity withdrawals and large trades could significantly swing the price. I wouldn't recommend relying on this price for sensitive tasks, such as determining whether a borrowing position is underwater.

v2 improved Uniswap's utility as an oracle. First, v2 allowed for arbitrary ERC20-ERC20 pairs. Second, each mining pool would take a snapshot of the price at the starting block before any trades or liquidity changes occurred, making manipulation more difficult. Finally, the stored price value (price multiplied by the running accumulator of seconds since the last block) allowed users to calculate a time-weighted average price (TWAP) instead of a simple spot price.

However, obtaining TWAP from v2 pools was not out-of-the-box—it required integrators to store past values of the running accumulator in a separate contract for calculations.

Uniswap v3 retained the benefits provided by v2 but also addressed the aforementioned shortcomings by allowing the storage of a series of accumulator values (by default, only 1 value is stored, but anyone willing to pay gas costs can expand the number of tracked values up to 65,535 observations, or about 9 days of prices).

Oracle Use Cases

Uniswap v3 has already been used as an on-chain oracle in various environments, with many projects calling Uniswap v3's oracle functionality from their contracts, including:

• Popsicle Finance (LP yield optimization protocol)
• keep3r network (decentralized task running protocol)
• Frax (an algorithmic stablecoin)
• Lixir Finance (LP manager for Uniswap v3)
• Rari Capital (creator of the Fuse lending protocol)
• Babylon Finance (decentralized asset management)
• Unipilot (LP yield optimization protocol)
• Angle (a stablecoin protocol)

These oracle calls are made across various pairs. As we can see in the chart below, while USDC-WETH is the most frequently called currency pair, it only accounts for 17% of oracle calls. The assets using oracle functionality have a long tail. Many of these are directly related to the aforementioned protocols (e.g., FRAX, KP3R). However, more are assets for which Uniswap may be one of the most important sources of liquidity (e.g., ENS, and of course, ELON).

Uniswap DAO as the Guardian of Oracles

The oracle functionality has been utilized, although materials on the performance of Uniswap oracles are relatively scarce (though I recommend the excellent thread by Michael Bentley on the costs of attacking v3 oracles).

The priestess working with the oracle at Delphi would receive her words and spread the answers to the petitioners.

However, where is the motivation to improve and maintain the oracle experience? The use of oracles currently does not benefit the protocol's traders, LPs, or maintainers.

Protocol trading fees are already a potential source of DAO cash flow in v2 and v3 (though no fees have been charged so far).

It is worth considering the fees for using price oracles. While this would require some changes to the protocol, it could be implemented as a fixed ETH fee per call or by registering project contracts on a series of approved oracle callers.

In exchange for these fees, the Uniswap DAO could become the "guardians of the oracles." What would this mean in practice? The DAO could:

• Act as the "last liquidity provider"
• Provide liquidity incentives to high-value mining pools acting as price oracles
• Provide data and research on oracle performance
• Offer better documentation on best practices for oracle usage

By "last liquidity provider," I mean that the DAO could create an automated strategy or designate an LP manager to provide a certain amount of passive liquidity to important oracles and liquidity-poor pools. This could prevent attacks and respond to attacks spanning multiple blocks that involve withdrawing liquidity or affecting the liquidity balance of the pool.

Current Limitations of Uniswap Oracles

This discussion feels incomplete without acknowledging some of the limitations of using Uniswap oracles that exist today.

While it is not recommended to use simple spot prices from AMMs (rather than TWAP), TWAP reduces the freshness of the data (by definition, it adapts more slowly to changing market conditions). When choosing the time length for measuring TWAP, you face a dilemma:

• The shorter the time window, the more easily TWAP can be manipulated.
• The longer the time window, the slower TWAP adjusts to changing market prices.

Take lending protocols as an example. If the price of collateral suddenly drops, and the TWAP only reflects the position as under-collateralized 30 minutes after the downtrend begins, the spot price may be lower by then, which could lead to losses for the protocol on what may now be an underwater position.

That said, the appeal of Uniswap oracles lies in their relatively autonomous operation. Even without the additional assurances that a DAO could provide, they will continue to function normally as long as there are incentives for market participants.

Returning to Vitalik's post, it might be interesting to explore how the DAO could use the current pool TWAP model as a component of an oracle solution to add fresher off-chain price data sources.