The _smoothed_price function limits individual price jumps, but frequent update_price calls could accumulate changes beyond the 0.5 bps/block threshold over time, weakening manipulation resistance. The codebase partially mitigates this with smoothing but lacks frequency controls.
The relevant code is in _smoothed_price:
vyper
Frequency Exploit: No limit on how often update_price can be called.
Threshold: Docs aim for 0.5 bps/block, but cumulative updates aren’t capped.
PoC
Objective
Accumulate price changes beyond 0.5 bps/block by repeatedly calling update_price.
Prerequisites
PRICE_PARAMETERS_VERIFIER role access.
Deployed scrvUSD oracle.
Exploit Scenario
An attacker triggers frequent updates to push the price up incrementally, bypassing the per-block cap.
Proof of Concept Steps
Setup: Deploy the oracle with max_price_increment = 2 * 10**12 (default).
Exploit Contract:
solidity
Execution:
Call exploit() in a testnet with rapid block production.
Each update adds a small, smoothed increase, but 10 calls exceed 0.5 bps/block cumulatively.
Result: Price rises faster than intended (e.g., >5 bps over 10 blocks), enabling arbitrage.
Outcome
Demonstrates gradual manipulation despite smoothing, exploiting lack of frequency limits.
Gradual Manipulation: Repeated small updates could shift prices significantly, enabling pool arbitrage.
Reduced Safety: Bypasses the intended smoothing protection over time.
Manual Review
Add a minimum time delay between updates in update_price:
vyper
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.