Dynamic fee hook on Ethereum

Uniswap v4 Hook Contract 0x0c32fafabf58f22a7e47e8853f7606f441418145 on Ethereum · Dynamic fee

Volume (24h)
$0
Value locked (TVL)
$0
All-time volume
$8.12M
Pools using this hook
1
Swaps (24h)
0 (0 traders)
Total swaps
9,015

What it does

Adjusts swap and liquidity-removal outcomes with return-delta accounting, likely using a configurable fee and a whitelist, though the exact behaviour is unverified without source.

How it works step by step

  • Runs logic after each swap and can adjust the swap result through a return delta
  • Runs logic after liquidity removal and can adjust that result through a return delta
  • Reads and writes a uint24 value in storage, likely a configurable fee
  • Checks a whitelist of addresses via isWhitelist
  • Calls the PoolManager through unlock, take, mint and burn to settle currency and ERC6909 claims
Swap behaviour
afterSwap runs after each swap and can take or give currency through its return delta, reading a stored fee-related value.
Liquidity behaviour
afterRemoveLiquidity is enabled with a return delta, so the hook can take or credit a currency amount when liquidity is removed; it also reads slot 3 during removal.
Fee behaviour
Likely reads or writes a uint24 fee value (slot 0 via 0x79ed9349 setter and afterSwap reads), suggesting a configurable fee, but the exact fee logic cannot be confirmed from decoded bytecode alone.
Owner & admin controls
Selector 0x79ed9349 (uint24 argument) writes storage slot 0 and 0x240e5259 writes slot 1; these look like owner-facing setters such as a fee or parameter update, and 0x1749201b reads slot 3 which is likely the owner or admin address. No pause or upgrade functions were identified, but the exact access check cannot be confirmed without source.

Enabled Uniswap v4 callbacks

afterRemoveLiquidity, afterSwap, afterSwapReturnDelta, afterRemoveLiquidityReturnDelta

afterSwap: runs logic after each swap and reads/writes hook state. afterSwapReturnDelta: lets the hook take or give currency out of the swap result. afterRemoveLiquidity: runs logic after liquidity removal. afterRemoveLiquidityReturnDelta: lets the hook take or give currency out of the liquidity removal result.

Security & trust assessment

Risk level: medium (decoded bytecode, low confidence).

Who controls it: Privileged setter functions appear to exist, so a single key could alter stored parameters that affect swap and removal outcomes; the caller check is not verifiable without source.

Risk to user funds: The hook can take or credit currency during swaps and liquidity removal through return deltas and can mint or burn ERC6909 claims, so it can affect amounts users receive; it does not appear to hold funds directly, but the balance paths cannot be fully verified without source.

Security findings

  • [medium] Hook takes currency via return deltas: Return-delta permissions on swap and remove-liquidity let the hook take a share of user flows, and the bytecode also calls take, mint, burn and unlock, so the hook moves currency through the PoolManager.
  • [medium] Whitelist gating of users: The bytecode contains a whitelist check (isWhitelist) and an external call that can alter fees or access, meaning some users may be treated differently.
  • [medium] Possible unguarded parameter setters: Setter selectors write to storage without an identifiable access check in decoded form, so if unguarded any caller could change parameters; this must be confirmed in source.
  • [info] Self-unlock and ERC6909 accounting: The hook self-unlocks the pool manager via unlockCallback and claims ERC6909 balances, a pattern that needs careful review of accounting.

Contract details

Verified source
No
Bytecode size
11,728 bytes
Upgradeable proxy
No
Detected patterns
erc6909-claims, moves-currency, return-delta, self-unlock

Pools using Dynamic fee hook