uniswap-v4-hooks

Uniswap V4 Hook Development

Build against one pinned, compatible dependency graph. Start from a pinned revision of the Uniswap V4 template or pin v4-core, v4-periphery, and the hook library to known-compatible revisions. Do not combine examples from different releases.

As of 2026-02-06 v4-periphery no longer contains BaseHook or HookMiner (PR #510). Use @openzeppelin/uniswap-hooks (what Uniswap/v4-template pins) or Uniswap/v4-hooks-public; both expose the same _before*/_after* internal-override API. HookMiner also remains at v4-periphery/test/shared/HookMiner.sol.

Before editing, inspect the project's foundry.lock, .gitmodules, and remappings. Read Hooks.sol, IHooks.sol, PoolOperation.sol, BaseHook.sol, and HookMiner.sol at those installed revisions. The links at the end are for discovery; the project's pinned dependency graph is the source of truth.

Architecture

Uniswap V4 keeps pools in a singleton PoolManager. A PoolKey selects one hook contract or no hook. The same hook contract can serve multiple pools.

The least significant 14 bits of the hook address encode callback permissions. PoolManager.initialize rejects an invalid hook address, and a maintained BaseHook validates the deployed address against getHookPermissions() in its constructor. Deploy a production hook with CREATE2 and a salt mined for the required low-bit pattern.

In a callback:

• msg.sender is PoolManager.
• The callback's sender argument is the immediate caller of the PoolManager operation. It is commonly a router, not the end user.
• hookData is caller-controlled unless a trusted integration authenticates and binds it to the operation.

An authentic PoolManager callback does not prove that the pool is authorized. Anyone can attempt to initialize a PoolKey that names the hook. A hook must either support permissionless pool creation or validate the complete intended PoolKey or PoolId. Initialization-sensitive hooks must also validate the initial price and every other required pool parameter.