Uniswap v4 Hooks

What it is

Uniswap v4 hooks are external smart contracts that a liquidity pool can call at specific points in its lifecycle — before or after a swap, before or after liquidity is added or removed, and at pool creation. Instead of every pool running identical, fixed logic, a pool creator attaches a hook contract that injects custom behavior, turning the AMM into a programmable base layer rather than a single fixed product.

How it works

1. When creating a pool, the deployer specifies a hook contract address; the pool's core logic will call into that contract at defined checkpoints (e.g., beforeSwap, afterSwap, beforeAddLiquidity).
2. The hook contract implements only the checkpoints it cares about — for instance, a hook might only need beforeSwap to adjust the effective price before the trade executes.
3. On every relevant action, the core pool contract pauses its default flow, calls the hook, and lets the hook return data or perform side effects (such as charging a custom fee, checking an allowlist, or updating a separate accounting ledger) before the pool resumes.
4. Because hooks can read pool state and return modified parameters, they can implement dynamic fees (fees that change with volatility), on-chain limit orders, custom oracles, MEV redistribution, or automated liquidity rebalancing — all without modifying the core AMM contract itself.
5. Which checkpoints a hook uses is encoded in the hook's contract address itself (via specific bit flags), so the pool knows at a glance which callbacks to invoke, avoiding wasted gas on unused hooks.
6. Because all pools share one underlying "singleton" contract in this design, creating a new hooked pool is cheap, and hooks can be reused across many pools like plug-ins.

Why designers use it

• Lets builders customize AMM behavior (dynamic fees, custom curves, order types) without deploying and bootstrapping an entirely new AMM from scratch.
• Concentrates innovation at the hook layer, so the audited core pool logic stays untouched and shared across the ecosystem.
• Enables genuinely new mechanisms — like time-weighted average pricing controls, auction-based launches, or MEV capture for LPs — that weren't expressible in earlier, fixed-logic AMMs.

Failure modes

• A buggy or malicious hook can misprice trades, block withdrawals, or drain funds, and because hooks are arbitrary code, each one needs independent security review — the core protocol's audit doesn't cover them.
• Hooks that call external contracts or oracles introduce classic reentrancy and stale-price risks that hadn't existed in the simpler, self-contained core AMM.
• Composability is fragile: a hook designed for one use case can behave unexpectedly when combined with unrelated integrations built on top of the pool.
• Because hook logic can change what a swap effectively costs or whether it succeeds, front-end and aggregator assumptions built for vanilla pools can silently break against hooked pools.

What to check before using it

• Read (or get audited) the specific hook contract's code — don't assume core-protocol security guarantees extend to it.
• Check which callback points the hook actually implements and confirm they match its advertised behavior.
• Test how the hook behaves under edge cases: zero liquidity, extreme volatility, or repeated rapid calls.
• Verify whether the hook has any admin/upgrade keys that could change its behavior after you've already integrated with it.