The ScrvusdOracleV2.vy
contract allows updating the profit_max_unlock_time
parameter with no restrictions or transition handling. This can lead to significant discrepancies between the calculated oracle prices and actual scrvUSD vault prices, potentially disrupting cross-chain stableswap pools.
The profit_max_unlock_time
parameter is crucial for calculating how profits are unlocked over time in the scrvUSD vault simulation. The contract includes an update_profit_max_unlock_time
function that allows an address with the UNLOCK_TIME_VERIFIER
role to change this value:
The issue is that there are no restrictions on what values can be set, and no mechanism to handle the transition between different unlock periods for profits that are already in the process of unlocking.
A sudden change to profit_max_unlock_time
can cause immediate and significant price discrepancies between the oracle and the actual scrvUSD vault.
This affects cross-chain stableswap pools that rely on this oracle for accurate pricing of scrvUSD.
Users may execute trades based on incorrect pricing, potentially leading to financial losses.
If the change is drastic, it could create arbitrage opportunities that harm liquidity providers.
Since this impacts price calculation, all three price versions (v0, v1, v2) would be affected, though to different degrees.
Manual code review
Implement bounds checking for the profit_max_unlock_time
parameter to prevent extreme values.
Add a change limitation to prevent dramatic changes that could cause price shocks.
Implement transition handling logic for in-progress profit unlocking when the parameter changes.
Consider adding a timelock mechanism for parameter changes to allow users to prepare for upcoming changes.
Require verification that the corresponding parameter has changed in the source contract before updating it in the oracle.
This issue and its duplicates lack sufficient proof of the impact of a sudden change in `profit_max_unlock_time`. Both price parameters and `profit_max_unlock_time` can be adjusted immediately, However, the whole purpose of `_smoothed_price` is to limit sudden updates. This is performed when the raw price and last price is compared within the `_price_v0/v1/v2` function calls to limit price updates to `max_change` The slowed price lag can then be safely arbitrage as mentioned in the docs > Smoothing is introduced for sudden updates, so the price slowly catches up with the price, while the pool is being arbitraged safely. Though, smoothing limits the upper bound of price growth. Therefore, we consider that scrvUSD will never be over 60% APR.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.