# Usage of `slot0` is extremely easy to manipulate

Multipool used Uniswap V3 slot0 spot price to compute reserves and LP mint amounts, letting an attacker skew share pricing for depositors.

- Payout: Contest reward
- Severity: high
- Program: Real Wagmi
- Credited: BugBusters
- Disclosed: 2023-06-14
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-06-real-wagmi-judging/issues/97
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-real-wagmi%3AH-3
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:oracle-manipulation

**Target:** Multipool.sol deposit/mint reserve calculation via Uniswap V3 slot0
**Root cause:** Multipool reads slot0.currentSqrtRatioX96 (spot price) to compute token reserves via getAmountsForLiquidity, then derives lpAmount to mint; spot price is trivially manipulable within a block.
**Steps:**
1. Identify Multipool deposit path calling getAmountsForLiquidity with slots[i].currentSqrtRatioX96 from slot0
2. Swap in the underlying Uniswap V3 pool to move slot0 sqrtPriceX96
3. Call deposit/mint while price is skewed so computed reserve0/reserve1 misprice shares
4. Restore price via reverse swap; victim depositors receive fewer LP tokens
**How found:** Code review noting Multipool uses slot0.currentSqrtRatioX96 as price source for reserve and LP mint math, a known manipulable oracle.
**Exploitation:** Attacker manipulates Uniswap V3 pool spot price (slot0) around a victim's deposit/mint transaction so the reserve-derived lpAmount is understated, capturing value from other depositors; slippage params partially mitigate.
**Insight:** When a contract derives share/reserve math from Uniswap V3 slot0, check whether the deposit/mint path has slippage bounds; even with slippage, spot-derived reserves can misprice shares for other users.