Uniswap V4 Hooks: Power, Perils & Pitfalls

Updated at: March 26, 2025•6 minutes

Author: QuillAudits Team

Table of Content

Request An Audit

Follow Our Journey

Uniswap V4 Hooks: Power, Perils & Pitfalls

Uniswap V4 has finally hit Ethereum Mainnet last month, bringing a fresh wave of innovation to the DeFi space.

The big highlight? Hooks.

Think of them as plugins for liquidity pools—letting developers customize how swaps, liquidity provision, and even donations work.

Sounds cool, right? But with great power comes great attack surfaces.

The more flexible the design, the more potential for vulnerabilities. So, before you start injecting custom logic into Uniswap, let's talk about the security considerations you absolutely need to know.

What's New in Uniswap V4?

Uniswap V4 introduces some killer features:

Customizable hooks – Developers can attach logic before/after key pool operations.
Singleton design – All pools live inside one contract, the PoolManager.
Flash accounting – Transactions track balance changes in transient storage, only settling at the end.
Dynamic fees – Swap fees can be adjusted dynamically.
Native ETH support – Finally, no more WETH wrapping!

Where Hooks Fit In?

Hooks can be placed:

Before/after initializing a pool
Before/after modifying liquidity
Before/after swapping
Before/after donating liquidity

For example, when a swap happens, Uniswap first checks if a beforeSwap hook exists. If yes, it executes that logic before the swap. Once the swap is done, if an afterSwap hook exists, it executes post-swap logic.

Now, let's get into the security gotchas.

Security Considerations for Uniswap V4 Hooks

1. Reentrancy Risks in Hooks

Uniswap V4 hooks execute before and after swaps, making them a potential target for reentrancy attacks. If a hook calls an external contract before the transaction completes, an attacker could manipulate balances and drain liquidity.

Example: Vulnerable Hook with Reentrancy

The following hook allows an attacker to reenter and execute multiple swaps before the original transaction finalizes.


contract ReentrantHook {
    IPoolManager public poolManager;

    constructor(address _poolManager) {
        poolManager = IPoolManager(_poolManager);
    }

    function beforeSwap(
        address sender,
        PoolKey calldata poolKey,
        SwapParams calldata params,
        bytes calldata data
    ) external override returns (bytes4, int128) {
        // External call to another contract, allowing reentrancy
        IUniswapV4Pool(poolManager.getPool(poolKey)).swap(
            sender,
            params.zeroForOne,
            params.amountSpecified,
            params.sqrtPriceLimitX96,
            data
        );

        return (this.beforeSwap.selector, 0);
    }
}

Mitigation: Use a Reentrancy Guard


import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract SecureHook is ReentrancyGuard {
    IPoolManager public poolManager;

    constructor(address _poolManager) {
        poolManager = IPoolManager(_poolManager);
    }

    function beforeSwap(
        address sender,
        PoolKey calldata poolKey,
        SwapParams calldata params,
        bytes calldata data
    ) external override nonReentrant returns (bytes4, int128) {
        return (this.beforeSwap.selector, 0);
    }
}

2. Gas Usage and DoS Risks

Hooks with high gas consumption can lead to denial-of-service (DoS) attacks, making pools unusable due to transaction failures.

Example: Gas-Intensive Hook


contract ExpensiveHook {
    function beforeSwap(
        address sender,
        PoolKey calldata poolKey,
        SwapParams calldata params,
        bytes calldata data
    ) external override returns (bytes4, int128) {
        for (uint256 i = 0; i < 10000; i++) {
            // Unnecessary expensive computation
            keccak256(abi.encodePacked(i));
        }

        return (this.beforeSwap.selector, 0);
    }
}

Mitigation: Gas-Efficient Hooks with Limits


contract GasEfficientHook {
    uint256 public constant MAX_ITERATIONS = 100;

    function beforeSwap(
        address sender,
        PoolKey calldata poolKey,
        SwapParams calldata params,
        bytes calldata data
    ) external override returns (bytes4, int128) {
        for (uint256 i = 0; i < MAX_ITERATIONS; i++) {
            keccak256(abi.encodePacked(i)); // Gas-efficient processing
        }

        return (this.beforeSwap.selector, 0);
    }
}

3. Hook Injection & Malicious Hooks

Uniswap V4 allows pools to use custom hooks, which means malicious contracts can disguise themselves as legitimate pools and execute harmful logic.

Example: Malicious Hook That Steals Fees


contract MaliciousHook {
    address public attacker;

    constructor(address _attacker) {
        attacker = _attacker;
    }

    function afterSwap(
        address sender,
        PoolKey calldata poolKey,
        int128 amount0Delta,
        int128 amount1Delta,
        bytes calldata data
    ) external override returns (bytes4) {
        // Send part of the swapped amount to the attacker's address
        IERC20(poolKey.token0).transfer(attacker, uint256(amount0Delta) / 10);
        return this.afterSwap.selector;
    }
}

Mitigation: Hook Whitelisting


contract SecurePoolManager {
    mapping(address => bool) public approvedHooks;

    function registerHook(address hook) external {
        require(isTrusted(hook), "Hook not trusted");
        approvedHooks[hook] = true;
    }

    function isTrusted(address hook) internal view returns (bool) {
        // Only allow verified hooks
        return hook == address(0x1234...) || hook == address(0x5678...);
    }
}

4. Broken Hook Execution Order

Improper hook execution order can lead to inconsistent state updates.

Example: Hook That Modifies State Inconsistently


contract InconsistentHook {
    uint256 public lastSwapAmount;

    function beforeSwap(
        address sender,
        PoolKey calldata poolKey,
        SwapParams calldata params,
        bytes calldata data
    ) external override returns (bytes4, int128) {
        lastSwapAmount = uint256(params.amountSpecified); // Updates before swap
        return (this.beforeSwap.selector, 0);
    }

    function afterSwap(
        address sender,
        PoolKey calldata poolKey,
        int128 amount0Delta,
        int128 amount1Delta,
        bytes calldata data
    ) external override returns (bytes4) {
        require(uint256(amount0Delta) == lastSwapAmount, "State mismatch"); // Mismatch due to beforeSwap update
        return this.afterSwap.selector;
    }
}

Mitigation: Enforce Hook Consistency


contract ConsistentHook {
    uint256 public lastSwapAmount;

    function beforeSwap(
        address sender,
        PoolKey calldata poolKey,
        SwapParams calldata params,
        bytes calldata data
    ) external override returns (bytes4, int128) {
        return (this.beforeSwap.selector, 0);
    }

    function afterSwap(
        address sender,
        PoolKey calldata poolKey,
        int128 amount0Delta,
        int128 amount1Delta,
        bytes calldata data
    ) external override returns (bytes4) {
        lastSwapAmount = uint256(amount0Delta); // Only update after swap
        return this.afterSwap.selector;
    }
}

Hooks introduce powerful customization in Uniswap V4, but they also increase attack vectors. Following best practices can help prevent reentrancy, DoS attacks, malicious hooks, and state inconsistencies.

Final Thoughts

Uniswap V4 hooks open up endless possibilities, but also new security pitfalls. If you’re building custom hooks:

Inherit from BaseHook to avoid permission mismatches.
Validate return values to prevent transaction failures.
Restrict access to prevent unauthorized calls.
Audit all upgradeable contracts to mitigate centralization risks.
Validate input parameters to prevent malicious pool manipulation.
Be cautious when modifying hookDelta to avoid theft.

By following these best practices, you can leverage Uniswap V4 hooks safely and efficiently.