Uniswap v4 Hooks: Seven Failure Patterns and 20M+ Loss Lessons

Uniswap v4 hooks let developers add custom logic for swaps and liquidity, including dynamic fees and custom accounting. A new Trail of Bits post argues that the Uniswap v4 PoolManager can enforce settlement invariants, but many real losses come from application-specific errors inside Uniswap v4 hooks rather than protocol flaws. The article highlights two app-level incidents—Cork (~$12M, May 2025) and Bunni (~$8.4M, September 2025)—totaling over $20M in losses. Both incidents stemmed from authorization and accounting logic around hooks, not from PoolManager or core Uniswap v4. Based on audits (including Trail of Bits work) and public findings, the post lists seven recurring failure patterns in Uniswap v4 hooks: 1) Missing caller checks (attackers call callbacks directly). 2) Treating any pool as legitimate (insufficient PoolKey/pool allowlisting). 3) Custom accounting leaks value (wrong delta sign/rounding; “NoOp swap” edge cases; fee manipulation). 4) Right logic, wrong hook timing (beforeSwap vs afterSwap or liquidity callback state). 5) Address permission bits are part of the API (mismatches break settlement or silently drop deltas), including proxy-upgrade risk. 6) Hook failures can block pool actions (reverts in after* callbacks, dependency outages). 7) State can change during a callback sequence (nested swaps/liquidity mutate shared hook storage). For builders, it provides a practical checklist (use BaseHook/SafeCallback, pool allowlists, balance/delta labeling, isolate callback state, fuzz adversarial cases). For auditors, it suggests targeted questions around access control, PoolKey validation, accounting invariants, revert paths, permission-bit alignment, and nested-state effects on shared hooks.