Skip to content
This repository has been archived by the owner on Jan 13, 2023. It is now read-only.

[BAC-119] Use Uniswap V2 and Curve in DAI-USD oracle #498

Merged
merged 13 commits into from
Aug 28, 2020

Conversation

Kenadia
Copy link
Contributor

@Kenadia Kenadia commented Aug 27, 2020

No description provided.

@Kenadia Kenadia requested a review from BrendanChou August 27, 2020 05:10
@Kenadia Kenadia changed the title Use Uniswap V2 and Curve in DAI-USD oracle [BAC-119] Use Uniswap V2 and Curve in DAI-USD oracle Aug 27, 2020
@linear
Copy link

linear bot commented Aug 27, 2020

Copy link

@BrendanChou BrendanChou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking that it might make more sense to use Uniswap ETH-USDC for the ETH price rather than a Maker Oracle. The Uniswap pools are quite deep these days, and the price should be off by no more than 0.3% due to arbitrage opportunities. This is tighter than most other on-chain oracles (Maker, Chainlink, etc) which are often updated if the price is off by more than 0.5% or 1.0%

Comment on lines 227 to 228
getCurvePrice().value,
getUniswapPrice(ethUsd).value

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: should we maybe just return a uint256 instead of Monetary.Price from these functions? seems unnecessary to wrap and unwrap the values like this

// Parameters used when getting the DAI-USD price from Curve.
int128 constant CURVE_DAI_ID = 0;
int128 constant CURVE_USDC_ID = 1;
uint256 constant CURVE_FEE_DENOMINATOR = 10000000000;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: prefer 10 ** 10 for readability

view
returns (uint256);

function get_dy_underlying(

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you prefer get_dy_underlying over get_dy as get_dy_underlying works on more types of Curve pools? Are there any gas implications to that?

Copy link
Contributor Author

@Kenadia Kenadia Aug 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the source code I thought get_dy_underlying was going to be cheaper, but looks like that's not the case. 55572 vs 55037. So I'll use get_dy instead.

BrendanChou
BrendanChou previously approved these changes Aug 28, 2020
Comment on lines 282 to 284
uint256 uniswapPrice = UNISWAP_DECIMALS_BASE
.mul(usdcAmt)
.mul(poolOneEthAmt)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe there's potential for overflow here for some tokens.
I think it should be fine for USDC since it has only 6 decimals.

10^30 * 10^6 * 10^18 for 1 USDC and 1 ETH

Maybe something to keep in mind or at least comment

edit: I see you have a test for this which is great

Comment on lines +277 to +278
(uint256 daiAmt, uint256 poolOneEthAmt, ) = UNISWAP_DAI_ETH.getReserves();
(uint256 usdcAmt, uint256 poolTwoEthAmt, ) = UNISWAP_USDC_ETH.getReserves();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe comment that the order is dependent on the pool. For a different address paired with ETH, the order might not be ETH-2nd

* Another mock Uniswap V2 pair.
*/
contract TestUniswapV2Pair2 is
IUniswapV2Pair

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: you can just have it inherit from TestUniswapV2Pair1 and add no new functions or variables

@BrendanChou BrendanChou merged commit efcbbab into master Aug 28, 2020
@BrendanChou BrendanChou deleted the ken/dai-oracle-update branch August 28, 2020 19:54
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants