Deployment
Chains and addresses
HookForge targets four chains first: Base, Arbitrum One,
Unichain and Robinhood Chain. The hooks are plain v4 hooks with no chain-specific
code, so they build and deploy against any chain with a PoolManager; the rest of the table is there
because the address book is generated from the same Solidity the deploy script reads.
Every address below was taken from Uniswap's published deployments and lives in
Chains.sol,
so a deploy script and this page cannot disagree.
| Chain | Chain ID | PoolManager | Hooks |
|---|---|---|---|
| ethereum | 1 |
0x000000000004444c5dc75cB358380D2e3dE08A90 |
0 |
| optimism | 10 |
0x9a13F98Cb987694C9F086b1F5eB990EeA8264Ec3 |
0 |
| bnb | 56 |
0x28e2Ea090877bF75740558f6BFB36A5ffeE9e9dF |
0 |
| unichain target | 130 |
0x1F98400000000000000000000000000000000004 |
10 |
| polygon | 137 |
0x67366782805870060151383F4BbFF9daB53e5cD6 |
0 |
| monad | 143 |
0x188d586Ddcf52439676Ca21A244753fA19F9Ea8e |
0 |
| xlayer | 196 |
0x360E68faCcca8cA495c1B759Fd9EEe466db9FB32 |
0 |
| worldchain | 480 |
0xb1860D529182ac3BC1F51Fa2ABd56662b7D13f33 |
0 |
| soneium | 1868 |
0x360E68faCcca8cA495c1B759Fd9EEe466db9FB32 |
0 |
| tempo | 4217 |
0x33620f62C5b9B2086dD6b62F4A297A9f30347029 |
0 |
| megaeth | 4326 |
0xaCB7e78fa05D562e0A5D3089ec896D57D057d38E |
0 |
| robinhood target | 4663 |
0x8366a39CC670B4001A1121B8F6A443A643e40951 |
10 |
| base target | 8453 |
0x498581fF718922c3f8e6A244956aF099B2652b2b |
10 |
| arbitrum target | 42161 |
0x360E68faCcca8cA495c1B759Fd9EEe466db9FB32 |
10 |
| celo | 42220 |
0x288dc841A52FCA2707c6947B3A777c5E56cd87BC |
0 |
| avalanche | 43114 |
0x06380C0e0912312B5150364B9DC4542BA0DbBc85 |
0 |
| ink | 57073 |
0x360E68faCcca8cA495c1B759Fd9EEe466db9FB32 |
0 |
| zora | 7777777 |
0x0575338e4C17006aE181B47900A84404247CA30f |
0 |
Deterministic addresses
A Uniswap v4 hook has to live at an address whose low fourteen bits are exactly the permission flags it declares, which is why hook addresses all end in the same handful of patterns. The deploy script mines a CREATE2 salt until the address matches, then deploys through the canonical deterministic factory, so the same hook lands on the same address on every chain.
Addresses published before a deploy are marked deterministic in the registry and on the hook page.
That means the address is known and reserved by the maths, not that there is code at it yet. The
status field is carried through the registry JSON for exactly this
reason: a client should never render a predicted address as a live one.
cd contracts
forge script script/DeployHooks.s.sol \
--rpc-url $BASE_RPC_URL --broadcast --verify