Uniswap v4 Core

01 Claim ledger

What the paper is allowed to say

Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.

1. Claim 01 · Paper model

   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.

2. Claim 02 · Paper model

   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.

3. Claim 03 · Paper model

   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.

4. Claim 04 · Paper model

   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.

02 Three cuts

Observation, model, falsifier

A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.

1. 01 Singleton is an accounting move

   Observation

   What the study says

   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.

   Model

   What has to hold

   Integrators read pool state including the hook address, not only the two tokens.

   Falsifier

   What would retire it

   Does the pool's curve match v3, or has the hook changed it?

2. 02 Hooks are the market

   Observation

   What the study says

   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.

   Model

   What has to hold

   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.

   Falsifier

   What would retire it

   Can the hook or its admin be replaced?

3. 03 Flash accounting must net

   Observation

   What the study says

   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.

   Model

   What has to hold

   The lock's settlement is enforced by the manager and cannot be bypassed by the hook.

   Falsifier

   What would retire it

   Does the pool's curve match v3, or has the hook changed it?

4. 04 v3 is not the default

   Observation

   What the study says

   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.

   Model

   What has to hold

   Native-currency accounting does not break the debt netting. That is an implementation invariant, not a slogan about ETH.

   Falsifier

   What would retire it

   Can a lock end with unpaid debt?

03 Sequence

One action, as an operating tape

1. 01A developer deploys or selects a hook and initialises a pool in the manager.
2. 02A liquidity provider adds liquidity. The hook may run, and may take a cut or refuse.
3. 03A swapper calls the manager. Before and after the curve moves, the hook may run.
4. 04Token debts are recorded inside the lock rather than transferred immediately.
5. 05The lock settles. Every debt must be paid or the transaction reverts.

04 Load-bearing

The argument, and where a pitch drops it

1. Customisation moved risk into unaudited code

   The cut

   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.

   Why it carries weight

   If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

   Where it is dropped

   A pool with a hook is not the v3 invariant. Read the hook or you do not know the product.

2. Upgrade rights are a hook property

   The cut

   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.

   Why it carries weight

   If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

   Where it is dropped

   Hooks can be upgraded if their own admin allows it. Immutability is a property of that hook, not of the word v4.

05 Register

What has to be true

• Model · Not re-measured

  The lock's settlement is enforced by the manager and cannot be bypassed by the hook.

• Adversary · Not re-measured

  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.

• Model · Not re-measured

  Integrators read pool state including the hook address, not only the two tokens.

• Model · Not re-measured

  Native-currency accounting does not break the debt netting. That is an implementation invariant, not a slogan about ETH.

06 Divergence

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.

A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.

07 Pre-mortem

What to check before you use the idea

1. Kill test 1What is the hook address, and what permissions does it have?
2. Kill test 2Can the hook or its admin be replaced?
3. Kill test 3Does the pool's curve match v3, or has the hook changed it?
4. Kill test 4Can a lock end with unpaid debt?
5. 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.

08 Anatomy

The paper, in the order a builder needs

09 Lexicon

Terms, opened into the record

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.

10 Repository

Every linked record on this page

Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.

11 Related

The next papers, as theses

• Uniswap · 2021

  Uniswap v3 Core

  The 2021 paper that replaces the uniform reserve curve with concentrated liquidity. A provider chooses a price range. Inside the range their capital acts like a constant-product pool. Outside it, their position is entirely in one asset.

• Uniswap · 2020

  Uniswap v2 Core

  The 2020 core paper for Uniswap v2: a constant-product automated market maker, with arbitrary ERC-20 pairs, price accumulators, and a flash-swap callback. It is the clearest short specification of the pool that much of later DeFi either forked or assumed.

• TWAMM · 2021

  The Time-Weighted Average Market Maker

  Execute a large order as if it were split into infinitely many tiny trades across an interval, without paying gas for each piece. Settlement is lazy. This is an order schedule, not a price oracle, despite the nearby acronym TWAP.