Summary

In this oracle system, each new raw price received from L1 is clamped so it cannot deviate from the current on‐chain price beyond a specified increment. This smoothing is intended to protect against sudden large manipulations. However, if L1’s actual price changes quickly, it may take multiple incremental updates for the L2 price to “catch up.” During that time, an arbitrager can exploit the difference in the pool if they learn the new raw price before it’s fully reflected on L2.

Vulnerability Details

The _smoothed_price() calculates a max_change based on max_price_increment, time elapsed, and last_price. If the difference between raw_price and last_price exceeds max_change, it clamps the new price to the maximum allowed step:

• Attack scenario :
  Assume a spike in price happened on L1. Due to the update limit on L2 :

• Someone can purchase the underpriced scrvUSD on L2 (which is lagging behind the real price).

• Bridge it back to L1, where it’s worth more (because the L1 price has jumped).

• Sell or redeem for a profit.

Impact

• Liquidity providers in the stableswap pool may suffer from arbitrage if the L2 oracle price is out of sync with the true L1 price for an extended period.

• Attackers can exploit partial increments if they know a price jump is coming.

Tools Used

Manual review

Recommendations

Since the oracle updates every 30 minutes, having a brief cooldown on deposits/withdrawals right after an update will reduce the risk of users exploiting the price while it’s still lagging behind L1. This short delay should only be applied in case the raw_price spikes beyond max_change to reduce user inconvenience.