Access control hook on BNB Chain

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

Volume (24h)
$0
Value locked (TVL)
<$0.01
All-time volume
$4.10M
Pools using this hook
145
Swaps (24h)
0 (0 traders)
Total swaps
62,550

What it does

A liquidity-gating hook that checks each add-liquidity request against an allowlist of providers before the position is added, so only approved addresses can deposit into the pool.

How it works step by step

  • Runs a check in beforeAddLiquidity, which is the only enabled callback.
  • Looks up the sender against a mapping(address => bool) allowlist in storage slot 1 via isAllowedProvider.
  • Owner can add or remove providers in batch (selector 0x65d24453 takes an address array and a bool) or individually (0xc4ed4354 takes an address and a bool).
  • Stores an owner address in slot 0, which is changed by the function at selector 0x6ff1f06e, and exposes owner() and poolManager() getters.
  • Does not implement swap, donation, fee or return-delta logic.
Swap behaviour
No swap callbacks.
Liquidity behaviour
beforeAddLiquidity checks the caller against the provider allowlist and is expected to revert for non-approved providers. Removing liquidity has no hook callback.
Fee behaviour
Uses the pool's static fee.
Owner & admin controls
The owner (storage slot 0, set via the function at 0x6ff1f06e) can add or remove allowed liquidity providers in single or batch calls. Ownership transfer or renunciation through 0x6ff1f06e is inferred from the decoded layout and has not been confirmed in source.

Enabled Uniswap v4 callbacks

beforeAddLiquidity

beforeAddLiquidity is used to restrict which addresses may add liquidity to the pool by checking the allowlist.

Security & trust assessment

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

Who controls it: The owner key alone decides who may provide liquidity and can add or remove providers at any time.

Risk to user funds: The hook does not take custody of tokens or change swap or fee flows. It can block new deposits but cannot move or seize funds already in the pool, based on the decoded functions.

Security findings

  • [medium] Owner-controlled liquidity allowlist: The owner can grant or revoke liquidity provision rights for any address, and a revoked provider cannot add new liquidity. Existing positions are not clearly affected by the decoded logic.
  • [medium] Single-owner key: The owner is a plain address in storage slot 0 with no evident timelock or multisig, so one compromised key can change the allowlist at will.
  • [low] Revert-based gating on pool entry: Because beforeAddLiquidity reverts for non-approved callers, legitimate LPs using routers or intermediaries may be blocked if the router address is not on the allowlist.
  • [info] Unverified bytecode: No verified source is available, so behaviour is inferred from selectors and storage layout and may differ from the actual implementation.

Contract details

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

Pools using Access control hook