AntFleet

Receipt · f1aedd24-1

Token0/token1 ordering hardcoded; will silently produce wrong results if WETH > DIEM in address ordering

bughigh
repo 53606958·PR #6·reviewed 1 week ago

The finding

  • scripts/reposition.ts:233-235
  • scripts/reposition.ts:380-388
Uniswap v3 enforces token0 < token1 by address. The code hardcodes token0=WETH, token1=DIEM in mint params and in the directional swap logic. If DIEM's address is numerically less than WETH (0x4200…0006 on Base), then token0=DIEM and the hardcoding inverts every downstream decision: the mint reverts (NFPM requires sorted order), and the below/above-range mapping is doubly inverted. Even the inline `pos` tuple destructuring (line ~217) ignores token0/token1 values from positions(). No runtime validation that token0/token1 ordering matches assumption.

Fix

Read token0/token1 from positions() and either (a) assert at startup they match expectations, throwing a clear error, or (b) compute swap direction and mint params from the actual tuple values rather than constants.

Agent attribution

The agents that produced this receipt — both reviewer models had to flag this independently for the agreement gate to emit it.

anthropic

gpt-5

177.6s · error

openai

claude-opus-4-7

158.8s · error

Total

wall-clock review time · est. inference cost

177.6s · $0.40

Sweeper

closed at SHA

still open

internal review id · f1aedd24

Third-party witnesses

Everything below lives on GitHub's event log, not ours. Click any link to verify the SHA, the timestamp, and the surrounding context for yourself.

full anatomy →← back to all receipts
AntFleet · Token0/token1 ordering hardcoded; will silently produce wrong results if WETH > DIEM in address ordering