# DoS in Liquidity Migration due to Unit Mismatch in UniswapPriceOracle

UniswapPriceOracle.validatePrice compares 1e16-scaled derivation against raw-percent slippage, so any deviation reverts and blocks V2-to-V3 liquidity migration.

- Payout: Contest reward
- Severity: medium
- Program: Olas
- Credited: ElmInNyc99
- Disclosed: 2026-05-18
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2026-01-olas#m-04
- Library page: https://bugbountylibrary.com/r/c4%3A2026-01-olas%3AM-04
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** UniswapPriceOracle.validatePrice / LiquidityManagerETH.convertToV3
**Root cause:** validatePrice computes derivation scaled to 1e16 (100%) but compares it to slippage passed as a raw percentage integer, so the comparison is off by 1e14.
**Steps:**
1. Call LiquidityManagerETH.convertToV3(), which invokes _checkTokensAndRemoveLiquidityV2.
2. It calls IOracle(oracleV2).validatePrice(maxSlippage / 100), passing slippage as raw percent (e.g. 50).
3. validatePrice computes derivation = (diff * 1e16) / timeWeightedAverage; a 5% deviation yields 5e14.
4. Check `5e14 <= 50` is false, so validatePrice returns false and convertToV3 reverts with SlippageLimitBreached().
**How found:** Code review comparing UniswapPriceOracle against BalancerPriceOracle, which correctly normalizes slippage; noticed the missing scaling factor in the derivation comparison.
**Insight:** When auditing oracle slippage checks, verify the unit/scale of both sides of every comparison; diffing a sibling oracle implementation (Balancer vs Uniswap) exposes missing normalization.