# Oracle.sol: observe function has overflow risk and should cast to uint256 like Uniswap V3 does

Aloe Oracle.observe omitted Uniswap V3's uint256 cast, so low-liquidity pools can overflow uint160 and corrupt secondsPerLiquidityCumulative, skewing implied volatility and LTV.

- Payout: Contest reward
- Severity: medium
- Program: Aloe
- Credited: roguereddwarf
- Disclosed: 2023-10-11
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-10-aloe-judging/issues/85
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-10-aloe%3AM-8
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:oracle-manipulation

**Target:** Solidity Oracle library (observe/secondsPerLiquidityCumulativeX128)
**Root cause:** In an unchecked block, (liqCumR - liqCumL) * delta is computed in uint160 instead of casting the difference to uint256 first as Uniswap V3 does, so the intermediate product can overflow uint160.
**Steps:**
1. Compare Aloe Oracle.sol L196 `liqCumL + uint160(((liqCumR - liqCumL) * delta) / denom)` against Uniswap V3 which casts the difference to uint256 before multiplying
2. Note liqCumR/liqCumL are uint160 (max ~1.5e48) and delta/denom are uint56
3. Accumulator grows by (uint160(delta)<<128)/liquidity; with liquidity=1 it grows ~3.4e38 per second
4. With observations ~86400s apart: 3.4e38 * 86400 * 86400 ≈ 2.5e48 > 1.5e48, overflowing uint160
5. Resulting secondsPerLiquidityCumulativeX128 is far smaller than correct, feeding wrong values into Volatility IV calc
**How found:** Porting-diff review: author recognized the code was copied from Uniswap V3 and diffed the arithmetic, spotting the missing uint256 cast present upstream.
**Insight:** When a protocol forks well-audited math (Uniswap V3 oracle), diff every arithmetic expression against upstream for dropped casts/checked blocks; overflow bugs hide in unchecked blocks where the original widened the type.