Summary

Using a single Oracle architecture is risky, this risk has already been accepted, but it's more risky; This oracle structure is written as hardcoded, it is recommended to design in an architecture that will switch to another oracle structure at any time.

Vulnerability Details

As in the LUNA example, oracles can stop, break down, do not give wrong prices, but their decentralization can be broken, it is always risky to use a single oracle because of such risks.

Impact

Tools Used

Manuel Code Review

Recommendations

Chainlink price feed e Uniswap V3 TWAP or Time Weighted Average Pricing Oracle eklenebilir

Firstly, many Chainlink price feeds lag behind real market pricing due to only updating after significant price changes (0.5%). Chainlink price feeds can be front ran via off-chain pricing or viewing the mempool.

Uniswap V3 TWAP or Time Weighted Average Pricing Oracles also suffer from lagging price updates as they take an average of the price observed from the last several blocks. Uniswap V3 TWAP oracles have front-running resistance due to the large amount of capital being needed over a larger time frame to successfully manipulate a Uniswap V3 TWAP Oracle.

The 10-minute window for Uniswap V3 Oracles was selected from weighing attack resistance vs. price accuracy; choosing too long of a window would result in larger deviations from spot prices, and too short of a window would result in easier manipulation.

A larger spread that is positive to the protocol would be akin to a higher transaction fee due to volatility, where front-running risk is higher.

This combination oracle design was also utilized to increase decentralization. As Uniswap V3 Oracles are immutable, and Chainlink's multi-sig can be updated without any timelock with a 3-of-20 multi-sig, a middle ground upon being the best of both worlds in data reliability and decentralization.