# Wrong calculation of `tickCumulatives` due to hardcoded pool fees

Multipool hardcodes Uniswap V3 fee tier 500 when reading tickCumulatives, so slippage checks use the wrong pool and can misprice rebalances.

- Payout: Contest reward
- Severity: high
- Program: Real Wagmi
- Credited: Bauchibred
- Disclosed: 2023-06-14
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-06-real-wagmi-judging/issues/48
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-real-wagmi%3AH-1
- 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:** Multipool.sol swap slippage check via Uniswap V3 pool oracle
**Root cause:** The contract indexes underlyingTrustedPools[500] unconditionally, assuming every token pair has a 500-fee Uniswap V3 pool and that it is the correct/optimal source for tickCumulatives.
**Steps:**
1. Inspect Multipool.sol L816-L838: `IUniswapV3Pool(underlyingTrustedPools[500].poolAddress)` used to fetch tickCumulatives for slippage.
2. Identify a token pair whose active/optimal pool uses a different fee tier (e.g. 3000) or has no 500 pool.
3. Trigger a swap/rebalance path that reads tickCumulatives from the wrong (or nonexistent/low-volume) 500 pool.
4. Observe computed amountOut/slippage diverges from the actual swap pool, allowing rebalance to execute at unfavorable prices or revert.
**How found:** Code reading of the swap slippage logic revealed a hardcoded `500` index into underlyingTrustedPools, then reasoning about chains/pairs lacking 500-fee pools or where the 500 pool is low-volume.
**Insight:** When a contract reads a Uniswap V3 TWAP/tickCumulatives for slippage, verify the pool address is derived from the actual swap pool's fee tier rather than a constant index; low-volume or missing fee-tier pools silently corrupt oracle math.