Access control hook on BNB Chain

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

Volume (24h)
$0
Value locked (TVL)
<$0.01
All-time volume
$3.34M
Pools using this hook
130
Swaps (24h)
0 (0 traders)
Total swaps
51,686

What it does

An allowlist hook that lets only approved liquidity providers add liquidity to a pool, with an owner managing the approved list.

How it works step by step

  • Enables only the beforeAddLiquidity permission; the decoded code reads the allowlist mapping (slot 1) in that callback.
  • Keeps a mapping(address => bool) of allowed providers, readable through isAllowedProvider(address).
  • The owner can add or remove providers one at a time with setAllowedProvider or in bulk with setAllowedProviders.
  • Ownership is held in slot 0 and can be handed over with transferOwnership.
  • The other hook callbacks appear in the dispatch table but are not enabled in the address permissions, so the pool manager will not call them.
Swap behaviour
No swap callbacks.
Liquidity behaviour
beforeAddLiquidity checks the allowlist mapping and presumably reverts if the caller is not an approved provider. The decoding does not show whether it checks the sender argument or something else, such as tx.origin or the router. Removing liquidity is not hooked, so anyone holding a position can withdraw it.
Fee behaviour
Uses the pool's static fee.
Owner & admin controls
The owner (slot 0) can add or remove allowed providers singly or in bulk and can transfer ownership. No pause, upgrade or fee-setting functions were found in the decoded selectors.

Enabled Uniswap v4 callbacks

beforeAddLiquidity

beforeAddLiquidity is used to gate who may add liquidity by checking the allowed-provider mapping.

Security & trust assessment

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

Who controls it: The owner can decide who may add liquidity to pools using this hook, which could exclude LPs or restrict the pool to chosen participants. It cannot change fees, pause swaps, or touch existing positions based on the decoded functions.

Risk to user funds: The hook appears to hold no funds and has no delta-returning permissions, so it cannot move or take user or pool funds. It can only block new liquidity additions, by reverting for non-allowlisted callers.

Security findings

  • [low] Owner controls who can provide liquidity: setAllowedProvider and setAllowedProviders write the slot 1 allowlist mapping, which beforeAddLiquidity reads. The owner can therefore block any address from adding liquidity, or allow any address.
  • [info] Removal and swaps are not gated: Only beforeAddLiquidity is enabled, so swaps, donations and liquidity removal never reach the hook. Revoking a provider does not trap their existing positions.
  • [info] No funds-moving logic found: There are no return-delta permissions and no token transfer selectors in the decoded code, and the storage holds only an owner and a mapping.
  • [info] Single-step ownership transfer: transferOwnership takes an address directly, with no evidence of a two-step acceptance. A wrong address could lock the allowlist permanently.
  • [info] Unverified source: The analysis comes from decoded bytecode only. The exact check in beforeAddLiquidity, such as which address is tested, cannot be confirmed.

Contract details

Verified source
No
Bytecode size
3,523 bytes
Upgradeable proxy
No
Detected patterns
ownable

Pools using Access control hook