A Complete Guide to Uniswap V4
Crypto UXDeFiInfrastructure

A Complete Guide to Uniswap V4

Discover how Uniswap V4 improves on V3 with innovations like a singleton pool, flash accounting, and hooks, unlocking more efficient and customizable swaps.

By sm-stack
|

History of Uniswap: V1 & V2

Before diving deeper into V4, let’s look at how the Uniswap protocol has evolved. Uniswap has built its protocol for over seven years, from V1 to V4.

Uniswap V1, created in 2017, was a very simple AMM. Its simplicity is evident because the entire codebase consisted of about 500 lines. Due to this simplicity, Uniswap V1 charged lower gas fees than other AMMs at the time. However, V1 only supported swaps between ETH and ERC20 tokens. Swapping between two ERC20 tokens required another step of swapping through ETH, which introduced inefficiencies.

Uniswap V2, which was launched in May 2020, introduced a more advanced structure that addressed this issue. It allowed the creation of pools between ERC20 tokens, enabling direct swaps between two tokens and eliminating the inefficiencies of V1. Additionally, it introduced new features such as an oracle system, which allowed direct price queries from the V2 pool, and flash loans, enabling traders to borrow funds safely for arbitrage opportunities.

However, Uniswap V2 still had its shortcomings. One major issue was what is commonly referred to as lazy liquidity. Let's examine this problem through an example.

Suppose Alice supplies liquidity worth $1,000 to the USDC-ETH pool in Uniswap V2. This liquidity is distributed evenly across the entire price range, from zero to infinity, regardless of the ETH price. Let's assume Bob swaps within this pool, causing the ETH price to rise from $3,000 to $3,100.

In this case, only a small portion of Alice’s liquidity is used for the swap, while the majority remains idle and does not actively participate in the transaction. This phenomenon is known as lazy liquidity.

This problem became even more pronounced in stablecoin pools. The value of stablecoins is typically pegged at $1, and depegging events are rare. Consequently, most stablecoin trades occur near the $1 mark. However, because Uniswap V2 distributes liquidity evenly across all price ranges, only a small fraction of the liquidity actively participates in transactions, while the rest remains idle. This inefficiency worsens the capital efficiency of DEXs, particularly in stablecoin pairs.

Uniswap V3

To address these issues in Uniswap V2, UniSwap V3 introduced concentrated liquidity. This mechanism allows liquidity providers (LPs) to define specific price ranges where their liquidity will be active.

(Concentrated Liquidity in Uniswap V3 | Source: Uniswap V3 whitepaper)

As shown in the image above, under the concentrated liquidity model, LPs can select the price range for which they wish to provide liquidity. Even with the same amount of liquidity, the density of liquidity increases when it is supplied closer to the current price. When swaps occur, fees are distributed proportionately to the liquidity density LPs provide. Therefore, LPs are incentivized to set narrower price ranges close to the current price, allowing them to earn higher fees. This mechanism increases capital efficiency and reduces slippage across the pool.

A prime example of this effect is Uniswap V3’s USDC-DAI pool on the Ethereum mainnet. As illustrated in the image below, most of the liquidity in this pool is concentrated in the price range of $0.9998 to $1.0002.

(DAI-USDC Pool at Uniswap V3 | Source: app.uniswap.org)

This pattern indicates that LPs believe DAI and USDC are unlikely to depeg from $1, so they concentrate their liquidity around this price. By concentrating liquidity, LPs can earn higher swap fees while traders benefit from lower slippage.

However, Uniswap V3 also introduced two significant challenges:

  1. Limited flexibility due to a rigid codebaseUniswap V3 enforced a one-size-fits-all approach where all pools followed the same code structure. This inherently limited flexibility, as it was impossible to tailor features to specific user needs. For example, while the built-in oracle functionality in Uniswap V3 was highly useful for professional traders and data providers, it also increased costs for regular users making swaps. Additionally, because all pools used the same hardcoded logic, it was difficult to implement custom functionalities like limit orders on Uniswap V3 without external modifications.While Uniswap V3 was a well-designed token exchange, it failed to evolve into a broader liquidity platform that encouraged developer innovation.

  2. Gas fee inefficienciesAlthough Uniswap V3 had relatively lower gas fees than other DEXs, it still required over 200,000 gas for a single swap. The issue became even more pronounced when transactions had to route through multiple pools, significantly increasing gas costs. Addressing these gas inefficiencies would drastically enhance the user experience on Uniswap.

What’s new on Uniswap V4?

Uniswap V4 is a protocol designed to make swaps more efficient and improve scalability so that a wider variety of builders can leverage Uniswap’s liquidity. It aims to address the issues presented in V3 while expanding the protocol’s capabilities. What mechanisms does Uniswap V4 introduce, and what new use cases can emerge from them?

First, let's examine the newly added features in Uniswap V4. The core pool structure in Uniswap V4 remains similar to V3, following the concentrated liquidity model. However, Uniswap V4 introduces three key features that significantly enhance the user experience compared to Uniswap V3:

  • Singleton architecture

  • Flash accounting

  • Hook

Let’s dive deeper into each of these features and explore the benefits they provide.

Singleton architecture

Until Uniswap V3, the protocol had two separate components: Factory and pool. Whenever a new pool was created, the factory contract deployed a new pool contract. However, in Uniswap V4, a single contract called PoolManager manages all pools. This new structure allows for cheaper swap routing across multiple pools.

(Swap Routing at Uniswap V4 vs. V3 | Source: Uniswap Blog)

For example, consider a routing scenario where a user swaps ETH to USDC and then USDC to OP. In V3, the swap process involved sending ETH to the ETH-USDC pool, receiving USDC, and then transferring it to the USDC-OP pool to complete the swap for OP tokens. However, in V4, routing is handled by simply updating internal balance records within the same contract. Instead of modifying balances for each pool individually, the balance updates occur only at the beginning and end of the transaction within a single contract. This drastically simplifies and reduces the cost of routing.

Additionally, deploying new pools has become significantly cheaper. In earlier versions, deploying a new pool required deploying a separate smart contract, which was costly due to Ethereum’s high contract deployment fees. However, in V4, pools can be created by simply calling a function within the PoolManager contract instead of deploying a new contract. This reduces deployment costs by over 99% compared to previous versions.

Flash accounting by EIP-1153

The second key feature introduced in Uniswap V4 is flash accounting, a novel approach to reducing gas costs by leveraging an efficient debt settlement model for swaps and liquidity management.

Uniswap V4 tracks outstanding balances between pools and users during a swap or other liquidity actions. Instead of immediately settling each transaction, the system ensures that all outstanding balances are fully settled only at the end of the transaction.

Let’s break this down with an example. When a user initiates a swap in Uniswap V4, three key components are involved:

  1. User: Requests a swap through the Router contract.

  2. Router: Receives the user’s tokens and forwards the request to Uniswap’s core contract.

  3. PoolManager: Executes the swap logic and transfers the requested tokens back to the user.

The interactions between these components can be visualized as follows:

(Initial Swap Process at Uniswap V4)

When the user interacts with the DEX interface to initiate a swap, the Router calls the unlock function in the PoolManager contract. This function unlocks balance modifications within the contract, allowing changes to be made.

The unlock function serves two main purposes:

  1. Prevents reentrancy attacks by ensuring that the function cannot be executed twice in the same transaction.

  2. Calls the Router’s callback function, which handles the actual swap logic.

The real processing of the swap (including balance updates and final settlement) happens inside the Router’s callback function, unlockCallback, which calls multiple functions within the PoolManager to execute the requested action.

In a swap scenario, unlockCallback carries out two key steps:

  1. Modifies balances and calculates outstanding debts

  2. Settles debts and finalizes the swap

The overall process can be visualized as follows:

(Debt Settlement Process at unlockCallback() function at Uniswap V4)

One crucial point to note is that throughout this transaction, certain values must remain unchanged before and after execution. The most important of these is delta, which represents the outstanding balance between the user and the pool, and should always return to zero at the start and end of the transaction.

Ethereum provides a specific storage type for such temporary data: transient storage. This was introduced through EIP-1153 in the Dencun upgrade (2024). Transient storage behaves similarly to standard Ethereum storage but is only valid within a single transaction. Once the transaction ends, all transient storage values are automatically reset, as illustrated below:

(Mechanism of Transient Storage)

Since transient storage is temporary and does not increase Ethereum’s permanent storage load, operations using transient storage are significantly cheaper than regular storage. For example, writing to an empty storage slot costs 20,000 gas, whereas writing to transient storage only costs 100 gas.

Uniswap V4 leverages this by storing debt balances (delta) in transient storage, drastically reducing gas fees. Transactions that previously consumed over 100,000 gas can now be completed with just a few hundred gas. Additionally, reentrancy guards in Uniswap V4 also use transient storage, further lowering costs.

In summary, Uniswap V4 adopts a unique "debt settlement" model designed to optimize gas efficiency through transient storage, making swaps significantly cheaper than Uniswap V3.

This efficiency is evident in real transactions. Below is an example where Hayden Adams attempted to swap 0.3 ETH for USDT. Despite Uniswap V4’s ETH-USDT pool having only ~$400K in liquidity, the Uniswap Router selected it as the optimal path due to V4’s gas efficiency.

(Uniswap Routing Result for ETH-USDT swap | Source: Hayden Adams X)

The Router selects swap paths by considering slippage, gas fees, and other factors. In this case, V4’s lower gas costs made it the preferred route, resulting in increased swap volume flowing into V4 pools and increasing fee revenue for liquidity providers.

Hooks

Among all the new features, Hooks are the most important addition in Uniswap V4.

In Uniswap V3 and other DEXs, users could only interact with predefined functionalities built into the protocol. However, Uniswap V4 allows pool creators to customize their pools with additional logic via Hooks. This enables pools to offer new functionalities tailored to specific needs.

According to Uniswap’s V4 blog post, Hooks could enable features such as:

  • TWAMM (Time-Weighted Automated Market Maker)

  • Dynamic fees based on volatility

  • On-chain limit orders

  • Depositing out-of-range liquidity into lending protocols

  • Custom on-chain oracles

  • Auto-compounding LP fees

  • Redistributing MEV profits to LPs

But how exactly do Hooks work to enable these features? What other use cases could arise from this functionality? And what are developers actually building?

Next, we will explore Hooks in detail, analyzing their impact and potential in Uniswap V4.

Deep dive into Uniswap V4 hooks

General behavior of hooks

In programming, hooking refers to intercepting function calls, messages, or events between software components to modify or extend their functionality. The components responsible for handling these intercepted messages or function calls are known as hooks. This pattern is commonly used for debugging and extending software capabilities.

The five functions of hooks

Uniswap V4 leverages this programming pattern to allow builders to extend the functionality of the DEX. In Uniswap V4, hooks can serve five primary functions:

Function Name

Demonstration

beforeInitialize / afterInitialize

Executes a custom action before/after pool deployment

beforeAddLiquidity / afterAddLiquidity

Executes a custom action before/after a user adds liquidity to the pool

beforeRemoveLiquidity / afterRemoveLiquidity

Executes a custom action before/after a user removes liquidity from the pool

beforeSwap / afterSwap

Executes a custom action before/after a user performs a swap within the pool

beforeDonate / afterDonate

Executes a custom action before/after a user donates tokens to the pool

As the function names suggest, Uniswap V4 allows hooking into specific actions before or after they occur, enabling custom actions based on the data associated with that action. For example, the beforeSwap function is called before a swap executes, allowing the hook developer to implement custom logic before PoolManager processes the swap.

A hook can implement a single function or multiple functions simultaneously, meaning developers can integrate their desired logic into almost every action within Uniswap V4.

Structure of hooks

In Uniswap V4, hooks are separate smart contracts independent of liquidity pools. When deploying a pool, the deployer must specify the address of the hook that will be associated with the pool. Once a hook is set, it cannot be changed. However, a single hook can be shared across multiple pools.

Importantly, even if two pools share the same token pair (e.g., USDC-ETH) and the same fee tier, they are considered different pools if they use different hooks. In Uniswap V3, a token pair could only exist in six different pools based on fee tiers. In contrast, Uniswap V4 allows multiple versions of USDC-ETH pools, each with unique functionalities, such as an oracle-integrated pool, a pool supporting limit orders, or a pool offering dynamic fees.

In summary, Uniswap V4 enables custom pools with specific functionalities through hooks, distinguishing it from previous versions.

At this point, you probably are wondering if:

  1. Hooks can truly implement any logic

  2. It is possible to attain any level of complexity using them.

Let’s look at how hooks work internally to answer these questions.

How hooks work under the hood

Core logic of hooks

To understand how hooks function internally, examining how their functions are structured is essential. In Uniswap V4, specific input and output data formats are defined for each hook function. This section explores the structure of these functions, detailing the data hooks that receive from Uniswap V4 contracts and the actions they can perform with this data.

Let’s examine beforeSwap / afterSwap as an example.

The beforeSwap function is triggered before PoolManager executes the swap logic. It receives five key parameters from PoolManager:

Variable

Demonstration

sender

The address that initiated the swap

zeroForOne

The direction of the swap (e.g., token0 → token1 or vice versa)

amountSpecified

The number of tokens being swapped

sqrtPriceLimitX96

The price limit set by the swapper to control maximum slippage

hookData

Custom data required for additional logic

This means that every time a swap occurs, the hook can access the following critical information:

  1. Who initiated the swap

  2. How much was requested to be swapped

  3. Which token was being bought/sold

  4. The slippage limit set by the user

After executing its logic, beforeSwap returns the following values to PoolManager:

Variable

Demonstration

selector

Function selector for this hook

beforeSwapDelta

Hook’s delta at the swap

lpFeeOverride

Updated LP fee

At this point, we can see that hooks are not just passive extensions but powerful mechanisms that actively interact with the pool’s operations.

Two key return values—beforeSwapDelta and lpFeeOverride—allow hooks to dynamically adjust swap processes and fee structures.

1. beforeSwapDelta: Active influence over swaps

The beforeSwapDelta value is directly linked to Uniswap V4’s debt settlement model. In V4, swaps create temporary debt between the Router and the pool, which is later settled. Similarly, hooks can establish debt relationships with pools, allowing them to actively intervene in the swap process.

For instance, a hook could:

  • Take a portion of a user’s swap as a fee or rebate

  • Modify the trade execution path based on custom conditions

  • Provide dynamic slippage adjustments in response to market conditions

It’s important to note that hooks are not required to return a beforeSwapDelta value. Some hooks may not affect the swap mechanism at all, instead they perform independent, non-intrusive actions.

2. lpFeeOverride: Dynamic fee adjustments

lpFeeOverride is related to Uniswap V4’s dynamic fee system. In Uniswap V4, fees can change dynamically based on market conditions, but only through hooks.

The two ways dynamic fees can be implemented are:

  1. Permanent fee updates

    • A hook can call the updateDynamicLPFee function to permanently adjust the pool’s fee in response to events like high volatility or low liquidity.

    • This allows pools to increase fees during market turbulence (compensating LPs for higher risks) and lower fees when trading volume is low to encourage more swaps.

  2. Temporary fee adjustments

    • By modifying lpFeeOverride, hooks can apply custom fees only to specific users or transactions without changing the pool’s default fee.

    • For example:

      • Offering discounted fees for NFT holders

      • Charging higher fees to arbitrageurs

      • Applying custom incentives for specific trading behaviors

This flexibility allows Uniswap V4 to implement tailored fee policies at the trade level, something that traditional AMMs cannot achieve.

In summary, beforeSwap enables hooks to perform three key actions:

1. Access control

Uniswap V4 hooks can verify the sender address in the beforeSwap function, allowing developers to implement access control mechanisms. This means that hooks can enforce custom conditions on who is allowed to execute swaps. For instance, a pool could be designed so that only users holding a specific NFT can trade within it.

However, one important caveat is that users do not interact with PoolManager directly when executing swaps. Instead, they typically go through a Router contract, which then interacts with PoolManager. As a result, the sender address that a hook sees in beforeSwap is usually the Router address, not the actual user address.

Due to this, access control logic is typically implemented at the Router level, rather than inside the hook itself. The hook determines which Router should execute swaps, while the Router handles user authentication and permission enforcement.

2. Intervention in swap logic

Uniswap V4 hooks can intervene directly in the swap execution logic. Since hooks receive all relevant trade details from PoolManager, they can dynamically adjust trade execution parameters and modify outcomes.

This capability enables a wide range of use cases, such as:

  • Implementing custom swap logic tailored to specific needs

  • Adjusting execution mechanics for different types of pools

  • Optimizing swap strategies for different market conditions

By default, Uniswap V4 uses concentrated liquidity, dividing price ranges into multiple tick intervals where each tick follows the x * y = k CPMM algorithm. However, hooks can override this behavior and apply alternative swap logic.

For example, a hook could implement a StableSwap algorithm similar to Curve for stablecoin pairs, allowing for reduced slippage and improved capital efficiency, especially for large-scale trades.

3. Dynamic fee adjustments

Lastly, hooks enable dynamic adjustments to LP fees, providing greater flexibility and potential benefits to liquidity providers (LPs).

One of the most common dynamic fee models is volatility-based fee adjustments. In highly volatile conditions, LPs risk impermanent loss (IL) and loss-versus-rebalancing (LVR), which can result in financial losses. To compensate for this risk, pools can implement higher fees during periods of high volatility, increasing overall LP revenue while attracting deeper liquidity.

One important detail is that hooks cannot modify fees for all pools. Only pools that have explicitly enabled dynamic fees can have their fees adjusted by hooks. This means that users swapping in fixed-fee pools can trade without worrying about unpredictable fee changes.

How hooks are installed in the pools

So, how are hooks installed in liquidity pools? Can any hook be attached to a pool? The answer is no.

Uniswap V4 does not allow hooks to be freely attached to any pool. When PoolManager deploys a pool, it undergoes a verification process to ensure that the hook assigned to the pool meets specific conditions.

A hook contract communicates with PoolManager by encoding the functions it implements into its contract address. The key part of this encoding is the last four hexadecimal digits (16 bits) of the hook’s address. These 16 bits indicate which functions the hook has implemented.

For example, let’s assume a hook contract has the address 0x4f....00C0. The last four digits (00C0) are the critical part. 00C0 is a hexadecimal value that, when converted into binary, looks like this:

0000 0000 1100 0000

Each bit (0 or 1) in this binary representation corresponds to a specific hook function. If a bit is 1, it means the hook implements that function. If a bit is 0, the function is not implemented.

The table below outlines the meaning of each bit:

Bit Position

Function Name

13

beforeInitialize

12

afterInitialize

11

beforeAddLiquidity

10

afterAddLiquidity

9

beforeRemoveLiquidity

8

afterRemoveLiquidity

7

beforeSwap

6

afterSwap

5

beforeDonate

4

afterDonate

3

beforeSwap *(returns delta)

2

afterSwap *(returns delta)

1

afterAddLiquidity *(returns delta)

0

afterRemoveLiquidity *(returns delta)

In example 00C0 (0000 0000 1100 0000), only the 7th (beforeSwap) and 8th (afterRemoveLiquidity) bits are set to 1, meaning that this hook implements only these two functions.

The reason for encoding hook functions into the contract address itself is to reduce gas costs.

If Uniswap did not use this method, PoolManager would have no way of knowing which functions a hook has implemented. It would have to attempt to call every possible function to determine which ones exist. This would result in unnecessary function calls and wasted gas.

For example, suppose a hook only implements beforeSwap. If PoolManager doesn’t know this in advance, it would try calling other functions like afterSwap, beforeAddLiquidity, etc., leading to unnecessary transactions and higher gas costs.

By encoding function implementations directly into the contract address, PoolManager already knows which functions to execute. This allows invalid function calls to be skipped entirely, reducing gas consumption.

In the table above, the last four bits (marked as returns delta) indicate whether the hook modifies the result of a swap or liquidity event.

For instance, if a hook modifies swap execution logic, it should return a beforeSwapDelta value. The presence of this modification is indicated in the last four bits of the address, ensuring that PoolManager knows in advance whether it needs to account for these changes.

This design prevents unnecessary calculations for hooks that do not modify swap results, further optimizing gas efficiency.

Since a hook’s functionality is determined by its address, developers must manually find an appropriate contract address that encodes the correct function configuration. But how can they do this?

Ethereum’s CREATE2 opcode allows developers to deploy contracts at predetermined addresses by specifying a salt value. This technique, called "Address Mining", enables developers to search for a valid salt that produces an address with the desired last four hexadecimal digits.

The formula for an Ethereum contract address using CREATE2 is:

address = keccak256(0xff + sender + salt + keccak256(init_code))

  • 0xff → Constant prefix indicating CREATE2

  • sender → Address deploying the contract

  • salt → Developer-defined arbitrary value

  • init_code → Bytecode of the contract being deployed

By modifying the salt, developers can repeatedly generate different addresses until they find one that ends with the required 16-bit function encoding.

While CREATE2 allows developers to generate the correct hook address, manually searching for the correct salt can be extremely tedious. Additionally, testing hooks becomes inconvenient because developers must repeatedly find a new valid address each time they deploy a modified contract.

To simplify this, Uniswap provides a tool called HookMiner. This library automates the address mining process and allows developers to efficiently find valid addresses for their hooks during testing.

(V4 Hook Address Mining Tool | Source: v4hookaddressminer.xyz)

Additionally, a web-based UI tool, V4 Hook Address Miner, has been developed to make the process even easier.

This tool allows developers to:

  1. Select the functions they want in their hook.

  2. Automatically generate a salt that produces a valid address.

  3. Deploy their hook contract without needing to manually mine for a valid address.

By leveraging these tools, developers can seamlessly deploy hooks with the correct address format, making the Uniswap V4 hook ecosystem more accessible and developer-friendly.

Potential considerations

So far, we have explored how Uniswap V4 hooks function and how they enable Uniswap to expand its capabilities. However, are there any side effects introduced by these features?

Security of each pool

Although Uniswap V4 hooks have certain restrictions on installation and input/output values, there are no restrictions on how the internal logic of a hook is implemented. In other words, malicious developers could design malicious hooks that steal funds from traders or liquidity providers.

For instance, a malicious developer could exploit the dynamic fee algorithm to execute a Denial-of-Service (DoS) attack on a pool, effectively blocking user activity. A possible attack scenario could involve increasing swap fees to over 100% when a certain price condition is met, causing all swaps to fail.

Additionally, improper access control could lead to situations where a pool’s liquidity is frozen or locked permanently. In an article by Composable Security, they discuss a case where, if the beforeInitialize function is left open to be called by anyone, liquidity in the pool could be locked forever.

So, what should users be cautious about when using Uniswap?

For traders using Uniswap’s official interface, there is no need to worry about malicious hooks when swapping tokens. This is because Uniswap has integrated UniswapX, an intent-based swap execution network. When using UniswapX, the responsibility for handling security risks associated with malicious hooks falls on the fillers who process user intents. In other words, if you are swapping tokens using UniswapX within the official Uniswap interface, you do not need to worry about malicious hooks.

However, liquidity providers (LPs) need to be more cautious. When providing liquidity in Uniswap V4, the interface allows users to specify the hook address associated with the pool.

(Liquidity Provision Interface at Uniswap | Source: Uniswap Official Page)

If the specified hook has been hacked or is malicious, the provided liquidity could be frozen or stolen. Therefore, liquidity providers must be cautious when using this feature and should only use hooks that have undergone audits and have proven security guarantees.

Routing problems in Uniswap V4

How does routing work in Uniswap V4 when users request a swap?

To better understand this, let’s examine how routing has evolved in previous versions of Uniswap.

In Uniswap V3, when a user requested a swap, the request was sent to the Smart Order Router at Uniswap’s backend. This system would calculate the optimal swap route and return it to the user. The user would then execute the swap by submitting the calculated route to the Router contract in V3.

However, in July 2023, Uniswap introduced UniswapX, a decentralized intent-based swap execution protocol designed to improve swap efficiency and enhance cross-chain UX. UniswapX offloads the routing process from the centralized Smart Order Router to a decentralized network of intent processors (fillers). These fillers participate in a Dutch auction to determine who will process the swap request. The filler that offers the best trade execution is selected automatically.

The basic process in UniswapX works as follows:

  1. The user signs a Permit2 message specifying:

    • Which token they want to swap (input)

    • How much they want to receive (output)

    • Any minimum acceptable output

  2. Fillers compete in an auction to execute the trade most profitably while staying within the user’s specified constraints.

    • Suppose Alice wants to swap 1 ETH for 3,200 USDC, with a minimum acceptable output of 3,190 USDC.

    • A filler, Bob, might execute the swap on Uniswap V3 at 1 ETH → 3,199 USDC, keeping 9 USDC as profit.

  3. If another filler, Charlie, can execute the same swap at 1 ETH → 3,196 USDC (keeping only 3 USDC as profit), Charlie’s offer is chosen instead.

    • UniswapX always selects the best trade execution for the user.

  4. The winning filler submits the Permit2 signature to the Reactor contract, which executes the swap and verifies that the trade conditions are met.

Now, will this algorithm work smoothly in Uniswap V4?

Compared to Uniswap V3, routing in V4 has become significantly more complex. This is because, in addition to finding the optimal swap path, the routing algorithm must now also account for the logic embedded within each hook.

As we discussed earlier, hooks can contain arbitrary logic. Although it is possible to determine which functions a hook implements based on its address, the actual behavior of the hook cannot be known without executing it. This uncertainty makes routing in Uniswap V4 significantly more challenging.

(Routing Problem at Uniswap V4 | Source: X of Alex Nezlobin)

Due to potential security risks with hooks, Uniswap V4 routing will only occur if fillers completely understand and trust the logic of the hooks associated with liquidity pools. This means UniswapX fillers must carefully verify whether a hook has been properly audited and vetted by the community or on-chain data sources before including it in their routing algorithms.

Consequently, hooks that are widely used or integrated into pools with significant liquidity are more likely to be selected by fillers and included in UniswapX routing algorithms.

That said, fillers will always seek new hooks and pools to maximize profit opportunities. Therefore, if a hook has demonstrated reliability, it is worth considering how to incentivize fillers to include it in their routing logic.

Given these challenges, a transparent dashboard for hook-related information becomes crucial. The community has already started building such tools, with the most prominent example being HookRank, which is modeled after L2Beat for Uniswap V4 hooks.

(HookRank | Source: hookrank.io)

On HookRank, users can view:

  • The name and address of each hook

  • The total TVL (Total Value Locked) in pools associated with the hook

  • The transaction success rate for pools using that hook

Currently, since Uniswap V4 is in its early stages, the dataset is relatively small. However, as the number of hooks and V4 pools grows, tools like HookRank will become invaluable for UniswapX fillers.

By leveraging such dashboards, fillers can quickly assess the reliability and security of various hooks, allowing them to optimize routing decisions while minimizing risk exposure.

Uniswap V4 hook ecosystem

As of February 2025, Uniswap V4 is still in its early stages, having been released only a few weeks ago. However, various teams are already building products utilizing hooks on Uniswap V4.

In this section, we will explore notable projects that are leveraging Uniswap V4 hooks and examine the potential scope of protocols that can be built using this new framework.

Current hook landscape

Uniswap V4 Hook Landscape)

The diagram illustrates various use cases of Uniswap V4 Hooks across different fields, including protocols being built based on Uniswap V4 Hooks. Let's explore how Uniswap V4 Hooks can be integrated into each of these areas through their respective mechanisms.

Major use cases of hooks

MEV minimization

When people think about MEV, they often associate it with disadvantages faced by traders, such as sandwich attacks. However, the downsides of MEV in DEXs like Uniswap are also significantly impactful on liquidity providers (LPs). Simply put, LPs suffer a reduction in profitability due to MEV.

This issue has been studied under the name Loss-Versus-Rebalancing (LVR). LVR occurs because time in a DEX is divided into discrete blocks, meaning that LPs cannot dynamically manage their positions in real-time. As a result, LPs incur losses when compared to an ideal environment where they could rebalance continuously.

(LVR & IL of LP at dynamic market condition | Source: Delphi Digital)

For example, imagine that the price of ETH suddenly doubles on a centralized exchange (CEX) to $2000 while it remains at $1000 on a DEX. Arbitrageurs will take advantage of this price discrepancy by buying ETH on the DEX and selling it on the CEX, profiting from the difference. However, the LPs on the DEX cannot react instantly to this price change, and they are forced to sell ETH at a much lower price than its true market value ($2000).

Let’s assume that ETH's price suddenly drops back to $1000. Arbitrageurs will buy ETH from the CEX and sell it on the DEX to profit again. Once again, LPs are forced to execute trades at worse-than-market prices.

In other words:

  • "DEX LPs have no choice but to give away all profit opportunities from market volatility to arbitrageurs."

  • "LPs should ideally be able to dynamically rebalance their positions to capture these profits, but instead, they lose out due to their inability to do so."

This is the fundamental concept of LVR.

(Toxicity of Uniswap V3 Order Flow | Source: An Automated Market Maker Minimizing Loss-Versus-Rebalancing)

LVR has been identified as a major issue reducing LP profitability in Uniswap V3. The graph above models Uniswap V3 LPs as "traders" and calculates their PnL (Profit and Loss) based on when they exit their positions. Across almost all timeframes, LPs consistently suffer significant losses.

The root cause of the LVR problem is that LPs cannot actively respond to price changes. The most straightforward and effective way to address this issue is to redistribute part of the MEV profits to LPs via protocol mechanisms.

Arrakis Diamond Protocol – A Hook for LVR Minimization

A notable example of an LVR-minimizing Hook is the Arrakis Diamond Protocol, which draws inspiration from the Diamond Protocol. The core idea behind this Hook is as follows:

  • Arbitrageurs must deposit collateral into the Hook before executing arbitrage trades in the pool.

  • This mechanism reduces the profitability of MEV arbitrage while encouraging backrunning transactions, ultimately minimizing LVR.

Arrakis' Proof-of-Concept (PoC) implementation assumes two key conditions:

  1. Arbitrageurs fully know the incoming transactions and how they will affect the pool’s price and liquidity.

  2. Before the next block is produced, arbitrageurs will always execute trades to align the pool's token price with the external market price.

In the Arrakis Hook-enabled pool, arbitrageurs must lock up collateral before conducting arbitrage trades. This system includes two important rules:

  1. The first transaction in each block must adjust the pool’s token price to match the external market price.

    • Suppose the Uniswap V4 pool has ETH priced at $1200, while external markets show ETH at $1100.

    • The arbitrageur must execute a trade that brings the Uniswap price down to $1100 before doing anything else.

    • This adjusted price is called the committed price.

    • If the arbitrageur fails to do this, no swaps will be allowed in that block.

  2. The arbitrageur’s collateral must be large enough to bring the pool’s price back to the committed price in case of deviations.

    • The collateral size is calculated dynamically based on the total amount of trades within the block.

    • Since the arbitrageur controls which transactions enter the block, they can determine the required collateral amount accordingly.

Once the pool price is aligned with the external market, the arbitrageur’s most profitable strategy is to execute backrunning MEV transactions.

But what if they don't follow this strategy? Arrakis’ mechanism penalizes arbitrageurs who fail to backrun by preventing them from reclaiming all their collateral at the end of the block. This setup forces arbitrageurs to follow a predictable, structured trading pattern that ensures price synchronization with external markets.

To track price changes and collateral adjustments, the Arrakis Hook uses the afterSwap function. After each swap, it recalculates the amount of collateral that the arbitrageur can reclaim based on how much the pool price has deviated from the committed price.

As a result, MEV extraction is significantly reduced, minimizing LVR and improving LP profitability. Simulations that analyze the performance of LPs under different LVR-minimization strategies can further confirm this.

(Profitability of LPs at different strategies to minimize LVR | Source: LVR-minimization in Uniswap V4)

The graph above compares various LVR minimization strategies against regular Uniswap LP positions (CFMM). LPs using these strategies earn approximately 5% to 20% more profits compared to standard Uniswap LPs.

In summary, Arrakis' LVR-minimizing Hook enforces predictable arbitrage behaviors that reduce MEV leakage and significantly boost LP profitability.

Sorella Angstrom – An AVS-Based LVR Minimization Hook

Sorella's Angstrom is another App-Specific Sequencing (ASS) solution designed to minimize LVR using Uniswap V4 Hooks. Sorella combines AVS-based off-chain consensus with Uniswap V4 Hooks to create a unique MEV redistribution mechanism.

(Angstrom Architecture | Source: Sorella Blog)

The user flow in Angstrom's architecture proceeds as follows:

  1. Arbitrageurs participate in an auction to win the right to submit the first transaction in an Angstrom Hook-enabled pool.

  2. Meanwhile, traders submit their swap requests to Angstrom's AVS node network, which maintains a shared mempool.

  3. Angstrom Network processes the auction results and constructs a transaction bundle, which is then submitted on-chain.

  4. The highest-bidding arbitrageur's transaction is always placed first in the bundle.

  5. This bundle is then sent to Ethereum’s block builders and mempool, where it gets included in the blockchain.

So, how does this minimize LVR? The winning arbitrageur’s bid is distributed to LPs. Instead of arbitrageurs extracting MEV for themselves, Angstrom auctions off the MEV profits and redistributes them to LPs. This effectively minimizes LVR by compensating LPs for the losses they would normally incur due to arbitrage trading. To redistribute the auction profits, Angstrom must track LP positions and update rewards whenever liquidity is added or removed. This is achieved using beforeAddLiquidity and beforeRemoveLiquidity at Uniswap V4 Hook.

Just like Uniswap V3, Uniswap V4 tracks LP earnings using a variable called feeGrowthInside, which stores the accumulated fees per unit of liquidity in a given position. Angstrom applies the same concept to distribute auction rewards. Each time an Angstrom bundle executes, the bid amount is added to LP rewards. Whenever LPs add, update, or remove their liquidity, these values are automatically updated via the Hook functions.

Thus, Angstrom ensures that LPs receive a share of the MEV profits, effectively reducing their LVR exposure.

Volatility-based dynamic fees

LVR does not necessarily have to be solved by MEV redistribution alone. Since LVR increases during high volatility, another alternative approach is to dynamically adjust LP fees based on market conditions. Uniswap V4’s architecture makes it extremely easy to implement volatility-based fee structures via Hooks.

Many DEXs outside of Uniswap such as Trader Joe, Algebra, Hypersea have already implemented volatility-based fee mechanisms. A51 Finance and Bunni are building Hooks for Uniswap V4 that will incorporate volatility-based dynamic fee mechanisms. These adaptive fee structures will help LPs recover more profits and reduce LVR losses.

Token launch

Uniswap V4 Hooks can also be used to design innovative token launch mechanisms.Below are some of the most notable projects building on V4 Hooks for token issuance and liquidity bootstrapping.

Flaunch – Fair Launch on Uniswap V4

One major use case is Fair Launches, where everyone has an equal opportunity to buy tokens at a fixed price. Flaunch has developed a Fair Launch Hook that enables a token sale to occur entirely within a Uniswap V4 pool. Unlike traditional Fair Launch protocols, which require a separate smart contract before migrating liquidity to Uniswap, Flaunch integrates the entire process into V4.

At Flaunch, after deploying a Uniswap V4 pool, tokens are available at a fixed price. During the Fair Launch phase, all trades execute at this fixed price. Once the sale ends, tokens start trading normally on Uniswap V4.

This is implemented using the beforeSwap function. The Hook maintains a "Fair Launch Active" state. If the Fair Launch is ongoing, all swaps execute at a fixed price. Once the sale ends, trades revert to standard Uniswap behavior.

Using Uniswap V4 Hooks, Flaunch eliminates the need for separate launch contracts while simplifying token distribution.

 

Doppler by Whetstone Research – A Dutch Auction + Dynamic Bonding Curve Hook

Similar to Fair Launch mechanisms, Uniswap V4 can also bootstrap liquidity for token projects that require initial liquidity. A representative example of this is Doppler, proposed by Whetstone Research. Doppler utilizes a Dutch auction-based dynamic bonding curve algorithm to determine the initial price of a token and bootstrap liquidity within a Uniswap V4 pool.

Traditional static bonding curve mechanisms allow a token to be traded even without initial liquidity. However, they are vulnerable to sniper bots that purchase tokens at a low price and sell immediately when the price increases. Doppler addresses this issue by combining Dutch auctions with bonding curves through a Uniswap V4 Hook.

Doppler's token launch system consists of two phases:

  1. Before discovering the initial market price, the price rapidly decreases.

  2. After discovering the initial market price, the price gradually increases based on a dynamic bonding curve.

In the first phase, a Dutch auction is conducted, during which the token price decreases over time, using ticks that represent price levels in Uniswap V3 and V4. This auction continues until a buyer appears, helping to determine the token’s initial price.

(Target Tick Decay Over Time | Source: Doppler Whitepaper)

Once the initial price is discovered, the token transitions to free trading using a bonding curve mechanism. The crucial difference here is that the bonding curve is not static—it adjusts dynamically according to market conditions.

Doppler divides the bonding curve’s progression into epochs:

  • If enough tokens are sold within an epoch, the bonding curve shifts upward.

  • If not enough tokens are sold, the bonding curve shifts downward.

This approach ensures that price discovery reflects actual market demand more accurately and disrupts predictable bot behavior, making sniper attacks and MEV extraction more difficult.

(Dynamic Bonding Curves | Source: Doppler Whitepaper)

Additionally, instead of deploying all liquidity at once when the bonding curve phase ends, Doppler gradually streams liquidity into the pool over multiple epochs. This approach prevents front-running and sandwich attacks by ensuring that liquidity does not enter the pool all at once. Without this, bots could manipulate liquidity additions to interfere with normal user swaps and pool operations.

These mechanisms are implemented using Uniswap V4 Hook functions such as:

  • beforeSwap

  • afterSwap

  • beforeAddLiquidity

In summary, Doppler offers a unique liquidity bootstrapping solution by combining dutch auctions and dynamic bonding curves. This approach solves key challenges, such as discovering an appropriate initial price for the token and preventing MEV-related issues commonly seen in traditional bonding curves

The core implementation of this system relies on Uniswap V4 Hooks, making it a prime example of how Hooks can be leveraged for advanced token launch mechanisms.

Future of Uniswap V4 & DeFi

Uniswap is the most widely used DEX in Ethereum's history, and Uniswap V4 has made it more modular, efficient, and customizable. What does this mean, and how will Uniswap V4 and DeFi evolve in the future?

A more sustainable and capital-efficient DeFi market

One of the biggest limitations of AMMs has been inefficiency. Issues such as impermanent loss, LVR, and high gas costs have been persistently raised. Uniswap V4 addresses high gas costs through strategies such as the Singleton architecture, Flash Accounting, and Native ETH support. As a result, pool deployment costs have been reduced by over 99%, and swap fees are significantly lower compared to Uniswap V3. This allows Uniswap V4 to provide a much-improved user experience on the Ethereum mainnet, where transaction fees are typically expensive.

Additionally, V4 gives builders a high degree of autonomy through Hooks, enabling Uniswap to achieve capital efficiency levels that allow it to compete with centralized exchanges. Many hooks, such as app-specific sequencing and MEV minimization mechanisms, are being developed to provide LPs with greater profitability. A model where a portion of MEV revenue is redistributed to LPs is also likely to become a standard. By minimizing losses from MEV and increasing LP profitability, Uniswap V4 can help build a more sustainable DeFi structure.

Uniswap as a sustainable platform

One of the biggest innovations in Uniswap V4 is the introduction of Hooks. This feature allows developers to freely adjust the AMM structure, adopt dynamic fee models, and design custom strategies. As a result, liquidity pools optimized for various market conditions are expected to emerge, breaking away from the rigid AMM models of the past.

As discussed earlier, Uniswap V4 serves as a platform that enables the creation of liquidity pools with tailored strategies for token launches, automated fee adjustments based on volatility, MEV minimization, and maximized LP profits. This allows developers to design pools that cater to different needs and market environments.

Furthermore, although not covered in detail above, new liquidity provisioning models may also emerge, such as lending or derivatives protocols built on top of Uniswap’s liquidity and institution-focused pools that restrict access to specific users to comply with regulatory requirements.

This means that Uniswap is evolving beyond being a DEX. Moving forward, It has the potential to become a liquidity platform where various protocols are built on top of its liquidity using Hooks, fostering a growing ecosystem.

The Uniswap V4 ecosystem that emerges from this structure possesses a key characteristic: sustainability. For example, the Curve ecosystem, which peaked in early 2022, relied heavily on vote incentives driven by $CRV token rewards. As a result, it struggled to sustain itself during market downturns. In contrast, Uniswap’s ecosystem is designed as a builder-driven environment where different projects integrate unique logic to establish their competitive advantages. Instead of relying on token rewards, Uniswap V4 attracts builders by offering the flexibility and programmability of Hooks.

 

In this builder-driven ecosystem, as high-quality projects compete and collaborate to advance the protocol incrementally, Uniswap V4 is expected to create a positive feedback loop—boosting LP profitability, increasing TVL, and subsequently driving greater swap volumes, further reinforcing its position as the leading DeFi platform.

 

Follow @2077Research for more research articles and visit the website for long-form deep dives into Ethereum R&D topics. 

Related research