Access control hook on BNB Chain

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

Volume (24h)
$0
Value locked (TVL)
<$0.01
All-time volume
$9.95M
Pools using this hook
333
Swaps (24h)
0 (0 traders)
Total swaps
178,097

What it does

Restricts who can add liquidity to a pool: only addresses on an owner-managed allowlist of providers can add liquidity, and everyone else is rejected.

How it works step by step

  • Keeps an allowlist mapping(address => bool) of approved liquidity providers in storage slot 1.
  • On beforeAddLiquidity it reads the allowlist and reverts with a custom error if the caller is not approved. The revert reason is inferred from the E1/E3 selectors and not confirmed.
  • The owner can add or remove single addresses (0xc4ed4354 takes address,bool) or batches (0x65d24453 takes address[],bool).
  • Ownership is stored in slot 0 and can be changed by a function with selector 0x6ff1f06e (takes an address and writes slot 0), probably a transfer of ownership.
  • Exposes isAllowedProvider(address), owner() and poolManager() as read functions.
Swap behaviour
No swap callbacks.
Liquidity behaviour
Before liquidity is added, the hook checks the allowlist (slot 1) and reverts for non-approved addresses. It is unclear whether the checked address is the sender, which would be the router, or an address decoded from the hook data, so the gating target cannot be confirmed. Removing liquidity is not gated because there is no beforeRemoveLiquidity callback.
Fee behaviour
Uses the pool's static fee.
Owner & admin controls
A single owner (slot 0) can add or remove addresses from the provider allowlist, individually or in batches. An address-taking function (0x6ff1f06e) writes the owner slot, so the owner can likely hand over ownership. No pausing, upgrade or fee controls were found in the decoded functions.

Enabled Uniswap v4 callbacks

beforeAddLiquidity

beforeAddLiquidity is used to enforce the liquidity provider allowlist before any position is increased.

Security & trust assessment

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

Who controls it: The owner can block any address from adding liquidity, or allow any address to, which makes the pool effectively permissioned. The owner can also likely transfer ownership. The owner cannot change fees or touch funds as far as the decoded code shows.

Risk to user funds: Low. The hook has no return-delta permissions and no token transfer logic was found in the decoded functions, so it does not appear to hold or move funds. Its only effect is to revert liquidity additions from non-allowlisted addresses, and existing positions can still be removed.

Security findings

  • [low] Owner controls who may provide liquidity: The functions 0xc4ed4354 and 0x65d24453 write the allowlist mapping in slot 1, so the owner can approve or block any provider at will.
  • [info] Gating may apply to the router, not the end user: The decoded view shows the beforeAddLiquidity sender argument, which in Uniswap v4 is the caller of the pool manager (often a router). If the hook checks that address, allowlisting a shared router could let any user through.
  • [info] No swap or removal restrictions: Only beforeAddLiquidity is enabled, so swaps and liquidity removals are never blocked by this hook.
  • [info] Ownership transfer in a single step: The function 0x6ff1f06e takes an address and writes the owner slot with no sign of a two-step handover, so a wrong address could lock out admin control.
  • [info] No source available: The analysis relies on decoded selectors and storage reads and writes, so details such as the exact revert condition are inferred.

Contract details

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

Pools using Access control hook