Hooklist and routing
Read the hooklist entry for the root hook, the exact flag spellings, and the current state of Uniswap routing allowlisting.
Two separate things, often confused. A hooklist entry is a public description of a hook. Routing allowlisting is what lets Uniswap's own routing quote and trade through it. A hooklist entry allowlists nothing.
The Hooklist Entry
The entry describes the root hook, 0xb3cA29cF721380CEe8b8e4755F3865Ebc68Fe8cC on chain 4663, deployed by 0xF4Ab4698554D5c95874986d5e956c62e5E6aB3eE. Its properties, in the shape Uniswap's hooklist schema expects:
| Property | Value | Why |
|---|---|---|
dynamicFee | true | every pool is initialized with fee = {{v2.dynamicFee}} and the hook returns the effective LP fee from beforeSwap |
upgradeable | false | there is no upgrade path. The root delegatecalls one immutable, code-hash-pinned accounting kernel, and every per-pool rule is frozen at creation and re-verified by hash on every callback |
requiresCustomSwapData | false | empty hookData is accepted from any caller, and every rule except the pot leg applies |
vanillaSwap | false | the hook returns deltas in both swap phases |
swapAccess | temporal | a new-token pool's guard window caps per-block quote spend on buys and blocks exact-output buys until a block fixed at creation. After that block every rule is price-based and no swap is refused on identity |
The flag set behind dynamicFee and vanillaSwap is the address's low fourteen bits, 0x28cc: beforeInitialize, beforeAddLiquidity, beforeSwap, afterSwap, beforeSwapReturnsDelta, afterSwapReturnsDelta. Removing liquidity and donating are not hooked. Hook permissions has the bit-by-bit mapping.
The entry names no audit report, because none exists. See Audit scope.
Two Spellings
Hooks.Permissions in v4-core spells the delta flags beforeSwapReturnDelta and afterSwapReturnDelta. Uniswap's hooklist schema spells them beforeSwapReturnsDelta and afterSwapReturnsDelta. A hooklist entry uses the hooklist spelling; Solidity uses the struct spelling. Neither is wrong and both appear in these docs, in the place each belongs.
Routing Allowlisting
A hook that uses beforeSwapReturnsDelta, afterSwapReturnsDelta or a dynamic fee has to be reviewed by Uniswap Labs before their routing will trade through it. The root hook uses all three, so it needs that review. The review is for routing compatibility, not a security endorsement.
Status today: the root hook, HookrModularHookV6, is on Uniswap's routing allowlist, approved in September 2026, so Uniswap's own interface and API route swaps through pools on it. The recapture root, HookrModularHookV6Wth, is a separate hook address and has not been submitted yet; pools on it trade through the Universal Router and the Hookr router either way, because the hook accepts any caller, but Uniswap's interface will not route through them until that review completes. Two things an interface has to handle.
- Allowlisting is per hook address. A new root profile means a new submission, and nothing carries over from an approved root to the next one.
- Nothing in the Hookr graph pins a Universal Router address. A pool's trusted-router slot holds
HookrKernelRouterV3, not a Universal Router, so the choice of which Universal Router build to route through belongs to whoever routes. Contracts and addresses records the two candidate addresses on chain4663and the runtime code hash of each.
What a Reviewer Can Check
| Claim | Where |
|---|---|
Routable by the Universal Router with empty hookData | Swapping and quoting |
The protocol fee is read, never set; the hook never calls setProtocolFee | Hook permissions |
| No proxy, no upgrade path, no per-pool admin | Immutability and ownership |
| Takes are bounded by a permanent registration and by per-pool frozen caps | Config schema and limits |
| The base LP fee carries no protocol share | Fee model |
| Removing liquidity is never hooked | Providing liquidity |
| What fails closed, and what the design does not address | Threat model |
| Every property the contracts hold, with the enforcing check | Invariants |
| Source verified on the explorer, address by address | Verification |