Likely access control hook on Arbitrum

Uniswap v4 Hook Contract 0x2f9fa457ed6c71be5b2b52437ea6788647a7bf00 on Arbitrum · Access control

Volume (24h)
$0
Value locked (TVL)
$0
All-time volume
$0
Pools using this hook
16
Swaps (24h)
0 (0 traders)
Total swaps
0

What it does

This hook runs custom logic around pool initialization and liquidity changes, controlled by an owner-set flag, and does not alter swap fees or swap execution, so it is unclear from the bytecode whether it benefits traders or LPs.

How it works step by step

  • Hook registered for beforeInitialize, afterInitialize, and before/after add and remove liquidity callbacks only; no swap callbacks are enabled.
  • Contains an owner-based access control pattern (owner storage slot, renounceOwnership, transferOwnership, OwnableUnauthorizedAccount error).
  • Stores a boolean flag at slot 0 offset 20 which is written by the function with selector 0x73d4b549 and read in the initialize and liquidity callbacks, likely gating whether those callbacks execute logic.
  • Exposes poolManager() and getHookPermissions() accessors, indicating a standard v4 hook skeleton.
  • Imports wrapper-related selectors (underlying(), getWrapper(address)) and InvalidPoolKey(), suggesting it may be designed around a specific wrapped-token pool setup, though the exact logic cannot be confirmed from bytecode alone.
Swap behaviour
No swap callbacks.
Liquidity behaviour
Runs logic in beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity and afterRemoveLiquidity, and reads the boolean flag in those paths; the exact effect (blocking, accounting or validation) cannot be determined from decoded bytecode.
Fee behaviour
Uses the pool's static fee.
Owner & admin controls
Owner can transfer or renounce ownership and toggle the boolean flag via selector 0x73d4b549; the specific parameter that flag controls is not determinable from bytecode.

Enabled Uniswap v4 callbacks

beforeInitialize, afterInitialize, beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity, afterRemoveLiquidity

beforeInitialize and afterInitialize run checks or setup when a pool is created; beforeAddLiquidity and afterAddLiquidity and their remove counterparts run hook logic around liquidity changes; no return-delta permissions are enabled, so the hook cannot take a cut of swaps through deltas.

Security & trust assessment

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

Who controls it: The owner controls the flag and ownership, so a privileged key could restrict when liquidity can be added or removed in pools using this hook.

Risk to user funds: The hook does not enable return deltas and does not appear to hold tokens itself, but it can revert liquidity operations, which could prevent LPs from withdrawing funds while the flag is in a blocking state.

Security findings

  • [medium] Owner-toggled flag gates liquidity callbacks: A boolean in storage slot 0 offset 20 is written by an owner-accessible function and read by the liquidity and initialize callbacks, so the owner may be able to block or alter liquidity operations on pools using this hook.
  • [info] Ownership can be renounced or transferred: renounceOwnership and transferOwnership are present; a transfer to a wrong address would hand control to an unintended party, and renouncing would leave the flag permanently fixed.
  • [low] Liquidity callbacks can revert: Before-liquidity hooks that check a flag can revert LP deposits or withdrawals, which could lock liquidity if the flag is set to a blocking state.
  • [info] Wrapper and underlying dependency: Selectors for underlying() and getWrapper(address) suggest reliance on external wrapper contracts whose behaviour is outside this hook's control.

Contract details

Verified source
No
Bytecode size
3,752 bytes
Upgradeable proxy
No
Detected patterns
ownable

Pools using Likely access control hook