Access control hook on Arc

Uniswap v4 Hook Contract 0x1df2971b2dfb0e80d7061dbe5e73688ba6552800 on Arc · Access control

Volume (24h)
$88.10K
Value locked (TVL)
$67.07K
All-time volume
$3.72M
Pools using this hook
3
Swaps (24h)
378 (72 traders)
Total swaps
10,437

What it does

A whitelist-based access gate that lets the owner decide which addresses can initialize pools and add liquidity to them.

How it works step by step

  • Stores an owner-managed whitelist of allowed addresses in a mapping.
  • Checks the initializing sender against the whitelist in beforeInitialize.
  • Checks the liquidity provider against the whitelist in beforeAddLiquidity and reverts if not allowed.
  • Exposes setWhitelist and isWhitelisted for owner management and lookup.
  • Uses Ownable with two-step ownership transfer.
Swap behaviour
No swap callbacks.
Liquidity behaviour
beforeAddLiquidity checks the caller against an owner-managed whitelist and reverts for non-whitelisted callers. beforeRemoveLiquidity and afterRemoveLiquidity are present as stubs that do not appear to restrict withdrawals. afterAddLiquidity and afterRemoveLiquidity are dispatched but no gating logic was confirmed for them.
Fee behaviour
Uses the pool's static fee.
Owner & admin controls
Owner (Ownable2Step: transferOwnership then acceptOwnership) can add or remove addresses from a whitelist via setWhitelist. The whitelist gates beforeInitialize and beforeAddLiquidity, so the owner decides which addresses may initialize pools and add liquidity. renounceOwnership is present but its selector suggests it is disabled (RenounceOwnershipDisabled error). No upgrade mechanism or pause function was identified.

Enabled Uniswap v4 callbacks

beforeInitialize, beforeAddLiquidity

beforeInitialize: checks whether the initializing sender is whitelisted before the pool is created. beforeAddLiquidity: checks whether the liquidity provider is whitelisted before liquidity is added.

Security & trust assessment

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

Who controls it: The owner alone controls which addresses can create pools and provide liquidity. A malicious or compromised owner could whitelist only favoured addresses or remove access for others, effectively controlling who participates. Ownership transfer is two-step, which reduces the risk of accidental transfer.

Risk to user funds: The hook does not appear to hold tokens or take fees. It can block new liquidity additions and pool initialization for non-whitelisted users, but does not seize or lock existing user funds based on the decoded functions.

Security findings

  • [info] Permissioned pool creation and liquidity: Pool initialization and liquidity provision are restricted to owner-whitelisted addresses, so the owner controls permissioning for the pool.
  • [low] Owner can change whitelist at will: Owner can add or remove whitelist entries at any time. Removing an LP from the whitelist blocks future adds but the decoded bytecode does not show forced withdrawal of existing positions.
  • [info] Two-step ownership transfer: Ownable2Step pattern (pendingOwner and acceptOwnership) is used, reducing risk of ownership loss through mistyped transfers.

Contract details

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

Pools using Access control hook