Summary
| The WhitePaper Reading Club [04] | [28-June-2025] |
|---|---|
| Uniswap v4 | [Cheong Kian, ck :)] |
| https://app.uniswap.org/whitepaper-v4.pdf |
Summary
Uniswap: A decentralized exchange (DEX) that lets anyone trade cryptocurrencies directly from their wallet without a middleman.
Uniswap v4: The latest version of Uniswap that lets developers build more powerful and customizable trading features using "hooks" while lowering gas fees.
Why This Is Important
For Developers
- Build advanced DeFi features like limit orders, custom fees, or even new AMM models using hooks
- Save time and cost by using the singleton architecture (no need to deploy a new contract for every pool)
- Easier to experiment and innovate on-chain
For Traders
- Lower gas fees on swaps (especially multi-hop swaps)
- Trade with native ETH — no need to wrap/unwrap
- Future trading features (like stop-loss or time-based trades) could be built right into the protocol
For Liquidity Providers (LPs)
- More control over how liquidity is managed
- Possibility to earn more through custom fee models
- Participate in more flexible and dynamic liquidity strategies
For the DeFi Ecosystem
- Boosts innovation by making Uniswap a programmable DEX
- Encourages new types of DeFi apps and liquidity systems
- Improves overall user experience and efficiency in the Ethereum ecosystem
Key Innovation
Uniswap v4 is the latest upgrade to the Uniswap decentralized exchange protocol, designed to be more flexible, gas-efficient, and developer-friendly. Its biggest innovation is hooks — custom code that lets developers add new features like dynamic fees, limit orders, or custom trading logic directly into liquidity pools. It also introduces a singleton architecture, which manages all pools through a single contract to reduce gas and improve efficiency, and flash accounting, which settles token balances only once per transaction to cut costs. Together, these upgrades make Uniswap v4 a powerful, programmable platform for building the next generation of DeFi applications.
Glossary
- DEX – Decentralized Exchange
- AMM – Automated Market Maker
- Hooks – Plug-in smart contracts that run during Uniswap actions
- Singleton – One smart contract managing all pools
- Flash Accounting – A method to reduce gas by settling balances only once per transaction
- TWAMM – Time-Weighted Average Market Maker
- ERC-6909 – Efficient token accounting for LP positions
- PoolKey – Unique identifier for a v4 pool
Background
- Uses EIP-1153 for temporary storage to save gas
- Pools are no longer separate contracts — managed via one PoolManager
- Supports native ETH, no need to wrap into WETH
- Developers can create fully customized pool logic using hooks
Team
- Hayden Adams – Founder of Uniswap
- Noah Zinsmeister – Core Developer & Protocol Lead
- Uniswap Foundation – Supports research and governance
Opinion
Uniswap v4 introduces powerful tools like hooks, singleton architecture, and flash accounting that make the protocol more customizable and gas-efficient. These upgrades could redefine how DeFi protocols are built and extended. But with greater flexibility comes greater responsibility — poorly implemented hooks could introduce security and audit challenges. Still, if used wisely, v4 has the potential to become a foundational layer for a more innovative and composable DeFi future.
Components
Hooks
| Problem | In previous Uniswap versions (v2/v3), developers had limited control over how pools behave. They couldn't easily add features like dynamic fees, custom order types (like limit orders), or complex logic without forking and deploying a whole new version of Uniswap, which was inefficient, costly, and fragmented the ecosystem. |
|---|---|
| Solution | Uniswap v4 introduces Hooks — custom smart contracts that developers can plug into a pool's lifecycle. This makes it possible to add powerful new features without modifying the core protocol, enabling a more flexible, modular, and extensible DEX architecture. |
| How it works | Hooks are external smart contracts that conform to the IHook interface. They are linked to a pool at creation time and can define callbacks at key points in the pool's lifecycle: beforeInitialize()/afterInitialize(), beforeSwap()/afterSwap(), beforeModifyPosition()/afterModifyPosition(), beforeDonate()/afterDonate(). When a pool is interacted with (e.g., a swap or liquidity add), the Uniswap v4 core contract calls the relevant hook function, allowing custom logic like fee adjustment, external oracle access, TWAMM execution, or state updates. Hooks must be deterministic and gas-bounded to prevent unpredictable behavior. They can read/write custom storage, enabling deep pool customization without protocol changes. |
Singleton
| Problem | In Uniswap v2 and v3, every liquidity pool was deployed as a separate smart contract, which increased gas costs, made cross-pool operations like multi-hop swaps more expensive, and created unnecessary on-chain complexity. |
|---|---|
| Solution | Uniswap v4 introduces a singleton architecture, where all pools are managed under one single contract called the PoolManager. This drastically reduces deployment and interaction costs and simplifies the ecosystem structure. |
| How it works | Uniswap v4 implements a central PoolManager contract that uses non-ERC-20 "pool objects" to store and manage all liquidity pool data within one contract. Each pool is identified via a unique PoolKey (containing token0, token1, fee, hook address, etc.) and slot inside the PoolManager's storage. Instead of deploying a new smart contract per pool, the PoolManager uses function selectors and internal storage mappings to route all interactions (swap, mint, burn, etc.) through shared logic, with extremely low gas overhead for pool creation. This also simplifies multi-hop swaps since all logic stays inside one contract. |
Flash Accounting
| Problem | In Uniswap v2 and v3, token transfers happen immediately at every step of a swap or liquidity change. This results in repetitive and costly token transfers, increasing gas fees, especially in complex trades like multi-hop swaps. |
|---|---|
| Solution | Uniswap v4 introduces flash accounting, a system where token balances are tracked internally and only settled once per transaction, reducing redundant on-chain movements and gas costs. |
| How it works | Uniswap v4 introduces flash accounting by utilizing EIP-1153 transient storage opcodes (TSTORE/TLOAD), which are reset after a transaction ends. During swaps or liquidity changes, token amounts owed to or from the pool are tracked in temporary memory-like storage, instead of performing transfer() calls for each hop. At the end of the transaction, a single net settlement occurs between the user and the pool — minimizing ERC-20 calls and saving significant gas. This design enables complex multi-hop swaps and batch operations without redundant token transfers or approvals. |
Native ETH
| Problem | In Uniswap v2 and v3, users couldn't trade directly with ETH (Ethereum's native coin). Instead, they had to wrap it into WETH (Wrapped ETH), which added extra steps, gas costs, and a clunky user experience. |
|---|---|
| Solution | Uniswap v4 introduces native ETH support, allowing users to interact directly with ETH — no wrapping or unwrapping required. |
| How it works | Pools in Uniswap v4 can be created using ETH directly by registering it as one of the tokens in the PoolKey. The PoolManager supports receiving msg.value and performs internal handling of ETH without needing to wrap into WETH. To safely manage native ETH, it uses low-level call and transfer logic for ETH inputs/outputs, alongside standard ERC-20 logic for the second token. This avoids the gas-heavy approve() and transferFrom() flow required for WETH, and simplifies DApp integrations and swaps involving native ETH. |
Custom Accounting
| Problem | Previously, the way Uniswap handled liquidity, fees, and balances was hardcoded, limiting innovation. Developers couldn't easily implement new pool types or fee models without modifying the entire protocol or forking it. |
|---|---|
| Solution | With Uniswap v4's custom accounting via hooks, developers can override or extend how token balances, fees, or pool states are handled, enabling custom AMM logic on top of the core protocol. |
| How it works | Custom accounting is implemented by overriding hook functions like beforeSwap() or afterSwap() to insert bespoke tracking logic. For example: a developer could inject a volatility-based fee model using on-chain oracle data inside a beforeSwap() hook; another could simulate a virtual AMM (like a TWAMM or batch auction model) using time-based state variables in hook storage. The hook contract has persistent storage and full context on swap parameters — it can adjust output amounts, charge fees, or log analytics independently from the core logic, effectively acting like a plugin to the shared PoolManager engine. |
Other Notable Features
ERC-6909 Accounting
| Problem | ERC-20 token standards are gas-inefficient when used for internal bookkeeping — every transfer involves external contract calls and storage writes, which quickly adds up in DeFi protocols. |
|---|---|
| Solution | Uniswap v4 adopts ERC-6909, an emerging token accounting standard that is more efficient for internal balance tracking, particularly useful for managing liquidity shares within pools. |
| How it works | Uniswap v4 uses ERC-6909-like internal logic (inspired by its draft spec) for managing LP tokens or positions. ERC-6909 uses centralized balance mappings (balances[address][id]) and allows for single-op transfers, minting, and burning without ERC-20 overhead. Unlike ERC-20, there's no need for approve() or external contract calls — the accounting is internal to the PoolManager and/or hook contracts. This enables fast, gas-efficient updates to liquidity positions and rewards without relying on traditional token standards. |
Governance updates
| Problem | Uniswap governance had limited flexibility when it came to pool-level control. Governance couldn't selectively adjust parameters like fees or tick spacing for individual pools, limiting fine-tuned protocol upgrades or incentives. |
|---|---|
| Solution | Uniswap v4 allows governance to participate in fee collection and configure key parameters more granularly, enabling smarter incentives and protocol revenue management. |
| How it works | Governance can now set a protocol fee share for each pool individually. This share defines how much of the LP fee (e.g., 0.3%) is routed to the protocol instead of liquidity providers. The logic for extracting and storing protocol fees is built into the PoolManager. Additionally, governance can: approve or deny specific hook contracts before they're used; set limits on fee tiers or enable/disable custom pools; upgrade PoolManager logic via factory-level governance actions. This structure maintains decentralization while allowing strategic influence over the protocol's economics. |
Gas reductions
| Problem | Trading and interacting with liquidity pools on Ethereum has traditionally been costly, especially with complex transactions like multi-hop swaps or frequent liquidity changes. |
|---|---|
| Solution | Uniswap v4 significantly reduces gas costs using three main strategies: singleton architecture, flash accounting, and native ETH support. |
| How it works | 1. Singleton Architecture: eliminates inter-contract calls by keeping all pool logic in one contract. 2. Flash Accounting: delays token transfers and collapses them into one net transfer, reducing multiple transferFrom() calls. 3. Native ETH Support: bypasses WETH wrapping/unwrapping, which saves gas and simplifies contract interactions. The protocol also removes certain features like auto-oracle updates (present in v3), further reducing gas use by 15k+ per swap in some cases. |
donate()
| Problem | In earlier Uniswap versions, if users wanted to contribute tokens to a pool (for tipping, seeding, or incentives) without receiving LP tokens, there wasn't a clean or gas-efficient way to do so. This made it harder to incentivize or rebalance pools manually. |
|---|---|
| Solution | Uniswap v4 introduces the donate() function, which allows anyone to send tokens directly to a pool without expecting anything in return, making it easier to support or rebalance liquidity. |
| How it works | The donate() function allows users to send tokens directly into a liquidity pool without modifying positions or minting LP tokens — purely to affect the pool's balance or price. The function is routed through the singleton PoolManager. A user specifies the PoolKey and the token amounts (amount0, amount1). The PoolManager executes a token transfer from the user to the pool via transferFrom(). No position is created, and no liquidity shares are minted. Since the pool's reserves change but the total liquidity does not, the price in the AMM formula (x*y=k) shifts accordingly. If the pool is using a hook, beforeDonate() and afterDonate() callbacks are triggered, which can add custom logic (e.g., event logging, reward tracking, or caps). |
References
[1] https://app.uniswap.org/whitepaper-v4.pdf
[2] https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5152215
[3] Known Effects of Hook Permissions
[5] https://docs.uniswap.org/contracts/v4/overview
Cheat Sheet — Uniswap v4
Automated Market Maker (AMM): A system that uses math (instead of a human broker) to let people swap tokens directly, using pools of tokens provided by users. Instead of matching buyers and sellers like a normal exchange (order book), AMMs use pools of tokens (liquidity pools), and a math formula decides how much of each token you get when you swap. Before AMMs (Uniswap v1, 2018), trading crypto required centralized exchanges with order books. AMMs made trading decentralized, permissionless, and instant; Uniswap v4 improves efficiency with hooks and gas savings.
Hooks: Small custom smart contracts that let developers add their own rules or features to v4 pools — dynamic fees, limit orders, or specialized trading logic. They run at specific moments (like before or after a swap) to add things like price oracles or MEV protection. Think of a pool as a pizza oven and hooks as special ingredients you add without changing the oven itself. Poorly written hooks could have bugs, so audits are key.
Singleton: Instead of creating a new smart contract for every trading pool, v4 uses one big contract (the PoolManager) to manage all pools, making it cheaper and simpler. The singleton design cuts pool creation costs by ~99% and makes multi-hop swaps faster since all pools live in one contract.
Flash Accounting: Tracks what tokens are owed during a trade and settles them all at once at the end, instead of moving tokens after every step. It uses Ethereum's EIP-1153 transient storage to keep a temporary "tab" of token movements, reducing costly ERC-20 transfers. At a restaurant, instead of paying for every dish as it arrives, you get one bill at the end.
Native ETH: v1 used ETH but was limited; v2/v3 required WETH wrapping. v4 saves ~21k gas per ETH transfer and improves UX, but requires careful contract design to handle ETH securely.
Custom Accounting: Hooks can override core AMM math with custom logic. Like customizing a board game's rules — the board (v4) stays the same, but you add house rules (via hooks). In v3, new pool types (like v2-style or TWAMMs) required forking the protocol; custom accounting lets developers experiment without starting from scratch.
ERC-6909 Accounting: A token standard that tracks balances inside the v4 contract, avoiding gas-heavy ERC-20 transfers for liquidity positions or rewards. It provides native support for multi-token operations through mint/burn mechanics that integrate with v4's flash accounting. Instead of mailing money back and forth (ERC-20 transfers), you keep it in a shared piggy bank (PoolManager) and just update a ledger.
Governance Update: v4 governance lets the community set a portion of pool fees for the protocol and approve hook contracts. In v3 governance could only set broad fee tiers, not pool-specific fees; v4 allows finer control to fund protocol growth without centralizing too much.
TWAMM (Time-Weighted Average Market Maker): A trading method that spreads large orders over time to avoid big price jumps, executable in v4 via hooks. Like sprinkling water over a garden over time instead of dumping a whole bucket at once. TWAMMs existed outside Uniswap but required custom AMMs; v4's hooks bring them in without forking.
Pool Key: A unique ID for each v4 pool, listing details like the token pair, fee, and hook address, used by the PoolManager to manage pools. Like a library card for each pool, telling the librarian (PoolManager) which book (pool) to pull and what rules (hooks) apply.
Cheat Sheet — General
Liquidity: The pool of tokens (like ETH and USDC) locked in a smart contract that people can trade against in an AMM. LPs deposit pairs of tokens and earn fees when others trade. In v4, hooks let LPs customize how their liquidity is used.
Concentrated Liquidity: Lets LPs choose a specific price range for their tokens, earning more fees when trades happen in that range. v1/v2 spread liquidity across all prices (wasting capital); v3 introduced concentrated liquidity (2021); v4's hooks make it more adaptable. Normal liquidity is like a sprinkler (spread evenly); concentrated liquidity is like a garden hose aimed at the plants that need it.
Liquidity Pool: A collection of tokens locked in a smart contract, used to facilitate trading in an AMM. v4's pools are managed by the PoolManager, with hooks allowing custom rules.
Gas Fee: Small payments in ETH to use the Ethereum network. v4 slashes gas fees with singleton architecture (99% cheaper pool creation), flash accounting, and native ETH.
MEV (Maximal Extractable Value): Profit validators/miners make by reordering or including specific transactions (front-running, arbitrage), often at traders' expense. Hooks in v4 can implement MEV protection, like redirecting profits to LPs.
Oracle: A system that provides real-world data (like token prices) to smart contracts. v4 removes v2/v3's built-in price oracle (which added ~15k gas per swap) and lets hooks create custom oracles.
Multi-Hop Swap: A trade that goes through multiple pools (e.g., A → B → C). The singleton architecture and flash accounting make multi-hop swaps faster and cheaper by keeping all actions in one contract with fewer transfers.
Dynamic Fee: Trading fees in a pool that can change automatically based on market conditions (e.g., volatility), set by custom hooks instead of being fixed. In v2 fees were fixed at 0.3%; v3 introduced fixed fee tiers; v4's hooks let fees adapt instantly.
Lock Mechanism: Ensures all trades or actions in a pool complete properly by "locking" the PoolManager during a transaction, guaranteeing solvency (no tokens owed) by the end. Used in flash accounting, it prevents partial transactions from leaving the pool in debt.
v3 (Old Way) vs v4 (Flash Accounting)
In Uniswap v3, swapping ETH → DAI typically goes through multiple pools (e.g., ETH → USDC, then USDC → DAI), and separate token transfers happen at each step — each leg incurs its own ERC-20 transfer and gas.
In Uniswap v4, thanks to flash accounting using EIP-1153, all intermediate steps (ETH → USDC and USDC → DAI) are tracked internally as balance changes ("deltas"). No actual tokens move until the very end of the transaction. Only the net result — ETH in, DAI out — is executed with just two transfers: ETH is taken from the user, and DAI is sent back to the user.
