You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The bug depends on whether the YAM address is numerically higher or lower than the token it's paired with. Therefore it is either activated at deploy time, or never activated. Thankfully it does not seem that this bug was activated on the existing deploys.
It seems to have been caused by a copy-paste error when modifying the Uniswap library. Perhaps consider using the Uniswap library directly.
Fix is simple. Change to FixedPoint.fraction(reserve0, reserve1)._x)
The text was updated successfully, but these errors were encountered:
Unfortunately this wasn't caught in our test suite, but would have been had any test deployment resulted in isToken0 to be false. As we have a positive and negative rebase test that would have failed. But didn't have any deployments where we hit that.
This line has the reserves out of order. If it is executed, it will cause the oracle to return an incorrect price. This will cause incorrect rebases.
https://github.com/yam-finance/yam-protocol/blob/master/contracts/lib/UniswapV2OracleLibrary.sol#L31
The bug depends on whether the YAM address is numerically higher or lower than the token it's paired with. Therefore it is either activated at deploy time, or never activated. Thankfully it does not seem that this bug was activated on the existing deploys.
It seems to have been caused by a copy-paste error when modifying the Uniswap library. Perhaps consider using the Uniswap library directly.
Fix is simple. Change to
FixedPoint.fraction(reserve0, reserve1)._x)
The text was updated successfully, but these errors were encountered: