# Overflow can still happen when calculating priceX8 inside poolMatchesOracle operation

Good Entry's poolMatchesOracle overflows computing priceX8 from sqrtPriceX96 for WBTC/WETH, breaking rebalance price checks.

- Payout: Contest reward
- Severity: high
- Program: Good Entry
- Credited: said
- Disclosed: 2023-10-02
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-08-goodentry-findings/issues/140
- Library page: https://bugbountylibrary.com/r/c4%3A2023-08-goodentry%3AH-03
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:evm tech:solidity vuln:accounting-error

**Target:** GeVault poolMatchesOracle price calculation (Uniswap v3 sqrtPriceX96)
**Root cause:** Scaling down sqrtPriceX96 by 2**12 before squaring is insufficient; the squared value times 1e8 still exceeds uint256 for realistic WBTC/WETH sqrtPriceX96, causing arithmetic overflow.
**Steps:**
1. Take WBTC/WETH Uniswap v3 pool 0x4585FE77225b41b697C938B018E2Ac67Ac5a20c0 slot0 sqrtPriceX96 = 31520141554881197083247204479961147.
2. token0 WBTC decimals 8, token1 WETH decimals 18.
3. Compute priceX8 = (1e8 * uint(sqrtPriceX96 / 2**12)**2 * 1e8) / 2**168.
4. Observe Arithmetic over/underflow revert in test.
**How found:** Code reading of poolMatchesOracle's scaling math; tested with a real widely-used WBTC/WETH pool's sqrtPriceX96 to show the 2**12 downscale is inadequate.
**Insight:** When converting sqrtPriceX96 to price, square before dividing by 2**192 or split the division (e.g. sqrtPriceX96**2 / 2**64 then / 2**128) to avoid overflow; test with real high-decimal-token pool values, not toy numbers.