Access control hook on BNB Chain

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

Volume (24h)
$0
Value locked (TVL)
<$0.01
All-time volume
$40.33M
Pools using this hook
3,696
Swaps (24h)
0 (0 traders)
Total swaps
695,509

What it does

A permissioned hook that only gates liquidity additions: the beforeAddLiquidity callback checks an address allowlist and is meant to let only approved addresses add liquidity to pools using it.

How it works step by step

  • Implements beforeAddLiquidity, the only enabled callback, which runs before any liquidity is added to a pool that uses this hook.
  • Keeps a mapping(address => bool) allowlist in storage slot 1, read by the liquidity check and written by allow and batch-allow functions.
  • Exposes allow(address,bool) and a batch variant (selector 0x9e24a6fb taking address[] and bool) so the owner can grant or revoke access per address or per list.
  • Stores a single address in slot 0 that is written by assign(address), most likely the privileged owner or admin account.
  • Exposes a view probe(address) that reads the allowlist for a given address, so the status of any address can be checked on-chain.
Swap behaviour
No swap callbacks.
Liquidity behaviour
beforeAddLiquidity checks the allowlist mapping and is expected to revert for addresses not approved, restricting who can add liquidity. Removing liquidity is not gated by this hook.
Fee behaviour
Uses the pool's static fee.
Owner & admin controls
The address in slot 0, set through assign(address), appears to control the allowlist through allow(address,bool) and the batch function. Whether that address can be changed again or is an owner with extra powers cannot be fully confirmed from the bytecode alone.

Enabled Uniswap v4 callbacks

beforeAddLiquidity

beforeAddLiquidity is used to reject liquidity additions from addresses that are not on the allowlist.

Security & trust assessment

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

Who controls it: A single key controls who may add liquidity and can reassign itself to another address, which could exclude LPs or grant access selectively.

Risk to user funds: The hook does not appear to hold, move or take user or pool funds. Its effect is to block liquidity additions, not to custody assets, and removals are not gated by it.

Security findings

  • [medium] Privileged allowlist controller: The address in slot 0 can grant or revoke liquidity-provision rights for any address via allow and the batch function, so the pool's liquidity set is controlled by one key.
  • [low] Admin reassignable: assign(address) writes the admin slot without a visible guard in the decoded selectors, so control could move to a new address if access is not checked inside the function body.
  • [medium] Liquidity-add gate can block the pool: If the controlling key is lost or the allowlist is emptied, no new liquidity can be added to pools using this hook, which may freeze LP growth for the pool.
  • [info] Source not verified: Without verified source, the exact access checks in allow, assign and the batch function cannot be confirmed; the analysis relies on decoded selectors and storage layout.
  • [info] No user fund custody: The hook does not appear to take tokens, return deltas or hold funds; it only accepts or rejects liquidity additions.

Contract details

Verified source
No
Bytecode size
867 bytes
Upgradeable proxy
No

Pools using Access control hook