# `UniV2LPOracle` will malfunction if token0 or token1's `decimals != 18`

UniV2LPOracle assumed both LP tokens have 18 decimals, so USDC/WETH pairs priced ~1000x too low, corrupting collateral valuation.

- Payout: Contest reward
- Severity: high
- Program: Sentiment
- Credited: Lambda
- Disclosed: 2022-08-30
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-08-sentiment-judging/tree/main/026-H
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-08-sentiment%3AH-5
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:oracle-manipulation

**Target:** UniV2LPOracle.getPrice LP token price oracle
**Root cause:** getPrice feeds raw getReserves() values into mulWadDown (which divides by 1e18) without normalizing token0/token1 decimals, so reserves of 6-decimal tokens are treated as 18-decimal.
**Steps:**
1. Deploy UniV2LpOracle with OracleFacade wired to Chainlink USDC/USD and WETH oracle.
2. Call getPrice on USDC/WETH pair `0xB4e16d0168e52d35CaCD2c6185b44281Ec28C9Dc`.
3. Observe reserves r0=45456843739761 (USDC, 6 decimals), r1=28342500764440756425363 (WETH, 18 decimals).
4. Result returns 0.1027e18 instead of expected ~102728e18 — off by ~1e6.
**How found:** Code review of the Alpha Homora fair LP pricing formula implementation; noticed mulWadDown divides by 1e18 unconditionally while reserves are raw token units, then validated against a real USDC/WETH pair on mainnet.
**Insight:** When porting a pricing formula that assumes WAD math, audit every input for implicit 18-decimal assumptions — Uniswap reserves are raw token units, so any mulWadDown on getReserves() silently misprices pairs with non-18-decimal tokens like USDC/USDT/WBTC.