Storage Proofs

Summary

In the ScrvusdOracleV2 contract, the price calculation logic, especially in price_v1 and price_v2, fails to correctly smooth large price changes when raw_price becomes unreasonably inflated. When the calculated raw_price and last_price both become large and their difference is smaller than max_change, the smoothing mechanism bypasses, resulting in significant price discrepancies. This behavior undermines the accuracy of the price feed, potentially causing price manipulation, market instability, and unreliable price signals for external systems.

Vulnerability Details

The issue arises from the following sequence of events:

1. raw_price becomes inflated

In the _obtain_price_params function, the contract simulates multiple periods by repeatedly adjusting params.total_supply and params.balance_of_self. Here’s how it leads to an inflated raw_price:

• Excessive Reduction of total_supply:

Each iteration of the for-loop in _obtain_price_params decreases params.total_supply by a fraction that depends on both balance_of_self and total_supply itself. When number_of_periods is large, these decrements become compounded over many rounds, making params.total_supply artificially small.

• Increment of Idle Assets (total_idle):

Before the loop, the contract calculates a “gain” (based on a fraction of (params.total_idle + params.total_debt)) and adds gain * number_of_periods to params.total_idle. This raises the total asset count in the vault. Consequently, you have a rising numerator (total_assets) combined with a shrinking denominator (total_supply) in the price formula.

• Compounded Effect Over Multiple Periods:

Because _obtain_price_params lumps together multiple cycles of what would normally be periodic adjustments, the iterative reductions in params.total_supply and the repeated additions to params.total_idle result in a disproportionately high ratio. By the time _raw_price is calculated, it sees a significantly higher asset count divided by a significantly lowered supply.

• Resulting Inflated raw_price:

Finally, _raw_price is computed via:

The artificial imbalance—high total_assets and low total_supply—produces an unrealistically large raw_price. This sets the stage for inaccurate price outputs in subsequent functions (e.g., _price_v1, _price_v2) and can bypass smoothing if raw_price and last_price differ by less than max_change.

2. Smoothing bypass: The _smoothed_price function attempts to limit the price changes based on max_change. However, when raw_price is large, and the difference between raw_price and last_price is smaller than max_change, the smoothing logic is bypassed. As a result, the new price (new_price) is applied directly without any constraint, even if it significantly deviates from the previous price.

3. Price fluctuation: The bypassing of the smoothing mechanism leads to large, unaccounted price fluctuations, as the smoothing function that should ensure gradual price changes fails to operate correctly.

In particular, this issue affects price_v1 and price_v2 since they rely on the smoothed prices to provide an accurate representation of scrvUSD value. If the smoothing fails, these price calculations will be inaccurate, and the contract may return an unreasonable price to external systems, leading to inconsistent market data.

Impact

Arbitrage Opportunities: Attackers may exploit the large price discrepancies caused by the bypassed smoothing mechanism, engaging in arbitrage between the contract and other exchanges or protocols.

Market Instability: Uncontrolled price fluctuations can destabilize liquidity pools and other systems relying on this oracle for price feeds, causing financial losses for liquidity providers and users.

Tools Used

Manual Review

Recommendations

Fix the Price Calculation Logic: Ensure that raw_price is properly bounded and adjusted to reflect the actual supply and assets. Apply more rigorous checks to prevent inflation of raw_price due to incorrect parameter adjustments.