The Dual Nature of Uniswap v4 Hook Mechanism: Innovation and Potential Risks Coexist

Uniswap v4 is set to launch, and this upgrade is ambitious. The new version will introduce several new features, including support for an unlimited number of liquidity pools for each trading pair and dynamic fees, singleton design, flash accounting, Hook mechanism, and support for the ERC1155 token standard. Utilizing transient storage technology, Uniswap v4 is expected to be released after the Ethereum Cancun upgrade.

Among many innovations, the Hook mechanism has attracted attention for its strong potential. This mechanism allows custom code to be executed at specific points in the lifecycle of a liquidity pool, greatly enhancing the pool's scalability and flexibility.

However, the Hook mechanism can also be a double-edged sword. Despite its powerful and flexible functionality, using Hooks safely presents significant challenges. The complexity of Hooks inevitably introduces new potential attack vectors. Therefore, it is necessary to systematically introduce the security issues and potential risks associated with the Hook mechanism to promote the safe development of the community. These insights will help build a more secure Uniswap v4 Hook.

This article will introduce the related concepts of the Hook mechanism in Uniswap v4 and outline the security risks that exist.

Mechanism of Uniswap V4

Before delving deeper, we need to have a basic understanding of the mechanisms of Uniswap v4. According to official announcements and the white paper, Hook, singleton architecture, and flash accounting are three important features that enable custom liquidity pools and efficient routing across multiple pools.

1.1 Hook

Hook refers to contracts that operate at different stages of the liquidity pool lifecycle. The Uniswap team aims to enable anyone to make trade-off decisions by introducing Hook. This approach allows for native support of dynamic fees, adding on-chain limit orders, or executing large orders through time-weighted average market making (TWAMM).

Currently, there are eight Hook callbacks, divided into four groups (, each group contains a pair of callbacks ):

• beforeInitialize/afterInitialize
• beforeModifyPosition/afterModifyPosition
• beforeSwap/afterSwap
• beforeDonate/afterDonate

The Uniswap team provided some examples ( such as the TWAMM Hook ) to introduce the operation method, and community participants also made some contributions. The official documentation also links to the Awesome Uniswap v4 Hooks repository, which collects more Hook examples.

1.2 Singleton, Lightning Accounting, and Lock Mechanism

The singleton architecture and lightning bookkeeping are designed to enhance performance by reducing costs and ensuring efficiency. It introduces a new singleton contract, where all liquidity pools are stored within the same smart contract. This singleton design relies on the PoolManager to store and manage the state of all pools.

The Uniswap v4 version introduces flash accounting and a locking mechanism. The locking mechanism works as follows:

1. The locker contract requests a lock on the PoolManager.

2. PoolManager adds the locker contract address to the lockData queue and calls its lockAcquired callback.

3. The locker contract executes its logic during the callback. During the execution process, interactions between the locker contract and the pool may result in a non-zero currency increment. However, at the end of the execution, all increments must be settled to zero. Additionally, if the lockData queue is not empty, only the last locker contract can perform operations.

4. The PoolManager checks the status of the lockData queue and the currency increment. After verification, the PoolManager will remove the locker contract.

In summary, the locking mechanism prevents concurrent access and ensures that all transactions can be settled. The locker contract requests locks in order and then executes transactions via the lockAcquired callback. Each pool operation will trigger the corresponding Hook callbacks before and after. Finally, the PoolManager will check the status.

This method means that the operation adjusts the internal net balance (, namely delta ), rather than executing an instant transfer. Any modifications will be recorded in the pool's internal balance, and the actual transfer will take place at the end of operation (, namely lock ). This process ensures that there are no unsettled tokens, thus maintaining the integrity of the funds.

Due to the locking mechanism, external accounts (EOA) cannot interact directly with the PoolManager. Instead, any interaction must go through a contract. This contract acts as an intermediate locker, requiring a lock request before performing any pool operations.

There are mainly two types of contract interaction scenarios:

• The locker contract comes from the official code repository or is deployed by the user. This situation can be seen as interaction through a router.

• The locker contract is integrated with the Hook in the same contract, or controlled by a third-party entity. This situation can be considered as interaction through the Hook. At this point, the Hook plays the role of both the locker contract and is responsible for handling callbacks.

Threat Model

Before discussing relevant security issues, we need to define the threat model. The main considerations are the following two scenarios:

• Threat Model I: The Hook itself is benign, but has vulnerabilities.

• Threat Model II: The Hook itself is malicious.

Next, we will discuss potential security issues based on these two threat models.

Security issues in Threat Model I 2.1

The threat model I focuses on vulnerabilities related to the Hook itself. This threat model assumes that the developers and their Hook are non-malicious. However, existing known vulnerabilities in smart contracts may also appear in the Hook. For example, if the Hook is implemented as an upgradeable contract, it may encounter issues similar to the OpenZeppelin UUPSUpgradeable vulnerability.

Given the above factors, we choose to focus on the potential vulnerabilities unique to the v4 version. In Uniswap v4, Hook is a smart contract that can execute custom logic before or after performing core pool operations on (, including initialization, modifying positions, swapping, and collecting ). While Hook is expected to implement standard interfaces, it also allows for custom logic to be included. Therefore, our discussion will be limited to the logic involving the standard Hook interface. We will then attempt to identify possible sources of vulnerabilities, such as how Hook might abuse these standard Hook functions.

Specifically, we will focus on the following two types of Hooks:

• The first type of hook is to safeguard user funds. In this case, an attacker may target this hook to transfer funds, resulting in asset loss.

• The second type of hook, which stores critical state data that users or other protocols depend on. In this case, an attacker may attempt to alter the critical state. When other users or protocols operate with incorrect states, it may pose potential risks.

Please note that hooks outside of these two ranges are not within the scope of our discussion.

After conducting an in-depth study of the Awesome Uniswap v4 Hooks repository, we discovered several serious vulnerabilities. These vulnerabilities mainly arise from the risk interactions between hooks, PoolManager, and external third parties, which can be mainly classified into two categories: access control issues and input validation issues.

Overall, we found 22 relevant projects ( excluding projects unrelated to Uniswap v4 ). Among these projects, we believe that 8 of them (36%) have vulnerabilities. Of the 8 vulnerable projects, 6 have access control issues and 2 are susceptible to untrusted external calls.

2.1.1 Access Control Issues

In this part of the discussion, we mainly focus on the potential issues that callback functions in v4 may cause, including 8 hook callbacks and lock callbacks. Of course, there are other situations that need to be verified, but those situations vary by design and are not within the scope of our discussion.

These functions should only be callable by the PoolManager and not by other addresses ( including EOA and contract ). For example, in the case where rewards are distributed by the pool key, if the corresponding function can be called by any account, then the rewards may be claimed incorrectly.

Therefore, it is crucial for hooks to establish a robust access control mechanism, especially since they can be invoked by parties other than the pool itself. By strictly managing access permissions, liquidity pools can significantly reduce the risks associated with unauthorized or malicious interactions with hooks.

2.1.2 Input Validation Issues

In Uniswap v4, due to the locking mechanism, users must obtain a lock through the contract before performing any liquidity pool operations. This ensures that the contract currently participating in the interaction is the latest locker contract.

Nevertheless, there is still a possible attack scenario where untrusted external calls occur due to improper input validation in some vulnerable Hook implementations:

• First of all, the hook does not verify the liquidity pool that the user intends to interact with. This could be a malicious liquidity pool containing fake tokens and executing harmful logic.

• Secondly, some key hook functions allow arbitrary external calls.

Untrusted external calls are extremely dangerous as they can lead to various types of attacks, including the well-known reentrancy attack.

To attack these vulnerable hooks, an attacker can register a malicious liquidity pool for their fake tokens and then call the hooks to execute operations in the liquidity pool. When interacting with the liquidity pool, the malicious token logic hijacks the control flow to carry out malicious activities.

2.1.3 Countermeasures against Threat Model I

To avoid security issues related to hooks, it is crucial to validate interactions by appropriately enforcing necessary access controls on sensitive external/public functions and validating input parameters. Additionally, reentrancy protection may help ensure that hooks are not executed repeatedly in the standard logical flow. By implementing appropriate security measures, the fund pool can reduce the risks associated with such threats.

2.2 Security Issues in Threat Model II

In this threat model, we assume that the developers and their hooks are malicious. Given the wide scope involved, we will only focus on security issues related to the v4 version. Therefore, the key is whether the provided hooks can handle the transfer or authorization of encrypted assets.

Since the method of accessing the hook determines the permissions that may be granted to the hook, we classify hooks into two categories accordingly:

• Custodial Hook ( Managed Hooks ): hooks are not entry points. Users must interact with the hook through the router (, which may be provided by Uniswap ).

• Standalone Hooks(: hooks are entry points that allow users to interact directly.

)# 2.2.1 Custodial Hook

In this case, the user's cryptocurrency assets ### include native tokens and other tokens ( that are transferred or authorized to the router. Since the PoolManager performs a balance check, malicious hooks find it difficult to directly steal these assets. However, there are still potential attack surfaces. For example, the fee management mechanism in version 4 may be manipulated by attackers through hooks.

)# 2.2.2 Independent Hook

When Hook is used as an entry point, the situation becomes more complex. In this case, since users can interact directly with the hook, the hook gains more power. Theoretically, the hook can perform any desired operation through this interaction.

In version v4, the verification of code logic is crucial. The main issue is whether the code logic can be manipulated. If the hook is upgradable, it means that a seemingly safe hook could become malicious after an upgrade, posing significant risks. These risks include:

• The upgradable proxy ### can be directly attacked (;

• Contains self-destruct logic. It may be vulnerable to attacks when selfdestruct and create2 are called together.

)# 2.2.3 Preventive Measures against Threat Model II

A crucial point is to assess whether the hook is malicious. Specifically, for hosted hooks, we should focus on the behavior of cost management; whereas for standalone hooks, the main concern is whether they are upgradable.

![Why is Hook a "double-edged sword" for Uniswap V4?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(

Conclusion

This article first provides a brief overview of the core mechanisms related to the Hook security issues of Uniswap v4. It then presents two threat models and briefly outlines the associated security risks.

In subsequent articles, we will conduct an in-depth analysis of the security issues under each threat model.