How Uniswap v4 Hooks Work: Custom Logic Plugged Into Every Swap

This article explains hooks, the defining feature of Uniswap v4. Hooks let anyone attach custom code to a liquidity pool so that specific logic runs automatically before or after every swap, deposit, or withdrawal. This matters because it turns Uniswap from a single exchange design into a platform where thousands of pool variants can coexist — each with different fee structures, oracle behavior, or access rules — all sharing the same core infrastructure.

Uniswap v2 and v3 are automated market makers — protocols where users trade tokens against pooled liquidity rather than matching with another trader. Every pool in v3 works the same way: a fixed 0.3%, 0.05%, or 1% fee, the same price curve math, the same rules for everyone. If you wanted different behavior — say, a dynamic fee that adjusts to volatility — you couldn't modify Uniswap. You had to build an entirely separate protocol.

• Every v3 pool uses identical logic — same fee tiers, same swap math, same oracle design
• Developers who wanted custom behavior forked Uniswap's entire codebase, fragmenting liquidity across competing deployments
• Liquidity fragmentation means worse prices for traders, because the same token pair's liquidity is split across disconnected pools
• v4's design goal was to let customization happen inside Uniswap instead of alongside it

What this means practically: Hooks exist because the alternative — everyone forking Uniswap to change one thing — was making DeFi worse for traders.

A hook is a separate smart contract (a program deployed on Ethereum) that a pool creator attaches to a specific pool at creation time. Once attached, the hook cannot be changed — it's permanent for that pool. The hook contains custom logic that Uniswap's core contract calls at defined moments during a transaction. Think of it as a callback: Uniswap says "I'm about to execute this swap" and the hook contract gets a chance to run code before it happens, after it happens, or both.

• A hook is a standalone smart contract with an address that encodes which callback points it uses
• Each pool gets exactly one hook (or no hook). The hook is set at pool creation and is immutable after that
• The hook doesn't replace Uniswap's swap logic — it wraps around it, executing at specific moments
• Hooks can read transaction data (token amounts, prices, the trader's address) and act on it
• A hook can modify fees, block certain transactions, update external contracts, or redistribute funds — the design space is open-ended

What this means practically: A hook is not a plugin you install. It's a permanent piece of a pool's identity, as fundamental as which two tokens the pool trades.

Uniswap v4 defines specific callback points — moments in a swap or liquidity action where the core contract pauses and calls the hook. There are eight primary callback points, organized in before/after pairs across four actions.

1. beforeSwap runs before the swap executes. The hook can inspect the trade, modify the fee, or revert the transaction entirely. This must run first because any fee adjustment needs to be set before the swap math calculates output amounts.

2. afterSwap runs after the swap completes. The hook sees the final amounts and can trigger side effects — logging data to an oracle, distributing rewards, or rebalancing external positions. This comes second because it needs the swap's actual results.

3. beforeAddLiquidity / afterAddLiquidity run around deposit actions. A hook could restrict who provides liquidity or apply a time-lock on new positions.

4. beforeRemoveLiquidity / afterRemoveLiquidity run around withdrawals. A hook could impose withdrawal fees or cooldown periods.

5. beforeDonate / afterDonate run around the donate function, which lets anyone tip liquidity providers in a pool directly. These are less commonly discussed but enable reward-distribution mechanisms.

What this means practically: Hooks don't get arbitrary access to Uniswap's internals. They get clearly defined entry points — which limits what can go wrong while still enabling a wide range of custom behavior.

The callback system is general enough that hooks can implement features that previously required entirely separate protocols. Several categories have already emerged from teams building on v4.

• Dynamic fees — a hook adjusts the swap fee based on market volatility, time of day, or pool utilization, rather than using a fixed percentage
• On-chain limit orders — a beforeSwap hook can match trades at specific prices, mimicking order-book behavior inside an AMM pool
• TWAP oracles — a hook that logs prices in afterSwap can build a time-weighted average price oracle directly into the pool, replacing the v3 oracle system that was removed in v4
• KYC-gated pools — a beforeSwap hook checks the trader's address against an allowlist, enabling compliant pools for regulated assets
• MEV redistribution — hooks can capture some of the value that would otherwise go to MEV (maximal extractable value) searchers — bots that reorder transactions for profit — and return it to liquidity providers or traders

What this means practically: Hooks turn Uniswap into a platform. Instead of one pool design, there can be thousands, each optimized for a different use case, all drawing from the same shared liquidity infrastructure.

This is where most explanations go wrong — they describe hooks without explaining why they only work in v4. The answer is the singleton contract. In v3, every pool is its own separate smart contract. Creating a pool and routing between pools costs significant gas (the fee paid for Ethereum computation). In v4, every pool lives inside a single contract. This makes pool creation cheap, multi-pool swaps efficient, and — critically — makes the hook callback system practical.

• In v3, each pool is a standalone contract. In v4, all pools share one contract with a unified accounting system called flash accounting
• Flash accounting tracks net balances across an entire transaction, settling tokens only once at the end, which dramatically reduces gas costs
• Hooks add external contract calls to every swap, which would be prohibitively expensive under v3's architecture. The singleton design absorbs that overhead
• Pool creation in v4 costs a fraction of what v3 charged, which matters because hooks encourage creating many specialized pools

What this means practically: Hooks aren't just a feature bolted onto Uniswap. They required rearchitecting the entire protocol to make the gas math work.

Hooks are powerful, which means they're also dangerous. A malicious or buggy hook can steal funds, block withdrawals, or manipulate prices. Because each hook is an arbitrary smart contract, there is no automatic safety guarantee. Users need to evaluate hooks the same way they evaluate any DeFi protocol.

• Check whether the hook's source code is verified and audited — an unverified hook is a black box
• Understand which callback points the hook uses. A hook that only uses afterSwap for logging is far less risky than one using beforeSwap to modify fees
• Look at whether the hook has admin functions — can someone upgrade or change its behavior after deployment?
• Prefer hooks that have been reviewed by Uniswap's community or listed on curated registries (these are expected to develop as the ecosystem matures)
• A hook that reverts in beforeSwap or beforeRemoveLiquidity can freeze your funds by blocking withdrawals entirely

What this means practically: The pool's hook contract matters as much as the tokens in the pool. Before providing liquidity, read the hook's audit or understand exactly what it does.

• Hooks are smart contracts attached permanently to a Uniswap v4 pool, running custom logic at defined points before and after swaps and liquidity actions
• They exist to end liquidity fragmentation — letting developers customize pool behavior inside Uniswap rather than forking the entire protocol
• v4's singleton architecture makes hooks economically viable by reducing the gas cost of the external calls hooks require
• Hook safety is not guaranteed by Uniswap — each hook is an independent contract that users must evaluate before trusting with their funds