Access control hook on Ethereum

Uniswap v4 Hook Contract 0x44b9bdeb28c01f30e587b1bbf87770bec9958fc0 on Ethereum · Access control

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

What it does

A permissioned, owner-upgradeable hook that appears to restrict which routers and traders may swap and provide liquidity in a pool, using an approver and whitelist model.

How it works step by step

  • Gates swaps via beforeSwap and afterSwap checks against an enabled flag and whitelists
  • Gates liquidity adds and removes via before and after liquidity callbacks
  • Maintains router and trader whitelists managed by the owner
  • Uses an approver address and per-address nonces, suggesting signed permission flows
  • Is a UUPS proxy so the owner can upgrade the logic
Swap behaviour
beforeSwap and afterSwap read the enabled flag, router and trader whitelists and a per-address nonce, likely restricting swaps to approved participants.
Liquidity behaviour
Before/after add and remove liquidity callbacks are enabled; they read the enabled flag and whitelist mappings, likely gating which addresses may add or remove liquidity. Exact revert conditions are not determinable from the decoded bytecode.
Fee behaviour
Uses the pool's static fee as far as can be determined; no fee-setting function is clearly identified.
Owner & admin controls
Owner (ERC-173 style, transferOwnership/renounceOwnership) can set the approver, toggle enabled, whitelist routers and traders, toggle a flag at slot 2 offset 2 and set a numeric parameter via 0x51ad3ced, and upgrade the implementation via upgradeToAndCall (UUPS). Parameter names are not known without source.

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 gate swaps against the whitelist and enabled state. The hook also has an approver address and nonce mapping, suggesting signature-based approvals.

Security & trust assessment

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

Who controls it: The owner can enable or disable the hook, change the approver, whitelist or de-whitelist routers and traders, and replace the implementation entirely through UUPS upgrades, so a privileged key could block swaps and liquidity for all users or route control to malicious logic.

Risk to user funds: The hook does not show clear mechanisms to custody or transfer user tokens directly, but it can block swaps and liquidity operations via enabled and whitelist checks, and an upgrade could introduce fund-moving logic; exposure is therefore indirect but significant.

Security findings

  • [high] Upgradeable implementation controlled by owner: upgradeToAndCall lets the owner swap the implementation at any time, so hook behaviour can change without user consent.
  • [medium] Owner can disable trading and restrict participants: Swaps and liquidity operations appear gated by the enabled flag and whitelist mappings, so the owner can halt or restrict trading.
  • [medium] Approver role can gate access: Setting the approver lets the owner control which signed approvals are accepted, a further point of centralised gating.
  • [info] Unverified implementation: Proxy delegates to implementation 0x521553991534f26b9aea7d3ac6d798ade0508fc0 with no source verification, so intended behaviour cannot be fully confirmed.

Contract details

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

Pools using Access control hook