Summary

The ScrvusdOracleV2 contract contains a critical vulnerability in its price approximation mechanism. The _price_v2() function relies on _obtain_price_params() to estimate parameters for future time periods, but there's a design flaw in how parameters are approximated for extended durations. An attacker with admin privileges can manipulate the max_v2_duration parameter to cause artificially inflated price calculations, potentially leading to significant economic damage in cross-chain StableSwap pools.

Vulnerability Details

The vulnerability exists in the parameter approximation logic of _obtain_price_params() function in ScrvusdOracleV2.vy:

The key issues are:

1. Linear Gain Approximation: In line 292-294, params.total_idle is increased by gain * number_of_periods, which assumes a linear growth model without accounting for compounding effects or diminishing returns. This creates unrealistic growth for large values of number_of_periods.

2. Insufficient max_v2_duration Controls: The max_v2_duration parameter can be set by an admin up to MAX_V2_DURATION (defined as 4 * 12 * 4 or 192 periods) which is excessively high given the approximation method used.

3. Flawed Supply Calculation: The loop that updates params.total_supply and params.balance_of_self uses a simplified model that doesn't accurately represent real-world token economics over extended periods.

The vulnerability becomes exploitable through the set_max_v2_duration function:

The only check is that _max_v2_duration must be less than or equal to MAX_V2_DURATION, which is not sufficient to prevent abuse.

Impact

The impact of this vulnerability is severe:

1. Price Manipulation: By setting a high value for max_v2_duration, an attacker can cause price_v2() to return artificially inflated prices.

2. Economic Damage in StableSwap Pools: Since the oracle is designed for cross-chain use in StableSwap pools (as noted in the contest details), manipulated prices would lead to incorrect valuations, enabling profitable arbitrage at the expense of liquidity providers.

3. Cross-Chain Amplification: The impact is amplified because this oracle serves cross-chain markets, potentially affecting multiple blockchains simultaneously.

4. Bypassing Smoothing Mechanism: While the contract includes a smoothing mechanism (_smoothed_price), it only limits instantaneous rate changes. A gradual manipulation via max_v2_duration over time would bypass this protection.

The price distortion could be significant. With realistic parameters, the price could be inflated by several hundred percent when max_v2_duration is set to high values.

Proof of Concept

Below is a detailed proof of concept demonstrating the vulnerability using realistic values. This test shows how an attacker with admin privileges can manipulate the price_v2 value by setting a high max_v2_duration:

This PoC demonstrates that by simply increasing the max_v2_duration parameter, an attacker can cause the price_v2() function to return dramatically inflated values. With realistic parameters, the price can be manipulated to be over 10 times higher than its normal value.

Root Cause Analysis

The root cause of this vulnerability is a combination of:

1. Flawed Mathematical Model: The approximation logic in _obtain_price_params() uses an overly simplistic model that assumes linear growth without accounting for real-world token economics, compounding effects, or diminishing returns.

2. Insufficient Parameter Validation: The set_max_v2_duration() function lacks adequate validation beyond a basic upper bound check, allowing admins to set potentially dangerous values.

3. Unlimited Linear Growth: The calculation params.total_idle += gain * number_of_periods allows for unbounded linear growth, creating unrealistic projections for large values of number_of_periods.

4. Inaccurate Supply Reduction: The loop that reduces params.total_supply uses a simplistic formula that doesn't accurately model how supply changes would occur in reality.

Tools Used

The vulnerability was identified through:

1. Manual code review of the ScrvusdOracleV2.vy contract

2. Mathematical analysis of the price calculation formulas

3. Logical flow analysis of parameter approximation

4. Simulation of different attack scenarios with various parameter values

Recommended Mitigation Steps

To address this vulnerability, I recommend implementing the following mitigations:

1. Implement Diminishing Returns Model: Replace the linear gain calculation with a model that accounts for diminishing returns over time:

1. Add Reasonable Hard Cap: Implement a stricter hard cap on max_v2_duration that cannot be bypassed by admins:

1. Implement Price Variance Circuit Breaker: Add a circuit breaker mechanism that limits how much price_v2() can deviate from more conservative price calculations:

1. Improve Parameter Validation: Add validation to ensure the approximated parameters remain within realistic boundaries:

1. Consider Alternative Approximation Methods: For long-term approximations, consider implementing more sophisticated models that better represent real-world yield accrual and token economics.

By implementing these mitigations, particularly the diminishing returns model and the circuit breaker, the contract would be significantly more resistant to price manipulation even if an admin sets a high max_v2_duration value.