Access control hook on BNB Chain

Uniswap v4 Hook Contract 0x3a5d0fa7dfb8664fdde2269900003189ecc18800 on BNB Chain · Access control

Volume (24h)
$0
Value locked (TVL)
<$0.01
All-time volume
$11.73M
Pools using this hook
350
Swaps (24h)
0 (0 traders)
Total swaps
202,077

What it does

An allowlist hook that only lets approved addresses add liquidity to the pool, with an owner who manages the list.

How it works step by step

  • Implements beforeAddLiquidity and reads a mapping(address => bool) allowlist in storage slot 1 to decide whether the liquidity provider is permitted.
  • Reverts with custom errors (E1, and E3(address) which probably carries an address) when the check fails. The exact conditions are inferred from the selectors, not confirmed.
  • Exposes isAllowedProvider(address) so anyone can check whether an address is approved.
  • The owner can update the allowlist through two functions: one taking (address,bool) for a single entry and one taking (address[],bool) for batches.
  • A function 0x6ff1f06e(address) writes the owner slot, so it most likely transfers ownership.
Swap behaviour
No swap callbacks.
Liquidity behaviour
Before liquidity is added, the hook looks up the allowlist. Providers who are not approved are most likely rejected. It is unclear whether the check applies to the sender passed by the router or to the position owner, and no remove-liquidity callback is enabled, so withdrawals are not restricted.
Fee behaviour
Uses the pool's static fee.
Owner & admin controls
The owner (slot 0, readable via owner()) can add or remove addresses from the allowlist, singly or in batches, and can most likely transfer ownership via 0x6ff1f06e(address). No pause, upgrade or fee controls were found in the dispatched functions.

Enabled Uniswap v4 callbacks

beforeAddLiquidity

beforeAddLiquidity is used to enforce the liquidity provider allowlist before a position is increased.

Security & trust assessment

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

Who controls it: The owner can block any address from adding liquidity, or approve any address, and can hand ownership to another account. It cannot move funds or change swap behaviour.

Risk to user funds: Low. The hook has no delta-returning permissions and no token transfer logic was decoded. It can only reject add-liquidity calls and cannot hold, move or block existing liquidity or swaps.

Security findings

  • [low] Owner controls who can provide liquidity: Functions 0xc4ed4354 and 0x65d24453 write the allowlist mapping and read the owner slot, so the owner alone decides which addresses can add liquidity.
  • [info] Ownership transfer without evidence of two-step: 0x6ff1f06e(address) writes the owner slot and is the only writer of it, which suggests a single-step transfer. A wrong address could permanently lock allowlist management.
  • [info] Swaps and removals are not hooked: Only beforeAddLiquidity is enabled, so the hook cannot block swaps or withdrawals and cannot take funds through return deltas.
  • [info] Allowlist logic not fully verified: Without source, the exact check in beforeAddLiquidity (which address is tested, and how E1 and E3 are triggered) is inferred from the storage reads and error selectors.

Contract details

Verified source
No
Bytecode size
1,685 bytes
Upgradeable proxy
No

Pools using Access control hook