Uniswap V4 Hook

What it is

A hook is an external smart contract that a Uniswap V4 pool calls at specific points in its lifecycle — before or after a swap, before or after liquidity is added or removed, and so on. Instead of every pool running identical, fixed logic (as in earlier Uniswap versions), V4 lets pool creators attach a hook contract that injects custom behavior: dynamic fees, on-chain limit orders, custom oracles, MEV protection, or entirely new pool mechanics. It turns the AMM from a single fixed product into a programmable base layer.

How it works

1. A developer writes a hook contract implementing one or more of Uniswap V4's defined callback functions (e.g., beforeSwap, afterSwap, beforeAddLiquidity, afterAddLiquidity).
2. When a new pool is created, its address is paired with a specific hook contract address; the pool's behavior is now permanently tied to whatever logic that hook implements.
3. Uniswap V4 uses a clever addressing trick: certain bits in the hook contract's deployed address encode which callbacks it implements, so the core pool manager knows which hooks to invoke without extra storage lookups.
4. During a swap, the pool manager calls the hook's beforeSwap function (if implemented), which can modify parameters like the fee rate, reject the trade, or execute other logic (e.g., checking an off-chain price feed).
5. The swap executes against the pool's liquidity as usual, following the same constant-product math as other Uniswap pools (potentially now with a hook-adjusted fee).
6. After the swap, afterSwap (if implemented) can run further logic — for example, donating part of the swap output to a vault, updating a custom oracle, or triggering a limit-order fill.
7. Because all pools share the same underlying "singleton" contract architecture in V4, hooks can be deployed cheaply and pools created permissionlessly, each with entirely different economic rules layered on top of the same core AMM engine.

Why designers use it

• Lets builders add custom logic (dynamic fees, MEV capture, limit orders, custom curves) without forking or redeploying the entire AMM.
• Reduces gas costs and complexity compared to building a separate protocol on top of or beside Uniswap, since hooks plug directly into the core swap flow.
• Enables composability experiments — new mechanisms can be tested on real liquidity without needing to bootstrap a whole new exchange.
• Gives pool creators fine-grained control over trade-offs like fee structure, price impact, and access control that were previously fixed at the protocol level.

Failure modes

• Malicious or buggy hooks: since anyone can deploy a hook and attach it to a pool, an unaudited or intentionally malicious hook can manipulate fees, block withdrawals, or drain value from unsuspecting liquidity providers or traders.
• Composability risk: a hook interacting with an external contract (like an oracle or lending market) inherits that external contract's risks, and a failure there can cascade into the pool.
• False sense of standardization: because all V4 pools share the same core interface, users may assume similar safety guarantees across pools, when in reality each hook can implement wildly different (and unaudited) logic.
• Address-encoding bugs: since hook capabilities are encoded in the contract's deployed address, a mismatch between the address's declared permissions and the hook's actual implementation can cause unexpected reverts or, worse, silently skipped safety checks.
• Fragmented liquidity: an explosion of custom hook variants for similar pairs can fragment liquidity across many slightly different pools instead of concentrating it in one place.

What to check before using it

• Read (or get audited) the specific hook contract's code before providing liquidity or trading in a hook-enabled pool — don't assume hook pools are as battle-tested as vanilla Uniswap pools.
• Check which callbacks the hook implements and what each one actually does, especially beforeSwap/afterSwap logic that can alter price or fees.
• Verify whether the hook has any admin-controlled parameters or upgrade paths that could change pool behavior after you've deposited liquidity.
• Confirm the hook doesn't introduce external dependencies (oracles, other contracts) that add their own failure or manipulation risk.
• Compare liquidity depth in the hook-enabled pool against equivalent vanilla pools, since novel hooks may fragment liquidity and increase slippage.