Access control hook on Ethereum

Uniswap v4 Hook Contract 0x6546c9758d947be900c28db2aba60d99640f0fc0 on Ethereum · Access control

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

What it does

An upgradeable, owner-managed hook that gates liquidity and swap callbacks behind an enabled flag and whitelist, with router allowlisting, as far as the decoded bytecode indicates.

How it works step by step

  • Stores an enabled boolean that can be toggled by the owner via enable()
  • Maintains a whitelist mapping of addresses updated by updateWhitelist()
  • Maintains a routers mapping of allowed routers updated by updateRouters()
  • Runs callbacks before and after add liquidity, remove liquidity and swap
  • Is an ERC1967 UUPS proxy whose implementation can be upgraded by the owner
  • Uses OpenZeppelin-style Ownable with renounceOwnership and transferOwnership
Swap behaviour
beforeSwap and afterSwap are enabled and read the enabled flag and whitelist, so swaps may be restricted or observed; exact logic cannot be confirmed without source.
Liquidity behaviour
Before and after add and remove liquidity callbacks are enabled, and they read the enabled flag and whitelist mapping, which suggests liquidity actions may be gated to whitelisted addresses while the hook is enabled.
Fee behaviour
Uses the pool's static fee; no fee-setting logic is visible in the decoded selectors.
Owner & admin controls
Owner (OpenZeppelin Ownable pattern, slot 0x9016...) can renounce or transfer ownership, enable or disable the hook, update whitelist and routers mappings, and upgrade the implementation via upgradeToAndCall (UUPS, ERC1967 slot). The initialize function sets the first owner and an enabled flag.

Enabled Uniswap v4 callbacks

beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity, afterRemoveLiquidity, beforeSwap, afterSwap

beforeAddLiquidity and afterAddLiquidity gate liquidity additions; beforeRemoveLiquidity and afterRemoveLiquidity gate or observe liquidity removals; beforeSwap and afterSwap check the enabled flag and whitelist and may restrict or observe swaps.

Security & trust assessment

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

Who controls it: The owner controls the enabled switch, the whitelist and router allowlists, and the implementation via UUPS upgrades, so a privileged key could block liquidity or swaps for non-whitelisted users or replace the logic entirely.

Risk to user funds: The hook does not appear to take custody of tokens directly, but it can revert add, remove and swap calls through its gating logic, and an upgrade could change its behaviour to hold or move funds. Source is unverified, so the exact effect is uncertain.

Security findings

  • [high] Upgradeable proxy controlled by owner: upgradeToAndCall lets the owner swap the implementation at any time, so the behaviour of the hook can change without notice.
  • [medium] Owner can gate or disable hook callbacks: The enabled flag and whitelist can be used to block liquidity actions and swaps for users who are not whitelisted.
  • [medium] Single-key ownership without timelock: Ownership can be transferred or renounced by a single owner key with no timelock visible in the bytecode.
  • [info] Router allowlist present: Router allowlist suggests only approved routers may interact, which can restrict access to the pool.

Contract details

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

Pools using Access control hook