Uniswap v4 Deep Dive: Hooks, Singleton Architecture, and Custom Pools

Why Uniswap v4 Is a Paradigm Shift

Every previous Uniswap version deployed a new factory and pool contracts. v1 had one pair type. v2 introduced token-to-token pairs. v3 added concentrated liquidity with multiple fee tiers — but still deployed a new pool contract for each pair/fee combination. By 2025, hundreds of thousands of individual Uniswap v3 pool contracts existed on Ethereum and L2s.

Uniswap v4 changes the fundamental architecture. Instead of many pool contracts, there is one — the PoolManager singleton. All pools live inside a single contract. This eliminates cross-pool approval overhead, enables direct pool-to-pool swaps without token transfers, and reduces deployment gas costs by 99%.

More importantly, v4 introduces hooks: arbitrary logic that developers can attach to pool lifecycle events. Before a swap, after a swap, before adding liquidity, after removing liquidity — hooks execute at each of these points. This turns every Uniswap pool into a programmable primitive.

The combination of a singleton architecture, hooks, and flash accounting creates a platform where anyone can build custom AMM logic without forking Uniswap's core.

The Singleton PoolManager and Flash Accounting

The PoolManager is the single contract that manages all v4 pools. Every pool is identified by a PoolKey struct: token0, token1, fee, tickSpacing, and hooks (the hook contract address).

Flash accounting is the accounting model that makes the singleton possible. Instead of transferring tokens between pools during a swap, the PoolManager tracks balance deltas — who owes how much to whom. Actual ERC-20 transfers only occur at the end of the transaction when all deltas are settled.

This has profound implications:
Multi-hop swaps across many pools execute without any intermediate token transfers. Gas cost scales with the number of pools visited, not with token transfer overhead.
Flash operations are native: you can take a loan from the PoolManager's balance within a transaction, perform operations, and repay — without needing a separate flash loan protocol.
Arbitrary logic can execute between the debit and settlement: all operations within a v4 transaction are atomic.

The unlock/settle pattern: a transaction begins with poolManager.unlock(data), which calls back into the caller's unlockCallback(data). Inside the callback, you execute swaps, add/remove liquidity, and take/settle token deltas. When the callback returns, the PoolManager verifies that all deltas are zero (everything has been settled).

Hooks: Lifecycle and Architecture

Hooks are contracts that implement callback functions called by the PoolManager at specific points in pool operations. The hook address is part of the PoolKey — every pool has exactly one hook (or no hook, using address(0)).

Hook callbacks:
beforeInitialize / afterInitialize — called when a pool is created.
beforeAddLiquidity / afterAddLiquidity — called when LP positions are created or increased.
beforeRemoveLiquidity / afterRemoveLiquidity — called when liquidity is withdrawn.
beforeSwap / afterSwap — called around every swap.
beforeDonate / afterDonate — called around donations (one-sided liquidity additions).

Which callbacks a hook implements is determined by a permission bitmap encoded in the hook's contract address. The PoolManager inspects specific bits of the hook address to determine which callbacks are implemented. This is enforced by requiring hook contracts to be deployed at addresses with specific bit patterns — achieved via CREATE2 mining.

The afterSwap callback receives a delta parameter: the difference between expected and actual swap output. Hooks can return a fee modifier here, effectively implementing dynamic fee logic. A hook can increase or decrease fees based on volatility, time of day, volume, or any other on-chain or committed oracle data.

Building a Custom Hook

Building a hook requires implementing the IHooks interface and deploying at an address that encodes the correct permissions.

A simple TWAP oracle hook as an example:
The hook stores a cumulative price sum in beforeSwap or afterSwap. It updates the sum with each swap and records the timestamp. Callers can compute a time-weighted average price over any window by querying the cumulative values at two timestamps.

Permission mining: use the Hookmine tool from OpenZeppelin or Hookfactory scripts to mine a salt that produces a CREATE2 address with the correct permission bits. This can take seconds to minutes depending on how many permissions you need.

The BaseHook abstract contract from v4-periphery provides default no-op implementations of all callbacks. Extend it and override only the callbacks you need.

Security considerations unique to hooks:
Hooks run inside the PoolManager's execution context. A malicious or buggy hook can manipulate swap amounts, prevent liquidity provision, or drain pool liquidity. Users should only interact with pools whose hook contracts have been audited.
The hook cannot rug liquidity from the pool directly — the PoolManager's invariant checking prevents it. But a hook can make a pool unusable or extract value through price manipulation.

Custom Pools and the v4 Ecosystem

Beyond simple fee hooks, v4 enables entirely new AMM designs:

Dynamic fees: adjust the swap fee based on realized volatility, pool imbalance, or oracle data. A hook that increases fees when volatility spikes reduces LP impermanent loss.

Limit orders: a beforeSwap hook that checks whether any limit orders should be filled at the current price. Limit orders are stored in the hook's state and settled when price crosses the specified level.

Range orders and TWAP execution: break large orders into many smaller ones executed over time, with the hook enforcing the execution schedule.

MEV-resistant designs: a hook implementing a commit-reveal scheme for swaps, or a hook that requires a minimum time between commitment and execution, can reduce sandwich attack profitability.

The v4 ecosystem of hooks is growing rapidly. Platforms like Doppler (liquidity bootstrapping hooks), Arrakis v2, and dozens of research projects are building on v4's programmable liquidity model. For DeFi developers, understanding v4 deeply is understanding the future of on-chain liquidity.