Hook addresses

In Uniswap V4, a hook's permissions are read from its address, not from storage. The lowest 14 bits of the address say which callbacks the pool will call.

That means a hook cannot be deployed to just any address. It has to land on one whose last bits match its permissions.

How SuperHooks handles it

When you press Deploy, the app does this in your browser:

1. Builds the hook's deployment bytecode, including its constructor arguments.
2. Tries CREATE2 salts until the resulting address ends in the right bits. This usually takes a few thousand to a few tens of thousands of tries and finishes in a moment.
3. Simulates the deployment.
4. Sends one transaction to the deterministic CREATE2 deployer at 0x4e59b44847b379578588920cA78FbF26c0B4956C, which creates the hook at that address.

You do not need a script or a mining tool.

Permission bits

Permission	Bit	Hex
beforeInitialize	13	0x2000
afterInitialize	12	0x1000
beforeAddLiquidity	11	0x0800
afterAddLiquidity	10	0x0400
beforeRemoveLiquidity	9	0x0200
afterRemoveLiquidity	8	0x0100
beforeSwap	7	0x0080
afterSwap	6	0x0040
beforeDonate	5	0x0020
afterDonate	4	0x0010
beforeSwapReturnDelta	3	0x0008
afterSwapReturnDelta	2	0x0004
afterAddLiquidityReturnDelta	1	0x0002
afterRemoveLiquidityReturnDelta	0	0x0001

A hook with afterSwap and afterSwapReturnDelta needs an address ending in 0x0044, for example 0x…0044 or 0x…c044.

If deployment fails in simulation

The hook checks its own address in its constructor. If the permissions SuperHooks declared do not match what the contract's getHookPermissions() returns, the simulation fails and no transaction is sent. Ask SuperHooks to fix the mismatch and save the hook again.

Redeploying

Each deploy uses a fresh salt, so deploying the same hook again gives a new address. A pool is tied to the hook address it was created with. A new hook address means a new pool.