Access control hook on BNB Chain

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

Volume (24h)
$0
Value locked (TVL)
<$0.01
All-time volume
$15.47M
Pools using this hook
327
Swaps (24h)
0 (0 traders)
Total swaps
302,172

What it does

Gates liquidity provision on a Uniswap v4 pool so that only allow-listed provider addresses can add liquidity, 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 caller may add liquidity.
  • Exposes isAllowedProvider(address) so anyone can check whether an address is approved.
  • Has two owner-only setters (0xc4ed4354 taking address,bool and 0x65d24453 taking address[],bool) that write to the allowlist, one for single entries and one for batches.
  • Has an owner-transfer function (0x6ff1f06e taking an address) that writes slot 0, the owner address.
  • Exposes poolManager() and owner() getters; the pool manager appears to be fixed in the bytecode as an immutable.
Swap behaviour
No swap callbacks.
Liquidity behaviour
Before liquidity is added, the hook checks the allowlist for the relevant address. Unlisted providers likely hit a revert (the error selectors E1 and E3(address) are present in the bytecode), so only approved providers can add liquidity. The exact address checked (sender or the router's caller) cannot be confirmed from the decoded output. Removing liquidity has no callback and is never gated.
Fee behaviour
Uses the pool's static fee.
Owner & admin controls
A single owner address (slot 0) can add or remove providers on the allowlist, one at a time or in batches, and can hand ownership to another address via 0x6ff1f06e. No pause, upgrade or fee parameters were found. Access to the setters is presumed owner-restricted because they read the owner slot, but this is inferred from storage reads rather than verified source.

Enabled Uniswap v4 callbacks

beforeAddLiquidity

beforeAddLiquidity is used to enforce the provider allowlist and revert for addresses that are not approved.

Security & trust assessment

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

Who controls it: The owner can decide who may add liquidity, exclude any address, and transfer ownership. The owner cannot change swap behaviour, fees, or withdraw funds based on the decoded functions.

Risk to user funds: Low. The hook has no token-moving functions or delta permissions, so it cannot hold or take user or pool funds. Its only impact is blocking new liquidity additions from non-approved addresses.

Security findings

  • [info] Owner controls who can add liquidity: The allowlist in slot 1 is written only by the owner-gated functions 0xc4ed4354 and 0x65d24453, so the owner decides which addresses can provide liquidity.
  • [low] Owner can lock out new liquidity: By removing providers or never adding them, the owner can stop all new liquidity from being added to pools using this hook. Existing positions can still be removed because there is no beforeRemoveLiquidity callback.
  • [low] Ownership transferable in one step: Function 0x6ff1f06e writes the owner slot directly. If it is a plain single-step transfer, a mistaken address could permanently lose control of the allowlist.
  • [info] No fund-handling logic detected: Only beforeAddLiquidity is enabled, with no return-delta permissions and no token transfer functions among the dispatched selectors.
  • [info] Not upgradeable by appearance: The small 1685-byte runtime and the two storage slots show no proxy or delegatecall pattern, though this was not verified against source.

Contract details

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

Pools using Access control hook