Summary

The oracle’s price smoothing mechanism uses a fixed max_price_increment value calibrated for Ethereum average blocktime.

When deployed on chains with shorter blocktimes (e.g., BSC with ~3s blocks), this fixed parameter permits a higher cumulative price change per real-time interval. As a result, even with trusted verifier roles, the design flaw can lead to aggressive price updates that may be exploited to manipulate stableswap pools.

Vulnerability Details

https://github.com/CodeHawks-Contests/2025-03-curve/blob/main/contracts/scrvusd/oracles/ScrvusdOracleV2.vy#L155

The oracle limits the allowed price change per update by calculating:

where,

max_price_increment is defined as a per‐second limit.

The protocol is subject to remain compatible with various blockchain.

On Ethereum, where the average blocktime is about 12 seconds, the allowed price change per update is proportional to a 12-second interval. However, on chains like BSC with an average blocktime of approximately 3 seconds, each block allows only a small price change.

Yet, because blocks occur roughly 4× as often on BSC, an attacker (or a compromised verifier) can trigger updates more frequently. Over the same real-time interval, the cumulative allowed price change on BSC becomes significantly higher than intended by the original design.

The design mistakenly assumes a uniform blocktime across chains. By using a fixed max_price_increment value, the smoothing mechanism does not account for chains with faster block production, leading to a mismatch in cumulative price movement.

Impact

On faster chains, the cumulative allowed price change per minute (or any fixed real-time interval) becomes proportionally higher, deviating from the intended safety threshold. Such abrupt price swings undermine the integrity of the price feed, creating arbitrage opportunities that can harm liquidity providers, even though the roles controlling the updates are assumed to be trusted.

Tools Used

Manual Review

Recommendations

Modify the oracle to adjust the max_price_increment parameter dynamically based on the average blocktime of the chain on which it is deployed. This ensures that the cumulative allowed price change per fixed real-time interval remains consistent with the intended safety threshold.