Access control hook on Optimism

Uniswap v4 Hook Contract 0x3e47e49b9ec128ea84db049a1d024b1ffa7c4800 on Optimism · Access control

Volume (24h)
$27.55K
Value locked (TVL)
$1.10K
All-time volume
$47.61K
Pools using this hook
1
Swaps (24h)
6,137 (78 traders)
Total swaps
15,891

What it does

A minimal Uniswap v4 hook that runs a check before liquidity is added to its pool, and can block additions, without changing swaps or fees.

How it works step by step

  • Implements beforeAddLiquidity, which runs before any liquidity addition to the attached pool
  • Is declared view, so it reads state and can only accept or revert the addition
  • Exposes lp() and poolManager() getters that bind it to a pool manager and LP reference
  • Enables no other callbacks, so swaps, removals, and fees are unaffected
  • Has no storage variables inferred from the bytecode
Swap behaviour
No swap callbacks.
Liquidity behaviour
beforeAddLiquidity is the only callback. It is declared as a view function, so it cannot mutate state; it appears to gate or validate liquidity additions for the pool, and may revert to block them. Removals are not hooked.
Fee behaviour
Uses the pool's static fee.
Owner & admin controls
No admin controls found.

Enabled Uniswap v4 callbacks

beforeAddLiquidity

beforeAddLiquidity: runs before liquidity is added to the pool and can revert to reject the addition.

Security & trust assessment

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

Who controls it: No privileged key or owner functions were identified in the decoded selectors, so no centralized control is evident from the bytecode alone.

Risk to user funds: The hook does not appear to hold, move or take tokens: it has no return-delta permissions and no state-changing functions were decoded. Its only effect is the ability to revert liquidity additions, which could block deposits but not withdraw existing funds.

Security findings

  • [info] Single-callback hook bound to a pool manager: The hook exposes lp() and poolManager() getters, which suggest it is bound to a specific pool manager and a specific LP token or position. The hook address also encodes only the beforeAddLiquidity permission.
  • [info] Gating logic not verifiable from bytecode: Without verified source, the exact logic of beforeAddLiquidity (whether it enforces an allowlist, a deposit cap, or a time window) cannot be confirmed from the decoded selectors alone.
  • [info] No fund-handling selectors found: The inferred storage layout is empty and no external call selectors were identified, so the hook appears not to hold or move funds itself.

Contract details

Verified source
No
Bytecode size
467 bytes
Upgradeable proxy
No

Pools using Access control hook