# Oracle tick rounding the wrong direction can lead to Swapper overpaying for swap

UniV3Oracle rounds arithmeticMeanTick down, so Swapper bots pay owners less than the intended scaled offer factor, causing owner fund loss.

- Payout: Contest reward
- Severity: medium
- Program: Splits
- Credited: obront
- Disclosed: 2023-04-06
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-04-splits-judging/issues/12
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-04-splits%3AM-2
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:oracle-manipulation

**Target:** UniV3OracleImpl / Swapper oracle price feed
**Root cause:** OracleLibrary.consult() returns arithmeticMeanTick rounded down to nearest tick (1 bp granularity); for Swapper the rounding should favor the owner, not the caller, so the scaled offer factor is under-delivered.
**Steps:**
1. Owner sets $defaultScaledOfferFactor to 99_99_90 expecting ~$100 cost on $10mm.
2. Bot calls flash() to swap; UniV3Oracle returns arithmeticMeanTick rounded down by up to 0.5 bp.
3. Asset valued at FAIR_VALUE*0.995 instead of FAIR_VALUE.
4. Final price = 9_950_000 * 99_99_90 / 1e6 = 9_949_900.50, owner pays ~$50,099.50 instead of $100.
**How found:** Reasoned about oracle rounding direction: noted UniV3Oracle rounds down for collateral safety, but Swapper's caller-vs-owner incentive means rounding should favor owner; checked Uniswap OracleLibrary.consult() and found tick-level (1 bp) truncation.
**Exploitation:** Bot repeatedly calls flash() on Swapper; each swap benefits from the downward tick rounding, accumulating owner losses proportional to volume.
**Insight:** When an oracle price feeds a discount/fee parameter set by one party but consumed by another, check rounding direction against who bears the risk—tick granularity (1 bp) can dwarf a thin configured margin.