Uniswap v4 Core

August 2024
Hayden Adams Moody Salem Noah Zinsmeister
[email protected] [email protected] [email protected]

Sara Reynolds Austin Adams Will Pote

Mark Toda Alice Henshaw Emily Williams

Dan Robinson
[email protected]

ABSTRACT gas costs for swappers and without customizability for integrators.
Uniswap v4 is a non-custodial automated market maker imple- Other possible enhancements, such as time-weighted average price
mented for the Ethereum Virtual Machine. Uniswap v4 offers cus- orders (TWAP) through a time-weighted average market maker
tomizability via arbitrary code hooks, allowing developers to aug- (TWAMM) [8], volatility oracles, limit orders, or dynamic fees, re-
ment the concentrated liquidity model introduced in Uniswap v3 quire reimplementations of the core protocol, and can not be added
with new functionality. In Uniswap v4, anyone can create a new to Uniswap v3 by third-party developers.
pool with a specified hook, which can run before or after pre- Additionally, in previous versions of Uniswap, deployment of
determined pool actions. Hooks can be used to implement features new pools involves deploying a new contract—where cost scales
that were previously built into the protocol, like oracles, as well with the size of the bytecode—and trades with multiple Uniswap
as new features that previously would have required independent pools involve transfers and redundant state updates across multiple
implementations of the protocol. Uniswap v4 also offers improved contracts. Additionally since Uniswap v2, Uniswap has required
gas efficiency and developer experience through a singleton imple- ETH to be wrapped into an ERC-20, rather than supporting native
mentation, flash accounting, and support for native ETH. ETH. These design choices came with increased gas costs for end
users.
1 INTRODUCTION In Uniswap v4, we improve on these inefficiencies through a
few notable features:
Uniswap v4 is an automated market maker (AMM) facilitating effi-
cient exchange of value on the Ethereum Virtual Machine (EVM).
As with previous versions of the Uniswap Protocol, it is non- • Hooks: Uniswap v4 allows anyone to deploy new concen-
custodial, non-upgradable, and permissionless. The focus of Uniswap trated liquidity pools with custom functionality. For each
v4 is on additional customization for developers and architectural pool, the creator can define a “hook contract” that imple-
changes for gas efficiency improvements, building on the AMM ments logic executed at specific points in a call’s lifecycle.
model built by Uniswap v1 and v2 and the concentrated liquidity These hooks can also manage the swap fee of the pool
model introduced in Uniswap v3. dynamically, implement custom curves, and adjust fees
Uniswap v1 [2] and v2 [3] were the first two iterations of the charged to liquidity providers and swappers though Cus-
Uniswap Protocol, facilitating ERC-20 <> ETH and ERC-20 <> tom Accounting.
ERC-20 swaps, respectively, both using a constant product market • Singleton: Uniswap v4 moves away from the factory model
maker (CPMM) model. Uniswap v3 [4] introduced concentrated used in previous versions, instead implementing a single
liquidity, enabling more capital efficient liquidity through positions contract that holds all pools. The singleton model reduces
that provide liquidity within a limited price range, and multiple fee the cost of pool creation and multi-hop trades.
tiers. • Flash accounting: The singleton uses “flash accounting,”
While concentrated liquidity and fee tiers increased flexibility for which allows a caller to lock the pool and access any of
liquidity providers and allowed for new liquidity provision strate- its tokens, as long as no tokens are owed to or from the
gies, Uniswap v3 lacks flexibility to support new functionalities caller by the end of the lock. This functionality is made
invented as AMMs and DeFi have evolved. efficient by the transient storage opcodes described in EIP-
Some features, like the price oracle originally introduced in 1153 [5]. Flash accounting further reduces the gas cost of
Uniswap v2 and included in Uniswap v3, allow integrators to uti- trades that cross multiple pools and supports more complex
lize decentralized onchain pricing data, at the expense of increased integrations with Uniswap v4.
1
 Adams et al.

• Native ETH : Uniswap v4 brings back support for native 2.2 Hook-managed fees
ETH, with support for pairs with native tokens inside v4 Uniswap v4 allows fees to be taken on swapping by the hook.
pools. ETH swappers and liquidity providers benefit from Swap fees can be either static, or dynamically managed by a hook
gas cost reductions from cheaper transfers and removal of contract. The hook contract can also choose to allocate a percentage
additional wrapping costs. of the swap fees to itself. Fees that accrue to hook contracts can
• Custom Accounting: The singleton supports both augment- be allocated arbitrarily by the hook’s code, including to liquidity
ing and bypassing the native concentrated liquidity pools providers, swappers, hook creators, or any other party.
through hook-returned deltas, utilizing the singleton as The capabilities of the hook are limited by immutable flags cho-
an immutable settlement layer for connected pools. This sen when the pool is created. For example, a pool creator can choose
feature can support use-cases like hook withdrawal fees, whether a pool has a static fee (and what that fee is) or dynamic
wrapping assets, or constant product market maker curves fees.
like Uniswap v2. Governance also can take a capped percentage of swap fees, as
The following sections provide in-depth explanations of these discussed below in the Governance section (6.2).
changes and the architectural changes that help make them possible.
3 SINGLETON AND FLASH ACCOUNTING
2 HOOKS Previous versions of the Uniswap Protocol use the factory/pool
Hooks are externally deployed contracts that execute some developer- pattern, where the factory creates separate contracts for new token
defined logic at a specified point in a pool’s execution. These hooks pairs. Uniswap v4 uses a singleton design pattern where all pools
allow integrators to create a concentrated liquidity pool with flexi- are managed by a single contract, making pool deployment 99%
ble and customizable execution. Optionally, hooks can also return cheaper.
custom deltas that allow the hook to change the behavior of the The singleton design complements another architectural change
swap — described in detail in the Custom Accounting section (5). in v4: flash accounting. In previous versions of the Uniswap Pro-
Hooks can modify pool parameters, or add new features and tocol, most operations (such as swapping or adding liquidity to a
functionality. Example functionalities that could be implemented pool) ended by transferring tokens. In v4, each operation updates an
with hooks include: internal net balance, known as a delta, only making external trans-
fers at the end of the lock. The new take() and settle() functions
• Executing large orders over time through TWAMM [8]
can be used to borrow or deposit funds to the pool, respectively. By
• Onchain limit orders that fill at tick prices
requiring that no tokens are owed to the pool manager or to the
• Volatility-shifting dynamic fees
caller by the end of the call, the pool’s solvency is enforced.
• Mechanisms to internalize MEV for liquidity providers [1]
Flash accounting simplifies complex pool operations, such as
• Median, truncated, or other custom oracle implementations
atomic swapping and adding. When combined with the singleton
• Constant Product Market Makers (Uniswap v2 functional-
model, it also simplifies multi-hop trades or compound operations
ity)
like swapping before adding liquidity.
Before the Cancun hard fork, the flash accounting architecture
2.1 Action Hooks was expensive because it required storage updates at every balance
When someone creates a pool on Uniswap v4, they can specify a change. Even though the contract guaranteed that internal account-
hook contract. This hook contract implements custom logic that ing data is never actually serialized to storage, users would still
the pool will call out to during its execution. Uniswap v4 currently pay those same costs once the storage refund cap was exceeded
supports ten such hook callbacks: [6]. But, because balances must be 0 by the end of the transaction,
accounting for these balances can be implemented with transient
• beforeInitialize/afterInitialize
storage, as specified by EIP-1153 [5].
• beforeAddLiquidity/afterAddLiquidity1
Together, singleton and flash accounting enable more efficient
• beforeRemoveLiquidity/afterRemoveLiquidity
routing across multiple v4 pools, reducing the cost of liquidity
• beforeSwap/afterSwap
fragmentation. This is especially useful given the introduction of
• beforeDonate/afterDonate
hooks, which will greatly increase the number of pools.
The address of the hook contract determines which of these hook
callbacks are executed. This creates a gas efficient and expressive 4 NATIVE ETH
methodology for determining the desired callbacks to execute, and
Uniswap v4 is bringing back native ETH in trading pairs. While
ensures that even upgradeable hooks obey certain invariants. There
Uniswap v1 was strictly ETH paired against ERC-20 tokens, native
are minimal requirements for creating a working hook. In Figure
ETH pairs were removed in Uniswap v2 due to implementation
1, we describe how the beforeSwap and afterSwap hooks work as
complexity and concerns of liquidity fragmentation across WETH
part of swap execution flow.
and ETH pairs. Singleton and flash accounting mitigate these prob-
lems, so Uniswap v4 allows for both WETH and ETH pairs.
1 Having separate permissions for ‘beforeAddLiquidity‘ and ‘beforeRemoveLiquidity‘ Native ETH transfers are about half the gas cost of ERC-20 trans-
reflects the difference in security assumptions between those two actions. Hooks that
can affect minting but not burning of liquidity are safer for liquidity providers, since fers (21k gas for ETH and around 40k gas for ERC-20s). Currently
they are guaranteed to be able to withdraw their liquidity. Uniswap v2 and v3 require the vast majority of users to wrap
2
Uniswap v4 Core

Start swap

True
S0. Check beforeSwap flag H1. Run beforeSwap Hook

False
Return
S1. Execute swap

True
S2. Check afterSwap flag H2. Run afterSwap Hook

False

Return
End swap

Figure 1: Swap Hook Flow

(unwrap) their ETH to (from) WETH before (after) trading on the security benefits, and easier integration for flow. Developers should
Uniswap Protocol, requiring extra gas. According to transaction also benefit from a well-audited code-base for the basis of their
data, the majority of users start or end their transactions in ETH, AMM.
adding this additional unneeded complexity. Custom accounting will also support experimentation in liquidity
provision strategies, which historically requires the creation of an
entirely new AMM. Creating a custom AMM requires significant
5 CUSTOM ACCOUNTING
technical resources and investment, which may not be economically
Newly introduced in Uniswap v4 is custom accounting - which viable for many.
allows hook developers to alter end user actions utilizing hook-
returned deltas, token amounts that are debited/credited to the
6 OTHER NOTABLE FEATURES
user and credited/debited to the hook, respectively. This allows
hook developers to potentially add withdrawal fees on LP positions, 6.1 ERC-6909 Accounting
customized LP fee models, or match against some flow, all while Uniswap v4 supports the minting/burning of singleton-implemented
ultimately utilizing the internal concentrated liquidity native to ERC-6909 tokens for additional token accounting, described in the
Uniswap v4. ERC-6909 specification [7]. Users can now keep tokens within the
Importantly, hook developers can also forgo the concentrated singleton and avoid ERC-20 transfers to and from the contract. This
liquidity model entirely, creating custom curves from the v4 swap will be especially valuable for users and hooks who continually use
parameters. This creates interface composability for integrators - the same tokens over multiple blocks or transactions, like frequent
allowing the hook to map the swap parameters to their internal swappers, liquidity providers, or custom accounting hooks.
logic.
In Uniswap v3, users were required to utilize the concentrated 6.2 Governance updates
liquidity AMM introduced in the same version. Since their intro-
Similar to Uniswap v3, Uniswap v4 allows governance the ability to
duction, concentrated liquidity AMMs have become widely used as
take up to a capped percentage of the swap fee on a particular pool,
the base liquidity provision strategy in the decentralized finance
which are additive to LP fees. Unlike in Uniswap v3, governance
markets. While concentrated liquidity is able to support most ar-
does not control the permissible fee tiers or tick spacings.
bitrary liquidity provision strategies, it may require increased gas
overhead to implement specific strategies.
One possible example is a Uniswap v2 on Uniswap v4 hook, 6.3 Gas reductions
which bypasses the internal concentrated liquidity model entirely - As discussed above, Uniswap v4 introduces meaningful gas op-
utilizing a constant product market maker fully inside of the hook. timizations through flash accounting, the singleton model, and
Using custom accounting is cheaper than creating a similar strategy support for native ETH. Additionally, the introduction of hooks
in the concentrated liquidity math. makes the protocol-enshrined price oracle that was included in
The benefit of custom accounting for developers - compared Uniswap v2 and Uniswap v3 unnecessary, which also means base
to rolling a custom AMM - is the singleton, flash accounting, pools forgo the oracle altogether and save around 15k gas on the
and ERC-6909. These features support cheaper multi-hop swaps, first swap on a pool in each block.
3
 Adams et al.

6.4 donate() [2] Hayden Adams. 2018. Uniswap v1 Core. Retrieved Jun 12, 2023 from https:
//hackmd.io/@HaydenAdams/HJ9jLsfTz
donate() allows users, integrators, and hooks to directly pay in- [3] Hayden Adams, Noah Zinsmeister, and Dan Robinson. 2020. Uniswap v2 Core.
range liquidity providers in either or both of the tokens of the pool. Retrieved Jun 12, 2023 from https://uniswap.org/whitepaper.pdf
[4] Hayden Adams, Noah Zinsmeister, Moody Salem, River Keefer, and Dan Robin-
This functionality relies on the fee accounting system to facilitate son. 2021. Uniswap v3 Core. Retrieved Jun 12, 2023 from https://uniswap.org/
efficient payments. The fee payment system can only support either whitepaper-v3.pdf
of the tokens in the token pair for the pool. Potential use-cases could [5] Alexey Akhunov and Moody Salem. 2018. EIP-1153: Transient storage opcodes.
Retrieved Jun 12, 2023 from https://eips.ethereum.org/EIPS/eip-1153
be tipping in-range liquidity providers on TWAMM orders or new [6] Vitalik Buterin and Martin Swende. 2021. EIP-3529: Reduction in refunds. Retrieved
types of fee systems. Jun 12, 2023 from https://eips.ethereum.org/EIPS/eip-3529
[7] JT Riley, Dillon, Sara, Vectorized, and Neodaoist. 2023. ERC-6909: Minimal Multi-
Token Interface. Retrieved Aug 26, 2024 from https://eips.ethereum.org/EIPS/eip-
7 SUMMARY 6909
In summary, Uniswap v4 is a non-custodial, non-upgradeable, and [8] Dave White, Dan Robinson, and Hayden Adams. 2021. TWAMM. Retrieved Jun
12, 2023 from https://www.paradigm.xyz/2021/07/twamm
permissionless AMM protocol. It builds upon the concentrated
liquidity model introduced in Uniswap v3 with customizable pools
through hooks. Complementary to hooks are other architectural
DISCLAIMER
changes like the singleton contract which holds all pool state in one This paper is for general information purposes only. It does not
contract, and flash accounting which enforces pool solvency across constitute investment advice or a recommendation or solicitation to
each pool efficiently. Additionally, hook developers can elect to buy or sell any investment and should not be used in the evaluation
bypass the concentrated liquidity entirely, utilizing the v4 singleton of the merits of making any investment decision. It should not be
as an arbitrary delta resolver. Some other improvements are native relied upon for accounting, legal or tax advice or investment rec-
ETH support, ERC-6909 balance accounting, new fee mechanisms, ommendations. This paper reflects current opinions of the authors
and the ability to donate to in-range liquidity providers. and is not made on behalf of Uniswap Labs, Paradigm, or their
affiliates and does not necessarily reflect the opinions of Uniswap
REFERENCES Labs, Paradigm, their affiliates or individuals associated with them.
[1] Austin Adams, Ciamac Moallemi, Sara Reynolds, and Dan Robinson. 2024. The opinions reflected herein are subject to change without being
am-AMM: An Auction-Managed Automated Market Maker. arXiv preprint updated.
arXiv:2403.03367 (2024).