When a market lives in a smart contract, each trading pair used to get its own deployed copy. Extra behavior around a fill then meant paying to copy that machine again, and a route that touched two pairs moved tokens at every hop.
Those extra deploys and those extra transfers made custom logic expensive to attach. Two pairs can show the same two symbols and still run different extra code, or a hop can fail because a transfer at one step reverted while the next pool already moved.
A later automated-market design stores many pools as records inside one shared contract, and a pool can attach extra code when it is created. Internal balances net until the call ends, so a multi-hop route can settle as one set of transfers.
Uniswap v4 is that design: PoolManager holds the pools, and a hook is the extra code a pool opted into at create time. BloFin lists UNI as UNI/USDT spot and as UNIUSDT and UNIUSD perpetuals, which are venue books, separate from a PoolManager call.
One PoolManager holds every v4 pool as state
v4 stores every pool as records inside a single contract called PoolManager, instead of giving each pair its own deployed pool contract, so creating a pool is a state write on that one contract. An ETH/USDC pool and a UNI/USDC pool can sit in the same manager, with different keys, skipping a second factory deploy.
Uniswap Docs describe PoolManager as a single entry point for all liquidity pools, with pool state and logic held inside that contract (source: Uniswap Docs, PoolManager).
On v2 and v3, a new pair usually meant a new contract, and gas scaled with that deploy. The v4 whitepaper says the singleton makes pool deployment 99 percent cheaper than the factory pattern, and it brings native ETH back into trading pairs (source: Uniswap v4 Core whitepaper). Cheaper create is why hooked variants can multiply while skipping a new bytecode copy per pair, though the swap still costs gas. Some v4 pools can hold ETH as ETH, skipping the wrap that older versions used for ETH pairs, and a UI that still shows "ETH" may be a native pair or a wrapped reserve, so count what the pool actually stores.
| v2 and v3 | v4 | |
|---|---|---|
| Where the pool lives | Its own contract | State inside PoolManager |
| Starting a pool | Deploy that contract | Write the pool into the manager |
| Extra logic on the swap | None on the core pair | Optional hook, chosen at create |
The manager still prices from pool state. v4 keeps concentrated liquidity, so an LP can still sit in a range, the same idea as concentrated liquidity on Uniswap v3, and the singleton is how those ranges are stored while the curve itself stays the pricing engine.
A pool key is more than two tickers, because fee, tick spacing, and the hook address are part of what makes one v4 pool distinct from another. You can see two ETH/USDC labels that look alike on a UI and still be looking at two pools, because one attached a hook and the other stayed hookless, so same symbols are still different state.
PoolManager is a smart contract on a chain, and ETH still pays gas for the call even when the pool holds USDC and UNI. The manager is separate from Uniswap Labs' website and separate from UNI in a wallet, even though Labs can ship an app that talks to PoolManager, because the pools live in the contract.
You skip an app-store update that overwrites v3. A router may send you into a v4 pool today and a v3 pool tomorrow, so read the pool, because the singleton only describes pools that were created as v4.
The fill is still tokens in and tokens out, the same pool idea as how Uniswap works, and what changed is storage and the optional extra call.
A hook is extra code that pool calls around the swap
A hook is a separate contract that a v4 pool can attach when it is created. The PoolManager calls it at set points, such as before or after a swap, or when liquidity is added or removed. It is extra code on that pool.
Uniswap Docs define hooks as external smart contracts attached to individual pools. Every pool can have one hook, and one hook can serve many pools, intercepting and modifying the flow at specific points during pool-related actions (source: Uniswap Docs, Uniswap v4 Hooks).
Suppose you send 400 USDC into a hooked ETH pool. The manager checks the pool, then it may call beforeSwap on the hook, then it moves the pool's balances and takes the swap fee, then it may call afterSwap. If that hook reverts, the whole swap fails and you keep the starting balances, minus gas, because the callback is part of the same transaction as the swap.
Labs' holder page calls hooks smart-contract plugins and lists uses such as a time-weighted average market maker, dynamic fees, and onchain limit orders. Uniswap Labs dated the v4 launch post January 31, 2025, and wrote that v4 does this through modular plugins that allow developers to build custom logic for pools, swaps, fees, and LP positions (source: Uniswap Blog, Uniswap v4 is Here). Those are examples of what a hook may implement, a catalog of possibilities, and they stay separate from a coding lesson.
A pool can also stay hookless, and the manager still holds that pool as v4 storage that simply skipped extra calls. Treat a v4 label as storage layout, and treat extra code as a per-pool fact you still have to read.
The hook is chosen at create and is part of the pool's identity, so someone later attaching a different hook means a new pool even if the two tokens match. If a UI shows a warning about a hook, that is a pool fact.
How to write that Solidity stays off this page. The holder need is to know that extra code can run, that it is local to that pool, and that token debts wait until the lock ends.
Flash accounting nets token debts until the lock ends
On older Uniswap versions, a hop often moved tokens between pool contracts as the route went. v4 keeps an internal net, called a delta, and only moves tokens when that net is settled at the end of the lock. You can cross two v4 pools in one call and still see one set of transfers at the end.
Uniswap Docs describe flash accounting this way: each balance-changing operation, such as a swap or a liquidity change, updates an internal net balance known as delta, and only the final balance changes require token transfers (source: Uniswap Docs, Flash Accounting).
The lock is the window while PoolManager is allowed to change pool state for that call, and during it the manager tracks what you owe and what the pools owe you. At the end, those debts must net to zero or the call reverts, which is why a half-finished hop leaves the manager solvent: the revert unwinds the lock. It is accounting, and it is separate from UNI staking.
Suppose a 400 USDC hop is meant to buy ETH, then a slice of that ETH is meant to buy UNI, all inside v4. The first pool's delta credits you ETH and debits USDC, while the second pool's delta credits you UNI and debits ETH. If the ETH legs cancel, the manager may only need USDC in and UNI out at the end, so intermediate ETH can stay inside the lock.
The call still settles on a chain. On Ethereum, ETH pays gas for that call even when the deltas are USDC and UNI, and a revert at the end of the lock still spends gas. How Ethereum works is the chain picture, so flash accounting leaves that fee in place and a BloFin book leaves that call unsent.
Flash accounting is why hooks can do extra work in the same call while skipping a token transfer at every step, and it is also why a hook that breaks the net can fail the whole lock.
A hook can fail or drain the pool that uses it
A hook is extra code a pool opted into, so if that code reverts, your swap reverts with it. If that code is written to take tokens, skim fees, or block withdrawals, the damage is on the pools that attached it. It is a per-hook fact.
Uniswap Labs' support page states that hooks are developed by independent third-party developers who are unaffiliated with Uniswap Labs. It tells you to exercise caution when adding hooks, because some may be malicious or cause unintended consequences (source: Uniswap Labs, What is a hook on Uniswap v4?).
Pool-local means the caution follows the hook address. You can swap in a hookless v4 pool on the same chain as a hooked pool and face different extra code, and a second pool that reused the same hook inherits that hook's behavior, so reading the pair symbols still leaves the hook unread.
A hook can also fail as ordinary code failure, because it can run out of gas, reject a size, or refuse a wallet. From your seat the fill just stays unconfirmed, and you can still pay gas for the failed call, while a confirmed swap is the one that settled. A revert leaves PoolManager empty of a partial ETH credit sitting in the lock.
The core manager and a hook are different contracts, so a numeric safety grade would be a different page: size the extra code, then size the pool.
Liquidity you add to a hooked pool is inventory that hook can see at the callback points. Uniswap liquidity pools is the share and fee picture. The extra risk on v4 is whether that pool's hook is code you actually meant to trust. If you skip reading the hook, you are trusting someone else's plugin on your size.
v2 and v3 pools still fill after v4
v4 left the older pools running, so a v2 pair and a v3 range pool can still quote and fill. v4 adds a storage layout and optional hooks. It is an added architecture, and it is separate from UniswapX.
Uniswap Labs published the v4-is-here post on January 31, 2025, which is a live date for v4. Dated release history sits in Uniswap history and versions. The holder picture is a stack: older contracts can keep running while new pools are created on PoolManager.
v3's concentrated ranges still exist inside v4, so an LP can still pick a band. What v4 added around that band is the singleton, flash accounting, and the hook. A pool still sets a price from reserves, and v4 adds how that pool is stored and what extra code may run.
Protocol fees are a separate switch from hooks, and Tally proposal 100 is executed. Its adopted text is to activate protocol fees on a subset of v4 pools on Ethereum, Arbitrum, Base, BNB Chain, Polygon, Optimism, and Robinhood Chain, rather than on every v4 pool everywhere (source: Uniswap Foundation vote, Activate v4 Protocol Fees (Part 1/2)). A v4 badge still leaves the protocol-fee setting as a pool-and-chain check. Holders of UNI still have no pro-rata claim on that fee as a wallet dividend.
A router can hop v3 then v4 in one user flow, and your screen may still say Uniswap even while the contracts underneath are mixed. If you care which extra code ran, you care which v4 pool, and whether it had a hook.
Uniswap is also a competing decentralized exchange (DEX) next to BloFin. What Uniswap is is the name split, so keep v4 on the singleton and the hook.
Matching a v4 pool to the product you actually used
A v4 pool is PoolManager state plus an optional hook. Match the confirmation to the product.
How to buy UNI is the purchase walk, including venue clicks.
UniswapX is a separate intent and auction protocol: you sign an order and fillers compete. That signed order is separate from a v4 hook, and it is separate from a fourth AMM version. A filler may use a Uniswap pool as inventory, and the signed order is still separate from the singleton.
A generic primer on how automated market makers (AMMs) work is the category picture, and v4 is Uniswap's current AMM architecture.
BloFin has listed UNI/USDT on spot since January 15, 2024. BloFin lists two UNI perpetuals: UNIUSDT at up to 75x, listed January 12, 2023, and UNIUSD, an inverse contract settled in UNI, at up to 20x, listed June 27, 2025. Those listings are venue books, so a fill there will leave your hook callback off an explorer.
You can still hold UNI on BloFin and skip PoolManager, which is a listing fact. It leaves v4 storage as a chain call you take only when you actually swap in a v4 pool.
Frequently asked questions
If two v4 pools both hold ETH and USDC, which one did my swap use?
A v4 pool is identified by the two tokens plus fee, tick spacing, and the hook address, so two ETH/USDC pools can sit in the same PoolManager and still be different state. Your 400 USDC went into whichever pool the router called. Read the pool key. If one pool has a hook and the other stays hookless, extra code ran on only one of them.
Can one hook serve my pool and another pool at the same time?
Yes. Every v4 pool can attach one hook, and that hook can serve many pools. If your ETH/USDC pool and another pair point at the same hook address, they share that extra code. A pause, a fee skim, or a revert in the hook then hits every attached pool, so isolation is the hook address: read the hook, then read the pool.
If I hop a v3 pool then a v4 pool, does flash accounting cover both hops?
Flash accounting is PoolManager's internal net for v4 legs, while a v3 pool is a separate contract and still moves tokens the v3 way. The v4 hops can net inside the manager, and the v3 hop settles on that pair, so a mixed-version route is two settlement styles in one user flow. Read each hop, because a single UI quote can hide that mix, and size the v3 leg as its own transfer.
If PoolManager holds every v4 pool, can a hooked pool drain my other v4 pool?
Pools are separate state inside the manager. A hook on one pool stays limited to the pools that attached it, even though they share a contract. The singleton is shared storage, with each pool's reserves kept as their own records, and a bug in PoolManager itself would be a different, core-level failure. Hook risk stays with the pools that opted into that hook, so check the hook on the pool you are actually using.
If the UI shows ETH, is v4 wrapping it to WETH the way v2 often did?
v4 can hold native ETH in a pair, so some pools skip the wrap that v2 used for ETH pairs, while other v4 pools still use WETH. The button label is the UI word. If you are trying to know what the pool stores, read the two currencies on the pool. Native ETH is a v4 accounting choice, and it stays ETH in that pair.
How do I tell if Tally 100 protocol fees apply to this v4 pool?
Proposal 100 turned v4 protocol fees on for a subset of pools on listed chains. A hooked pool can have a protocol fee, a hook fee, both, or neither. Check the pool family and the chain the contract sits on, then treat the setting as current governance state. A v4 badge in a UI still leaves that check to you.
How can I tell on an explorer whether a fill hit PoolManager?
Look at the contract that moved the tokens. A v4 swap talks to PoolManager, and it may call a hook, while a BloFin UNIUSDT close stays on the venue ledger. Internal venue transfers, a different chain, or a wrap-only transaction are also separate from a hooked pool fill. If the explorer shows PoolManager, extra Uniswap v4 code may have run, so match the transaction to the product you actually used.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Updated September 2026. Primary sources include the Uniswap v4 Core whitepaper, Uniswap v4 PoolManager and hooks docs, and Tally proposal 100. All facts independently verified against cited documentation current as of September 2026.
This article is educational and general in nature, not financial or investment advice. Cryptocurrencies like UNI carry real risks, including price volatility, venue risk, smart-contract exploits in ecosystem apps, and hook-level failures on v4 pools that opt into extra code. Nothing here is a recommendation to buy, sell, hold, or participate in any project. Do your own research, and consider speaking with a licensed professional before making financial decisions. BloFin does not provide investment advice.