Uniswap v4 Explained: Hooks, Singleton Design and Flash Accounting

Uniswap v4 is the fourth major version of Uniswap, a decentralised exchange built on an automated market maker (AMM). Instead of matching buyers and sellers in an order book, an AMM lets traders swap against pools of tokens supplied by liquidity providers (LPs), with prices set by a formula. v4 keeps the concentrated liquidity model from v3, where LPs pick a price range for their capital, but it changes the architecture around that model. The design was published in 2023, and the protocol went live on Ethereum and a number of other networks in early 2025.

Three ideas define the upgrade:

• Singleton contract. Every pool is stored inside one contract, the PoolManager, instead of each pool being its own deployed contract.
• Flash accounting. Token balances are tracked as running debts and credits during a transaction and settled once at the end.
• Hooks. Developers can attach custom contracts to a pool so it runs extra logic at set points in its life.

Smaller changes support these: native ETH can be used directly without wrapping, pool parameters such as fee and tick spacing are more flexible, and balances can be held inside the PoolManager as ERC-6909 tokens.

v4 does not remove earlier versions. Uniswap v2 and v3 contracts are immutable and stay deployed, so each version runs side by side with its own liquidity. For readers, the practical meaning is that v4 turns a fixed exchange into something closer to a platform on which many pool designs can exist, some good and some risky.

In Uniswap v2 and v3, a factory contract deploys a new contract for every pool. Each pair and fee tier therefore has its own address, its own token balances and its own code instance. That structure is simple, but creating a pool costs a lot of gas, and a swap routed through several pools has to move real tokens from contract to contract.

v4 replaces this with a singleton: one PoolManager contract holds the state for every pool. A pool is identified by a pool key made of five values:

1. The first currency (currency0)
2. The second currency (currency1)
3. The fee setting
4. The tick spacing
5. The hooks contract address (or none)

Change any of these and you have a different pool. That is why a pair with a hook and the same pair without one are separate pools with separate liquidity.

The singleton brings several benefits:

• Cheaper pool creation. Initialising a pool writes data to storage rather than deploying a contract.
• Cheaper multi-hop swaps. A route through three pools does not need token transfers between pools, because all of them sit in the same contract.
• One place for token custody. The PoolManager holds the tokens, which simplifies accounting but also concentrates value in a single contract.

That last point is a design trade-off. A single contract with a large balance is a high-value target, so its code and audits matter a great deal. Users do not interact with the PoolManager directly in most cases; they use periphery contracts such as routers and position managers that call it on their behalf.

The singleton alone would not save much gas if every swap still moved tokens in and out. Flash accounting is the mechanism that makes the saving real.

In v4, interacting with the PoolManager follows a pattern. A caller, usually a router, asks the PoolManager to open a session. Inside that session the caller can run many operations: swaps across several pools, liquidity changes, donations. The PoolManager does not transfer tokens after each step. It keeps a running tally of what the caller owes and is owed for each currency, called deltas. When the session closes, the PoolManager checks that every delta is zero, meaning the caller has paid what it owes and taken what it is owed. If any balance is unsettled, the whole transaction reverts.

This relies on transient storage, introduced on Ethereum through EIP-1153 in the Cancun upgrade. Transient storage holds data only for the length of a transaction and is much cheaper than normal storage. The deltas live there and disappear when the transaction ends.

Practical effects:

• Multi-hop routes settle only the net input and output tokens, not each intermediate token.
• Composability improves. A single transaction can combine a swap, an LP adjustment and a fee collection, and settle once.
• Claim tokens. Instead of withdrawing tokens, a user can keep a balance inside the PoolManager as ERC-6909 claims, which saves transfers if they trade often.

The design depends on the chain supporting transient storage, which is one reason deployments are limited to networks that do.

A hook is a smart contract that you attach to a pool when you initialise it. The PoolManager then calls the hook at specific moments, giving the developer a way to add behaviour without forking the whole exchange.

The defined callback points are:

• Before and after pool initialisation
• Before and after adding liquidity
• Before and after removing liquidity
• Before and after a swap
• Before and after a donation (a way to send tokens directly to in-range LPs)

A hook does not need to use all of these. Which callbacks it uses is encoded in the hook contract's address itself: certain bits of the address act as permission flags. A developer therefore needs to deploy the hook at an address with the right pattern, which is usually done by mining a salt with CREATE2. The PoolManager reads those bits to know which functions to call, and it can verify the pool's behaviour from the address alone.

Some hooks go further and can return deltas, which lets them change the amounts in a swap or liquidity action. That allows custom accounting, for example charging an extra fee or replacing the usual pricing curve. Such powers are why hook code deserves careful review.

Two more points matter. A hook is fixed to a pool at creation, so you cannot swap it for another later, although a hook may itself be upgradeable or have an admin. And hooks run inside the same transaction as the swap, so a badly written hook can make a pool revert, cost extra gas or behave in unexpected ways.

Hooks matter because they let a pool behave differently from the default constant-product, fixed-fee design. Developers have proposed or built many categories. Which ones are live, and in what form, changes over time, so check current deployments rather than assuming any specific product exists.

Category	What the hook can do	Callback commonly used
Dynamic fees	Raise fees in volatile periods and lower them in calm ones	Before swap
Limit orders	Fill orders when the price crosses a level	After swap
Time-weighted orders	Spread a large trade over time	Before swap
Oracles	Record prices on chain for other contracts	Before or after swap
MEV protection	Redirect or reduce value lost to sandwiching	Before swap
LP management	Rebalance ranges or compound fees automatically	After swap, liquidity callbacks
Access control	Restrict a pool to approved users or tokens	Before swap, liquidity callbacks
Custom curves	Replace the standard pricing formula	Before swap with deltas

Note that v4 does not ship a built-in price oracle the way v2 and v3 did; oracle behaviour is something a hook can supply.

The common thread is that pool logic once requiring a separate protocol, or a fork of Uniswap, can now sit on top of Uniswap's existing infrastructure and routing. A hook developer can also benefit from the liquidity, tooling and interfaces that already support v4 pools.

The flip side is that every new pool design starts with little liquidity and little track record. A clever idea is not evidence that a pool is safe or profitable for LPs.

v4 gives pool creators more control over fees and spacing, and hooks can adjust fees over time.

Flexible fee settings. In v3, only a small set of fee tiers existed, set by governance. In v4, a pool creator can choose the fee and tick spacing when creating a pool, within protocol limits. Tick spacing controls how finely LPs can choose price ranges; smaller spacing allows tighter ranges but can mean more computation when swaps cross ticks.

Dynamic fees. A pool can be flagged as using a dynamic fee. A hook then sets or overrides the fee, either at intervals or on each swap. Hooks could base the fee on recent volatility, trading volume, time of day or other inputs. For LPs, the aim is better compensation for risk. For traders, the effect is that the cost of trading in the same pair can differ between pools and over time.

Hook fees and protocol fees. Hooks that take deltas can charge their own fees on top of the pool fee, and the protocol has a separate protocol fee mechanism that governance can control. Whether any protocol fee is active, and at what level, is a governance matter that can change, so read it from current documentation rather than a guide.

What to check before trading or providing liquidity in a pool:

• Is the fee fixed or dynamic, and who controls the logic?
• Does the hook charge anything beyond the displayed fee?
• Can an admin change the settings after you deposit?

The interface should show the total cost estimate, but it may not reveal everything a custom hook does.

v4 builds on v3 rather than replacing its core idea. The table summarises the main differences in design.

Feature	Uniswap v3	Uniswap v4
Pool structure	One contract per pool	All pools in one PoolManager
Concentrated liquidity	Yes	Yes
Customisation	Fixed behaviour	Hooks at defined points
Fee tiers	Small set approved by governance	Flexible fee and tick spacing per pool
Dynamic fees	No	Yes, via hooks
Native ETH	Needs wrapping to WETH	Supported directly
Token movement in multi-hop	Between pool contracts	Net settlement at the end
Built-in oracle	Yes	No, a hook can provide it
LP positions	NFT from the position manager	NFT from a new position manager
Source license	Business Source License, later converted	Business Source License terms

On licensing, Uniswap's v3 and v4 core code has used the Business Source License, which allows reading and some use but restricts certain commercial copying for a set period before converting to a more open license. Check the repository for the current terms and change dates, since they are specific and can matter to builders.

For most users, the interface looks similar. You choose tokens, see a quote and sign. The difference is mostly in routing and which pools exist. Because liquidity is fragmented across v2, v3 and v4, aggregators and the Uniswap router compare them and pick the best route, which may include a v4 pool or not.

A hook is third-party code with potentially large powers. The core PoolManager has been audited, and the protocol has run security programmes such as a bug bounty, but those cover Uniswap's contracts. They do not cover each hook that anyone deploys. Anyone can create a pool with a hook, so you should treat unfamiliar pools as untrusted.

Key risks:

• Malicious or buggy hooks. A hook can take unexpected fees, block withdrawals, misprice swaps or fail in edge cases.
• Admin control. An upgradeable hook, or one with an owner who can change parameters, lets that owner alter the pool after you deposit.
• Token risk. Hooks do not make a bad token safe. Fee-on-transfer tokens, freezable tokens and honeypots remain dangerous.
• Impermanent loss. Concentrated liquidity amplifies price-movement losses for LPs, whatever the hook does.
• Liquidity fragmentation. More pool variants mean thinner liquidity and worse prices in many of them.
• Fake pools. Scammers can create pools with the same token symbols as real ones.

A defensive checklist before you commit funds:

1. Confirm the token addresses against the project's official sources.
2. Find the hook address and check whether its code is verified on a block explorer.
3. Look for independent audit reports and read what they cover.
4. Check whether the hook is upgradeable and who holds admin keys.
5. Start with a small test amount, and keep approvals limited.
6. Prefer pools with meaningful, long-standing liquidity over brand-new ones.

These steps reduce risk but do not remove it. Smart contract losses are usually unrecoverable.

Using v4 through the main interface is similar to earlier versions, but a few habits help.

Swapping

1. Connect a wallet on a network where v4 is deployed.
2. Select the tokens and verify their contract addresses, not just the symbols.
3. Review the quote, price impact and route. Routes can include v2, v3 or v4 pools.
4. Set a slippage tolerance that suits the pair. Lower is safer, but trades may fail.
5. Check the approval request. Permit2-style approvals have limits and expiry, so avoid unlimited ones.
6. Confirm the transaction and check the result on a block explorer.

Providing liquidity

1. Choose a pool, noting the fee, tick spacing and whether it has a hook.
2. Pick a price range. Narrow ranges earn more fees while the price stays inside them, but go out of range more often and magnify impermanent loss.
3. Deposit both tokens as required by the range.
4. Receive a position NFT representing your liquidity.
5. Monitor the position, and remove or adjust it if the range no longer suits you.

Some users hand range management to automated tools or yield aggregators, such as vfat.io, which supports farming and position management across protocols. That adds another layer of smart contract and operational risk.

Whatever you do, this is not investment advice. Fees earned can be smaller than losses from price movement, gas costs apply on every action, and tax treatment of swaps and LP income depends on where you live.

Uniswap v4 sits in a wider DeFi stack. Other protocols can use v4 pools for pricing and swaps, and some products combine lending with exchange features. Fluid, for example, combines lending and a DEX on one liquidity layer, while Dolomite and Compound V3 are money markets where tokens swapped on a DEX are often used as collateral. Convex Finance builds around Curve liquidity rather than Uniswap, but shows how incentive layers form around AMM pools. Risk managers such as Gauntlet analyse DeFi parameters, which is the kind of work hook-based pools will increasingly need. Team Finance offers liquidity locks, which projects use to show LP tokens are not about to be withdrawn, though a lock does not guarantee a project is safe.

Several facts about v4 change over time and are better checked at the source:

• Supported networks and contract addresses: the official deployments page in the Uniswap documentation.
• Audit reports and bug bounty terms: the project's security documentation and repository.
• License terms and change dates: the license file in the repository.
• Protocol fee settings: Uniswap governance forums and the contracts' current state.
• Trading volume, liquidity and fees: public analytics dashboards and block explorers, not static articles.
• Notable hooks and their audits: the hook developers' own documentation and independent security reviews.

As a rule, when a pool or hook is new, treat popularity metrics with caution. Volume can be inflated, and a pool being listed in an interface does not mean anyone has vetted it.