Hook 0x0838…0fc0 on Ethereum

Uniswap v4 Hook Contract 0x08382ab717d6a9f64d0d66e3c15e46c4ac790fc0 on Ethereum · Other

Volume (24h)
$0
Value locked (TVL)
$0
All-time volume
$26.93K
Pools using this hook
1
Swaps (24h)
0 (0 traders)
Total swaps
38,826

What it does

A proxy-based Uniswap v4 hook with an owner-controlled enabled flag that gates liquidity and swap callbacks; its precise trading or fee function cannot be determined without source.

How it works step by step

  • Exposes beforeSwap and afterSwap callbacks that consult a stored enabled flag
  • Exposes before and after add and remove liquidity callbacks that consult the same flag
  • Stores an owner address and supports ownership transfer and renouncement
  • Uses a UUPS-style upgradeToAndCall to change the implementation
  • Implementation logic and any fee or accounting behaviour could not be verified without source
Swap behaviour
beforeSwap and afterSwap callbacks exist and read the enabled flag; the exact swap-time logic cannot be determined from the decoded bytecode.
Liquidity behaviour
beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity and afterRemoveLiquidity callbacks are present and read the enabled flag in slot 0, but the exact logic they execute cannot be determined from the decoded bytecode without source.
Fee behaviour
Uses the pool's static fee; no fee-setting logic is visible in the decoded functions.
Owner & admin controls
Owner (OpenZeppelin Ownable pattern, slot 0x9016...) can transfer or renounce ownership; owner can call enable(bool) to toggle a bool flag stored in slot 0 that is read by the liquidity and swap callbacks, and upgradeToAndCall lets the implementation be replaced via the UUPS proxy pattern, controlled by the owner.

Enabled Uniswap v4 callbacks

beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity, afterRemoveLiquidity, beforeSwap, afterSwap

beforeAddLiquidity and afterAddLiquidity gate liquidity additions; beforeRemoveLiquidity and afterRemoveLiquidity gate liquidity removals; beforeSwap and afterSwap run around swaps; all appear to consult the enabled flag.

Security & trust assessment

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

Who controls it: The owner can toggle the enabled flag, which the callbacks read, and can upgrade the implementation to arbitrary code, giving full control over the hook's behaviour and any logic that runs on pool actions.

Risk to user funds: The hook does not appear to take custody of tokens directly from the decoded functions, but if the enabled flag blocks liquidity or swap callbacks, or the implementation is upgraded, user trades and liquidity positions could be blocked or altered.

Security findings

  • [high] Upgradeable proxy controlled by owner: Proxy delegates all calls to implementation 0x56b34b7e1889c9c6ec0aa744a402583bbecb0fc0; the owner can replace this via upgradeToAndCall, so the hook logic can change at any time.
  • [medium] Owner-toggled enabled flag gates pool actions: Slot 0 bool is written by enable and initialize and read by liquidity and swap callbacks, so the owner can block or allow pool actions.
  • [info] Single-owner control with transferOwnership and renounceOwnership: Ownership can be transferred or renounced by the owner, with no visible timelock in the decoded functions.
  • [info] Initialize entry point present: Initialize is a public nonpayable function; its protection against re-initialization could not be confirmed from bytecode alone.

Contract details

Verified source
No
Bytecode size
176 bytes
Upgradeable proxy
Yes
Detected patterns
ownable, upgradeable

Pools using Hook 0x0838…0fc0