LibraryMarkets2023Design paperCorpus record
Uniswap v4 Core
Uniswap v4. Hayden Adams and the Uniswap v4 authors.
One contract holds many pools. Hooks are code that runs before and after swaps and liquidity changes. Flash accounting settles balances at the end of a lock. A hook can change the rules v3 users took for granted.
Uniswap v4 puts many pools inside one contract and lets a hook run around swaps and liquidity changes. Balances are settled at the end of a lock. The hook, not the singleton, decides whether the pool still behaves like v3.
The five-minute read
Singleton is an accounting move
One PoolManager holds the state. Hopping pools does not require a token transfer on every hop because debts are tallied and netted. That saves gas. It does not, by itself, change the curve.
Hooks are the market
A pool can point at code that runs before or after a swap, a liquidity change, or a donation. Dynamic fees, limit-order behaviour, oracles, and access control all live there. So do rug pulls, if the hook can change the rules.
Flash accounting must net
Inside a lock, a caller can owe tokens. The lock cannot end in debt. That is what makes the singleton safe to share. A hook that breaks the lock's accounting breaks every pool that shares the manager.
v3 is not the default
A hookless pool can resemble concentrated liquidity. A hooked pool can be something else entirely. Reading the v3 paper and assuming it applies is the mistake v4 makes easy.
One action, walked through
- A developer deploys or selects a hook and initialises a pool in the manager.
- A liquidity provider adds liquidity. The hook may run, and may take a cut or refuse.
- A swapper calls the manager. Before and after the curve moves, the hook may run.
- Token debts are recorded inside the lock rather than transferred immediately.
- The lock settles. Every debt must be paid or the transaction reverts.
The argument, unpacked
Customisation moved risk into unaudited code
v2 and v3 were one invariant, readable once. v4 is a platform. The safety of a pool is the safety of its hook plus the manager. A frontend that shows only a fee tier is hiding the object the user is actually using.
Upgrade rights are a hook property
The manager's code and the hook's admin are separate questions. An immutable manager with an upgradeable hook is not an immutable pool. The paper's architecture allows both. The deployment has to say which.
What has to be true
- The lock's settlement is enforced by the manager and cannot be bypassed by the hook.
- Hooks declare their permissions honestly. A hook with a permission it should not have is an application bug users will not see in the fee tier.
- Integrators read pool state including the hook address, not only the two tokens.
- Native-currency accounting does not break the debt netting. That is an implementation invariant, not a slogan about ETH.
What happened after the paper
v4 is a later design than the v2 and v3 papers already in this library. Deployments, hook libraries, and fee switches moved after the whitepaper. A pool's hook can implement a TWAMM or something that only looks like one. Cite v4 for the singleton, the lock, and the hook permissions. Cite the hook's own code for the market you are actually in.
What to check before you use the idea
- What is the hook address, and what permissions does it have?
- Can the hook or its admin be replaced?
- Does the pool's curve match v3, or has the hook changed it?
- Can a lock end with unpaid debt?
Terms
- Hook
- Code the pool manager calls around swaps and liquidity changes. It can alter the rules of that pool.
- Flash accounting
- Recording debts inside a lock and requiring them to net to zero before the lock ends.
The problem the paper names
v3 deployed a new contract per pool and could not express limit orders, dynamic fees, or an on-chain TWAMM without a new protocol. v4 puts the variation in a hook, and the shared state in a singleton.
What the design proposes
- A PoolManager singleton.
- Hooks with permissions for initialize, swap, liquidity, and donate.
- Flash accounting: debts inside a lock must net to zero before the lock ends.
How the mechanism is specified
- The singleton reduces the cost of moving through several pools because tokens are not transferred on every hop.
- A hook sees the swap and can alter amounts, charge a fee, or refuse a caller. The hook's code is the market structure.
- Native currency can sit in the manager. That is an accounting change, not a new asset.
What this page does not treat as proven
- A pool with a hook is not the v3 invariant. Read the hook or you do not know the product.
- Hooks can be upgraded if their own admin allows it. Immutability is a property of that hook, not of the word v4.
- This is not a recommendation to provide liquidity, and not a description of every pool deployed under the name.
Why a venture studio still reads it
Ask which hook address is on the pool, what it is allowed to change, and who can replace it. The singleton is the boring part. The hook is the market.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.