Uniswap v4 for accountants: one contract, hooks and netted transfers
How v4's singleton PoolManager, hooks, flash accounting, native ETH and dynamic fees change the evidence trail for LP positions and swaps.
If your treasury provides liquidity or trades on Uniswap v4, the on-chain trail looks different from v3: tokens move once at the end of a transaction rather than per step, pools can run custom code, and fees can change trade by trade. The accounting questions are mostly the same as v3, but you need better evidence to answer them.
Uniswap v4 went live on 31 January 2025 across ten networks, including Ethereum, Arbitrum, Base and Polygon [1]. It keeps the concentrated-liquidity model introduced in v3 and adds several architectural changes [2]. Our earlier explainer on v3 positions covers fee-versus-principal separation; this piece focuses on what is new.
One contract holds every pool
In v2 and v3, a factory deployed a separate contract for each pool. In v4, a single contract, the PoolManager, manages all pools [2][3]. The whitepaper says this makes creating a pool about 99 percent cheaper [2].
For reconciliation, this matters because the counterparty address on a v4 transfer is usually the PoolManager, not a pool-specific address. You cannot tell which pool a deposit went to from the counterparty alone. The pool is identified inside the event data, so your records need the pool identifier from the logs, not just the token transfer.
Flash accounting: transfers happen at the end
Each v4 operation updates an internal running balance called a delta, which tracks what is owed to or from the PoolManager [2][5]. Actual token transfers happen only at the end, when the caller settles what it owes and takes what it is owed; the transaction fails unless every delta is back to zero [2][3]. These balances live in transient storage, which only lasts for the transaction [2].
The practical effect: a multi-hop swap, or a swap followed by adding liquidity, can show only the net token movements on-chain. If you swap ETH to USDC to DAI, you may see ETH out and DAI in with no USDC transfer at all. Classifying from transfers alone will miss the middle step. Under most policies the intermediate token was never held by you, so the net result is usually what you book, but you should confirm that from the decoded events rather than assume it.
Hooks: pools that run their own code
Each v4 pool can attach an optional hook contract that runs before or after pool creation, adding or removing liquidity, swaps and donations [4]. Hooks can apply dynamic fees, restrict who can provide liquidity, and even build custom accounting or a different pricing curve [4]. With certain permissions, a hook can return its own deltas that adjust what the user pays or receives [4]. The whitepaper gives withdrawal fees on LP positions as one example [2].
This is the biggest accounting change. In v3, a pool with the same tokens and fee tier behaved the same way everywhere. In v4, two ETH/USDC pools can have different economics because of their hooks. A hook can also take a share of swap fees and allocate it to anyone, including LPs, swappers or the hook creator [2]. Before you book activity in a pool, find out what its hook does. A hook that charges a withdrawal fee, pays extra rewards or bypasses concentrated liquidity entirely changes what each token movement means.
Dynamic fees and governance fees
A pool creator chooses at creation whether a pool has a fixed fee or a fee managed by its hook [2]. Governance can also take a capped percentage of swap fees, in addition to the LP fee, and no longer controls which fee tiers are allowed [2]. So the fee rate on a swap is a fact about that specific trade, not a constant you can look up once per pool. If you report trading costs or fee income by rate, take the rate from the event data.
Native ETH and ERC-6909 balances
v4 supports pairs with native ETH again, so traders no longer have to wrap into WETH first; WETH pairs still exist alongside them [2]. Your ledger may now see ETH and WETH versions of the same market. Keep them as separate assets: they are different tokens, and whether wrapping is a disposal is a policy question in its own right.
v4 also lets users mint ERC-6909 tokens that represent balances held inside the PoolManager, so frequent traders and LPs can avoid moving tokens in and out [2][3]. A wallet holding these claims has not lost the underlying tokens: they sit in the PoolManager on its behalf. If your balance checks only read ERC-20 balances, these claims will look like missing funds.
Positions and fees
Through the periphery PositionManager contract, liquidity positions are still represented as NFTs [6]. There is no dedicated collect step: fees are collected by decreasing liquidity by zero [6]. When you increase or decrease liquidity, accumulated fees are credited automatically, and when you add liquidity, accrued fees can partly or fully cover the tokens needed [6]. That means one add-liquidity transaction can contain a fee realization and a reinvestment with little visible token movement. You need the decoded fee amounts to separate fee income from principal.
| Account | Debit | Credit |
|---|---|---|
| Add liquidity to a native ETH/USDC v4 pool (basis-continuity policy) 1 ETH carried at 2,500 plus 3,000 USDC carried at 3,000 | ||
| LP position — Uniswap v4 ETH/USDC (NFT) | 5,500.00 | |
| Digital assets — ETH | 2,500.00 | |
| Digital assets — USDC | 3,000.00 | |
| Collect fees by a zero-liquidity decrease 0.01 ETH at 3,000 = 30.00 plus 25 USDC = 25.00 | ||
| Digital assets — ETH | 30.00 | |
| Digital assets — USDC | 25.00 | |
| LP fee income | 55.00 | |
How standards treat LP positions
Nothing in v4 settles whether depositing into a pool is a disposal; that remains a policy and jurisdiction question. Under US GAAP, ASU 2023-08 fair value applies only to fungible crypto assets that do not give the holder enforceable rights to underlying assets [7]. An LP position NFT is not fungible, and it represents a claim on pool tokens, so most entities will conclude it is outside that scope. In 2026 the FASB tentatively decided to bring wrapped and receipt tokens into scope, but KPMG notes that how LP tokens fit remains unclear [8]. Treat this as an open area and document your reasoning.
What to do
- Record the pool ID and hook address for every v4 position, not just the PoolManager counterparty.
- Read what each pool's hook does before booking activity in it, and note any hook fees or extra rewards.
- Classify from decoded events, not from token transfers, so netted multi-hop swaps and in-transaction fee reinvestment are not missed.
- Track ETH and WETH as separate assets, and include ERC-6909 claim balances in wallet reconciliations.
- Take swap fee rates from each trade's event data rather than assuming a fixed tier.
- Write down your policy for LP deposits (disposal or basis continuity) and apply it consistently across v3 and v4.
Sources
- Uniswap v4 is Here – A New Era of DeFi (Uniswap Labs)
- Uniswap v4 Core (whitepaper) (Uniswap Labs)
- Uniswap/v4-core (Uniswap (GitHub))
- Uniswap v4 Hooks (Uniswap Developer Docs)
- Uniswap v4 Flash Accounting (Uniswap Developer Docs)
- Position Manager (v4 guides) (Uniswap Developer Docs)
- 2.3 Crypto Assets Within the Scope of ASU 2023-08 (Deloitte DART)
- FASB makes progress on crypto asset transfers project (KPMG)
General information for finance teams, current as of publication. Not legal, tax or accounting advice.