# Price can deviate by much more than maxDeviationRate

NFTFloorOracle's maxPriceDeviation only caps a single feed update, so an oracle can call setPrice repeatedly to move price far beyond the intended limit.

- Payout: Contest reward
- Severity: medium
- Program: ParaSpace
- Credited: Trust
- Disclosed: 2023-04-27
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-11-paraspace-findings/issues/491
- Library page: https://bugbountylibrary.com/r/c4%3A2022-11-paraspace%3AM-22
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:business-logic vuln:oracle-manipulation

**Target:** NFTFloorOracle price feed contract
**Root cause:** _checkValidity compares each new TWAP only against the immediately prior stored TWAP, so the deviation limit applies per-update rather than over a time window.
**Steps:**
1. Set maxPriceDeviation=150 (50% allowed growth).
2. Oracles report [1, 1.1, 2]; stored twap for asset is 1.1.
3. Oracle #2 calls `setPrice(1.5)` — deviation 1.5/1.1≈136% < 150, accepted.
4. Oracle #2 calls `setPrice(1.7)` — 1.7/1.5≈113% < 150, accepted.
5. Oracle #2 calls `setPrice(2)` — 2/1.7≈117% < 150, accepted; price now 2 vs original 1.1 (~82% growth).
**How found:** Code review of _checkValidity: noticed deviation is computed only against the last stored twap with no elapsed-time component, so the check is per-transaction rather than rate-limited over time.
**Exploitation:** A single compromised or malicious oracle feed repeatedly submits incremental price updates, each within maxPriceDeviation of the previous, to ratchet the asset price arbitrarily within one block sequence.
**Insight:** When a deviation guard compares only to the last stored value, check whether the update function can be called repeatedly in sequence; a per-step cap without a time window is trivially ratcheted.