Summary

Adds UniswapV3 TWAP backup oracles to the PegStabilityModules (PSMs) for DAI and ETH. These both have highly liquid USDC pools on Uniswap V3:

• DAI-USDC: ~$300m TVL
• USDC-ETH: ~$285m TVL

Description

A UniswapV3OracleWrapper has been created which implements IOracle.sol. Each asset requires its own UniswapV3OracleWrapper contract to be deployed.

Calculating oracle price and siloing out Uniswap logic

The Maths of calculating the oracle price is siloed out into UniswapWrapper.sol. This is mostly done because the UniswapV3 contracts are written in a version, >=0.5.0 <0.8.0, which is incompatible with the Fei codebase. They rely on underflows and overflows happening in some of their accounting logic, which in >0.8.0 causes reverts.

Oracle config and safety

The oracles settings are controlled by an OracleConfig that is injected in. It has the following form:

struct OracleConfig {
    uint32 twapPeriod;
    uint128 minPoolLiquidity;
    address uniswapPool;
    uint256 precision;
  }

The minPoolLiquidity config is a safety parameter that is used to enforce a minimum level of liquidity in the relevant pool in order to provide a valid reading.

Testing

Integration tests which fork mainnet have been added to the contracts/test/integration folder. Five oracles have been deployed against the corresponding pools:

• daiUsdcPool
• usdcEthPool
• wbtcUsdcPool
• usdtAvinocPool
• usdcFeiPool

The prices returned by the relevant TWAP oracles have been validated manually against the relevant pool spot price. These 5 in particular were chosen because they have parameters (token0, token1, inputNumDecimals, outputNumDecimals) which allow all 4 paths of the Uniswap maths calculation logic to be tested. Details are outlined in the integration tests.

Concern

I think there is a broken abstraction in OracleRef.sol where the decimal normalisation and inversion occurs globally and applies to both the primary and backup oracle price results.

As in this PR, these considerations should be pushed down into the relevant oracle contract. These factors likely need to be taken into account in different ways for different oracles depending on how they calculate the price. For example in calculating the Uni TWAP price, we need to know whether we are inverting when we are calculating the numerator and denominator.

If this UniV3 backupOracle was to be set, and setDecimalsNormalizer() or setDoInvert() were later seperately called on OracleRef.sol - it would result in the backup oracle OracleRef.sol reporting the incorrect price due to this global post processing.

Before deploying this PR, I believe we should:

1. Remove setDecimalsNormalizer() or setDoInvert() from OracleRef.sol and push these considerations down into the primary Chainlink oracle contract