Open the app

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:

PropertyValueWhy
dynamicFeetrueevery pool is initialized with fee = {{v2.dynamicFee}} and the hook returns the effective LP fee from beforeSwap
upgradeablefalsethere 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
requiresCustomSwapDatafalseempty hookData is accepted from any caller, and every rule except the pot leg applies
vanillaSwapfalsethe hook returns deltas in both swap phases
swapAccesstemporala 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 chain 4663 and the runtime code hash of each.

What a Reviewer Can Check

ClaimWhere
Routable by the Universal Router with empty hookDataSwapping and quoting
The protocol fee is read, never set; the hook never calls setProtocolFeeHook permissions
No proxy, no upgrade path, no per-pool adminImmutability and ownership
Takes are bounded by a permanent registration and by per-pool frozen capsConfig schema and limits
The base LP fee carries no protocol shareFee model
Removing liquidity is never hookedProviding liquidity
What fails closed, and what the design does not addressThreat model
Every property the contracts hold, with the enforcing checkInvariants
Source verified on the explorer, address by addressVerification