Storage Proofs

Summary

In ScrvUsdOracleV2.vy, v1and v2are projected prices. However, due to the logic in _obtain_price_params_ _whereby:

if params.last_profit_update + period >= parameters_ts:````return params

This would lead to the function always retrieving the current price params, hence resulting in no price projection even for v1and v2prices.

Vulnerability Details

Looking at the flow, beginning at update_price:

1. self.last_prices = [self._price_v0(), self._price_v1(), self._price_v2()]

2. Looking at _price_v1first:

   1. it will calculate the smoothed price of the last stored v1 price and _raw_price(block.timestamp, self.price_params_ts

   2. In _raw_price, it will now pass self.price_params_tsin obtain_price_params

   3. The below check in obtain_price_paramswill now return the current stored params

      period: uint256 = self.profit_max_unlock_time

      if params.last_profit_update + period >= parameters_ts:

      return params

Since profit_max_unlock_time == 7 * 86400, the last profit update + 1 week will be certain to be more than the last stored price_params_ts.

1. Now for _price_v2:

   1. it will calculate the smoothed price of the last stored v2 price and _raw_price(block.timestamp, block.timestamp)

   2. n _raw_price, it will now pass block.timestampin obtain_price_params

   3. If the last profit update + 1 week >= block.timestamp, it will return last stored params. This means that if price is updated via update_price, it will only calculate price projections for v2 if the function is called more than 1 week from last profit update, which would result in stale price updates.

Impact

When updating self.last_prices, the V1 and v2 price will always be based on last stored params, instead of projecting price based on periods. Due to this, the core logic of the function is broken as the price update does not consider correct price projections to ensure safe and precise approximation.

Tools Used

Manual