Opus finding
Build-mode allocation comment contradicts code: ‘below/above range’ swap direction is inverted relative to stated token0/token1 mapping
criticalbughigh
- scripts/reposition.ts:233-244
- scripts/reposition.ts:305-322
In Uniswap v3, when the current price (tick) is below the position's tickLower, the position is composed entirely of token1 (the higher-priced asset in the range, which Uniswap stores by sorted address). The code asserts token0=WETH and token1=DIEM, but on Base the canonical WETH (0x4200…0006) and DIEM token addresses determine sorting — the comment hardcodes an assumption that may be wrong, and even if token0=WETH/token1=DIEM, Uniswap v3 mechanics say: below-range position holds all token0 (not token1), and above-range holds all token1. The code/comment has this inverted. If currentTick < tickLower, the position is 100% token0 = WETH (not DIEM), so trying to swap diemBal/2 → WETH will fail or do nothing because there is no DIEM, and the mint will be single-sided WETH. The same inversion applies above range. This will cause mints to be near single-sided (poor capital efficiency) or revert on slippage, and on a live run will misallocate funds.
Recommendation
Correct the Uniswap v3 invariant: below range (tick < tickLower) → position is 100% token0 → if token0=WETH, swap 50% WETH→DIEM. Above range → 100% token1 → if token1=DIEM, swap 50% DIEM→WETH. Also verify token0/token1 ordering dynamically from the NFPM positions() result (already fetched in `pos`) rather than hardcoding.