# The getOwnValuation() function contains errors in the price calculation

USSDRebalancer.getOwnValuation miscomputes Uniswap V3 sqrtPriceX96 price due to wrong decimal scaling, yielding inaccurate USSD valuation used for rebalancing.

- Payout: Contest reward
- Severity: high
- Program: USSD
- Credited: 0xPkhatri
- Disclosed: 2023-05-15
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-05-USSD-judging/issues/222
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-05-USSD%3AH-3
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity vuln:accounting-error vuln:oracle-manipulation vuln:precision-loss

**Target:** USSDRebalancer.getOwnValuation() Uniswap V3 price math
**Root cause:** Price scaling uses division by 1e6 and 1e18 instead of multiplication by 1e6, misplacing decimal adjustment relative to the sqrtPriceX96 squared shift.
**Steps:**
1. Read USSDRebalancer.sol L74/L76 getOwnValuation().
2. Observe token0==USSD branch: `price = sqrtPriceX96*sqrtPriceX96/(1e6) >> 192`.
3. Observe token1==USSD branch uses `*1e18` then `(1e24/price)/1e12`.
4. Compare to Uniswap V3 math primer: correct scaling is `*1e6 >> 192`.
5. Resulting price is off by ~1e12, corrupting rebalance valuation.
**How found:** Manual review comparing getOwnValuation() scaling against the Uniswap V3 math primer; noticed division by 1e6 where multiplication was expected.
**Insight:** When auditing Uniswap V3 price derivations, verify the decimal scaling factor (1e6 vs 1e18) and its position relative to the >>192 shift; a misplaced divide vs multiply silently skews valuation by 1e12.