A field guide to programmable liquidity.

Data you can trace.

The initial curated registry contains three protocol A dynamic-fee deployments listed in its official BNB mainnet configuration. These are not presented as audited, immutable, or explorer-verified without supporting evidence.

Public BNB RPC reads scan 1,000 blocks ending three blocks behind the reported head. The scan covers protocol A CL/Bin and protocol B pool initialization, plus protocol A CL swaps. Up to 24 active CL pool IDs are resolved through the official pool-key getter, with batched token-symbol reads. Results are capped at 200 recent events. This bounded window is not a historical index and cannot establish total pool counts, daily volume, TVL, APR, or user counts.

protocol A pool pages support direct pool-key lookup beyond the rolling window. protocol B pool pages can fall outside that window. Historical analytics use a separate persistent indexer when its database is connected. Coverage, backfill progress, daily swap counts and token volumes are shown on Analytics and pool pages. An unavailable RPC is displayed explicitly. Registry counts describe this site's coverage, not the whole ecosystem.

Read the permission map.

protocol A callback bits are obtained by calling getHooksRegistrationBitmap(). CL uses liquidity callbacks; Bin uses mint/burn counterparts. protocol B permission bits are encoded in the low 14 address bits, but those bits alone do not prove the address is a valid v4 hook.

Active means a callback is enabled in the decoded bitmap. Inactive means disabled. Unknown means no reliable bitmap was obtained. A pool's configuration must also match the hook's bitmap.

A transparent ranking.

The fallback score is the number of observed events attributed to a hook within the same scan window. A hook is ranked only when that attribution exists. Ties use the contract address. Missing volume, TVL, unique-user, and growth data are not assigned invented values. The UI shows an empty ranking when evidence is insufficient.

Your wallet stays in control.

Connect an EVM browser wallet directly in BNBhooks. Account access and transactions require wallet approval. BNBhooks does not custody assets, ask for private keys, or sign for you.

protocol A pool pages support in-app CL/Bin swaps and CL position minting, withdrawal and fee collection through official contracts. Review the exact pool, recipient, token limits, Permit2 approvals and expiry. Simulation is required before signing. Quotes can change; minimum outputs and maximum inputs are enforced onchain.

Source, compiler artifact, deployment.

Ten protocol A CL strategies generate standalone Solidity and compile with Solidity 0.8.26. Download the source, ABI, creation bytecode and standard compiler input, or carry the artifact into Deploy. Parameters are immutable. Generated code is unaudited; points are activity accounting, the oracle is a tick accumulator, and the anti-JIT strategy is a position cooldown. Review these specific behaviors before using funds. Bin and v4 strategy generation are not supported by these CL templates.

The deployment tool accepts a reviewed compiler artifact with ABI and linked creation bytecode. It estimates gas, requests a wallet transaction, and waits for two confirmations. Direct CREATE cannot satisfy every hook deployment requirement; v4 address mining and CREATE2 must use the appropriate upstream tooling.

Sources & attribution

Review callback permissions, deployed bytecode, source and ABI in the contract explorer.

Licenses differ by repository and file. Restricted implementation code is not bundled. See THIRD_PARTY_NOTICES.md in the repository for the reuse record. Interface signatures are based on published protocol interfaces.

Automated analysis — not a security audit. A repository link, detected interface, submitted entry, or absence of a detected proxy is not an endorsement or safety guarantee.