# Pool with 19 splits will never be usable

JumpyFallback.at starts its cursor at index 1<<splits, so a pool with 19 splits reads tree[524288] out of bounds and every pour reverts, making the pool permanently unusable.

- Payout: Contest reward
- Severity: medium
- Program: InfinityPools
- Credited: zigtur
- Disclosed: 2025-01-13
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_infinitypools_october2024.pdf#3.2.1
- Library page: https://bugbountylibrary.com/r/cantina%3Ainfinitypools_october2024%3A3.2.1
- Tags: domain:web3 impact:dos kind:contest platform:cantina sev:medium tech:evm tech:solidity technique:source-review vuln:dos

**Target:** JumpyFallback library / InfinityPool.pour
**Root cause:** Info.tree is sized 1<<MAX_SPLITS (524288 elements, max index 524287) but at() initializes cursor to 1<<splits, which equals 524288 when splits=19, so the first tree[cursor] read is out of bounds.
**Steps:**
1. Create pool via `factory.createPool(token0, token1, 19)` and fetch it with `getPool(token0, token1, 19)`.
2. Call `setInitialPriceAndVariance(fromUint256(1), fromUint256(1))` and warp forward.
3. Approve tokens and call `infinityPool.pour(0, TUBS, fromUint256(10), "")`.
4. Observe revert with panic 0x32 (array out-of-bounds) at `self.tree[cursor.toUint256()]` in JumpyFallback.at.
**How found:** Read JumpyFallback.at and noticed cursor starts at 1<<splits while the tree array is declared with 1<<MAX_SPLITS elements; checked the boundary case splits=MAX_SPLITS=19 and confirmed the index 524288 exceeds the last valid index 524287.
**Insight:** When an array is sized 1<<N and code indexes it with 1<<k, the k=N boundary is off by one — always test the maximum allowed parameter value against array bounds, not just typical values.
