Access control hook on BNB Chain

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

Volume (24h)
$0
Value locked (TVL)
$2.28
All-time volume
$1.73M
Pools using this hook
83
Swaps (24h)
0 (0 traders)
Total swaps
24,168

What it does

Gates liquidity provision on the pool: only addresses that the hook owner has allowlisted can add liquidity, while swaps and removals are untouched.

How it works step by step

  • Keeps a mapping of allowed liquidity provider addresses in storage slot 1.
  • On beforeAddLiquidity it reads that mapping and, judging by the storage reads and the absence of any other state change, reverts if the caller is not allowlisted.
  • The owner can allow or disallow a single provider with setProvider(address,bool).
  • The owner can update many providers in one call through a batch function (selector 0xb0d781bf, address[] and bool).
  • Ownership is held in slot 0 and can be handed over with transferOwnership, which reverts with ZeroOwner for a zero address.
Swap behaviour
No swap callbacks.
Liquidity behaviour
Before liquidity is added, the hook checks the allowlist mapping for the caller. The exact comparison (sender versus another address) is not visible in the decoded output, but only slot 1 is read, so it is probably the sender. Removing liquidity has no callback and is never restricted by the hook.
Fee behaviour
Uses the pool's static fee.
Owner & admin controls
A single owner (slot 0) can add or remove allowed providers one at a time or in batch, and can transfer ownership to a non-zero address. No pause, upgrade or fee parameters were found in the decoded functions.

Enabled Uniswap v4 callbacks

beforeAddLiquidity

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

Security & trust assessment

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

Who controls it: The owner can decide which addresses may add liquidity and can freeze new deposits by removing providers. It cannot stop swaps or liquidity removal through this hook, and it has no fee or fund controls.

Risk to user funds: Low. The hook holds no balances in its storage layout, has no delta permissions, and does not block removals or swaps. The only effect on users is that non-allowlisted addresses cannot add liquidity.

Security findings

  • [low] Owner controls who can provide liquidity: setProvider and the batch function write the allowlist mapping in slot 1 and are gated by the owner in slot 0 (NotOwner error). The owner can therefore block any address from adding liquidity at any time.
  • [info] Single-key ownership transfer: transferOwnership changes the owner immediately in one step, with no two-step acceptance. It rejects only the zero address (ZeroOwner), so a mistaken transfer to a wrong address cannot be undone.
  • [info] No custody or delta logic: Only beforeAddLiquidity is enabled and there are no return-delta permissions, so the hook cannot take tokens from the pool or change amounts.
  • [info] Not upgradeable by visible mechanism: The decoded dispatch contains no upgrade or delegatecall-style function, and the bytecode is small (1621 bytes). The source is unverified, so this is a limited conclusion.

Contract details

Verified source
No
Bytecode size
1,621 bytes
Upgradeable proxy
No
Detected patterns
ownable

Pools using Access control hook