A PancakeSwap Infinity hook is an external smart contract that can change what happens before or after swaps, liquidity updates and other pool actions. Some hooks adjust fees automatically. Others require a direct approval, hold assets or issue a position token. Before using a hook-enabled pool, identify the exact contract, understand its callbacks and permissions, confirm what its audit actually covers, and prove that funds can exit through the intended workflow.

Last reviewed: October 24, 2026. PancakeSwap interfaces, hooks, supported networks, pool deployments, contract addresses and documentation can change. Treat the live application, verified explorer data and wallet confirmation as controlling information. Anyone can create a token, pool or hook. This independent guide is educational and is not financial, legal, tax, security-audit or investment advice.

Quick answer: open the Infinity pool through the verified PancakeSwap application, expand Pool Features and record the network, pool type, hook name, address and creator. Open the address in the correct block explorer, verify source code, proxy status, administrator and relevant callbacks. Determine whether the hook runs automatically or needs a separate approval and custody step. Read the actual audit scope, test with a small amount, verify the resulting events and keep a documented exit path. An Infinity label does not make every third-party hook equivalent to PancakeSwap Core.

What is PancakeSwap Infinity?

PancakeSwap Infinity is a modular exchange architecture built around Pool Managers, multiple automated-market-maker designs and optional hooks. The current system includes CLAMM and LBAMM pools, while official documentation can add other pool types. A Pool Manager coordinates pools of its type; a hook adds separate custom behavior to a particular pool.

This distinction matters during review. The Pool Manager, router, token contracts and hook are different pieces of code. Verifying one address does not verify the others.

What is an Infinity hook?

A hook is an externally deployed smart contract attached when an Infinity pool is created. It can execute logic at defined moments before or after initialization, swaps, liquidity changes and donations. PancakeSwap describes hooks as plugins for pools.

Any developer, protocol or community member can build one. Therefore, “PancakeSwap Infinity pool” identifies an architecture, not a universal security guarantee for every attached contract.

Pool Manager, router and hook are not interchangeable

Component Main role Audit question
Token contract Defines token balances and transfer behavior Is it the intended asset and network?
Pool Manager Coordinates the relevant Infinity pool type Is it an official deployment?
Universal Router Builds and executes eligible trade routes Which pools and spenders appear in the route?
Hook Adds pool-specific logic What callbacks, permissions and dependencies exist?
Custom UI Collects parameters for a specialized feature Does it encode the expected contracts and amounts?

A wallet confirmation may involve more than one component. Decode the transaction rather than assuming every address labeled “PancakeSwap” has the same function.

Can a pool change its hook?

PancakeSwap documentation states that a hook is selected during pool creation and cannot simply be changed later for that pool. A single hook contract can serve multiple pools, while each pool has one attached hook address. New logic may still appear through a new pool or through upgradeable dependencies controlled by the hook design.

Record the pool identifier as well as token symbols. Two pools for the same pair can have different types, fee logic, hook addresses and risk.

Not every Infinity pool uses a hook

Some Infinity pools display no hook feature. Others show Dynamic Fees, Fee Discount, Order Type, Shared Inventory or several behaviors represented through one attached hook or integrated design. Never infer a hook from the token pair alone.

Open Earn, select Farm/Liquidity, filter for Infinity and inspect the Pool Feature column. Then open the pool detail instead of relying only on the list badge.

Start the audit from Pool Features

PancakeSwap’s official Hooks 101 guide directs users to a pool’s Pool Features modal. For a documented hook, it can show:

  • hook name and plain-language description;
  • onchain hook address;
  • creator identity;
  • source-code link;
  • features active for that pool.

Save these details with the network and inspection date. If the interface does not expose enough information to identify the contract, do not replace that evidence with a search result or direct-message link.

Verify the network before the address

An EVM address can look identical on BNB Chain, Base, Ethereum and another compatible network while containing different code or no contract at all. Open the explorer link from the official pool page and confirm its chain.

Record chain ID, contract address and pool tokens together. An address copied without network context is incomplete evidence.

Verify the hook contract address

  1. Open PancakeSwap through a trusted bookmark.
  2. Select the intended network and Infinity pool.
  3. Open Pool Features.
  4. Copy or follow the displayed hook address.
  5. Confirm the explorer is for the intended network.
  6. Compare the complete address, not only its first and last characters.
  7. Save the pool and hook links in the audit record.

Do not accept an address supplied by a token community without reconciling it with the official pool interface.

Identify the creator without treating identity as proof

The creator may be PancakeSwap, a named partner such as Brevis, a token project or an independent developer. A known name helps locate documentation and responsibility but does not replace technical review.

For a third-party hook, find the official project announcement, repository, audit and administrator policy. A social account created recently or linked only through advertisements is not sufficient provenance.

Verified source code is the first technical checkpoint

A block explorer should show verified source that corresponds to deployed bytecode. Verification permits public inspection; it does not prove the design is safe. An unverified contract prevents meaningful public comparison and should be treated as a major warning.

Check compiler version, source files and constructor arguments. If the address is a proxy, the visible proxy source is not the application logic. Find the implementation address and review both.

Open source does not mean audited

A GitHub link demonstrates that source is available somewhere. Confirm the deployed bytecode corresponds to the reviewed source and that the repository revision matches the audit. Documentation for a current interface can point to code changed after an older report.

Look for tagged releases, commit hashes and deployment records. “Based on audited code” is weaker than an audit of the exact deployed version and configuration.

Read audit scope, not only the badge

PancakeSwap publishes audits for Infinity Core and Periphery. Those reports do not automatically cover every external hook. Read the report title, dates, commit, contracts, exclusions and unresolved findings.

Build a scope map:

  • Infinity Core or Pool Manager;
  • router and periphery;
  • the exact hook implementation;
  • custom UI or offchain components;
  • oracle, proof, keeper or relayer dependencies.

Mark each component as covered, independently reviewed or unknown. Never use a Core audit logo as evidence for unknown third-party logic.

Understand the ten hook callbacks

PancakeSwap documentation lists ten trigger points:

Callback When it runs Main review question
beforeInitialize Before pool initialization Can creation parameters be rejected or changed?
afterInitialize After initialization What state or dependencies are created?
beforeAddLiquidity Before adding liquidity Are deposits restricted or adjusted?
afterAddLiquidity After adding liquidity Are extra tokens, fees or records created?
beforeRemoveLiquidity Before removing liquidity Can exit be delayed, charged or blocked?
afterRemoveLiquidity After removal How are final balances or rewards settled?
beforeSwap Before swap execution Can fee, eligibility or amount change?
afterSwap After swap execution Are rebates, inventory or orders updated?
beforeDonate Before a pool donation What restrictions apply?
afterDonate After donation How is donated value accounted for?

A hook need not implement every callback. Identify those actually enabled and trace their effects.

Trader-focused callback review

For an ordinary swap, focus on beforeSwap and afterSwap. Ask whether the hook changes the pool fee, validates a discount, injects liquidity, updates an order or calls another contract. Determine whether the result depends on time, volume, wallet balance, volatility or an external proof.

Compare the final output and minimum received, not only the nominal pool fee. A lower fee can coexist with worse execution if liquidity is thin.

LP-focused callback review

Liquidity providers must also study add and remove callbacks. A strategy that accepts deposits cleanly can still have a complex exit. Identify withdrawal conditions, additional fees, position tokens, locks, operator dependencies and how unclaimed rewards are handled.

Test the removal workflow with a small amount before committing significant value. Do not rely on a successful swap as proof that LP withdrawal works.

Automatic hooks versus authorized hooks

PancakeSwap distinguishes hooks that execute automatically from those requiring direct user interaction.

Type Typical behavior Extra review
No separate authorization Dynamic fee or automatic eligibility check during a normal pool action Route, callback effect, fee and dependencies
User authorization required Limit order, TWAMM or managed position Spender, custody, receipt token, claim and exit path

“Automatic” does not mean risk-free. It means the hook runs through the pool action without an additional custom deposit flow.

Audit token approvals separately

An approval transaction grants a spender permission; it is not the swap or deposit itself. Read the spender and amount in the wallet. Determine whether the spender is the official router, Permit2-style component, hook or a custom position manager.

Prefer a limited allowance when the interface and workflow support it. If unlimited approval is required, document why, how to revoke it and what an attacker could do if the spender became compromised.

Direct custody changes the risk

Some specialized hooks can require assets to enter a position or strategy contract. Ask:

  • Which contract holds the tokens?
  • What represents ownership?
  • Can the position be transferred?
  • Who can pause deposits or withdrawals?
  • Which call returns unfilled or unused assets?
  • Does exit depend on a keeper, oracle or custom UI?

A receipt token is valuable only if the redemption logic remains available and correctly recognizes it.

Check administrator and upgrade powers

Inspect ownership, roles and proxy controls. A contract may be open-source while an administrator can upgrade implementation, alter fees, pause operations or change an external dependency.

Record whether control belongs to a single externally owned account, multisig, timelock or governance process. Check recent administrative transactions. A multisig lowers single-key risk only when signers and thresholds are credible.

Map external dependencies

A hook can rely on an oracle, zero-knowledge proof service, keeper, relayer, offchain API or separate inventory operator. Each dependency creates another failure mode:

  • stale or manipulated data;
  • proof generation unavailable;
  • keeper fails to execute;
  • operator pauses inventory;
  • bridge or cross-domain message delayed;
  • admin changes an endpoint or verifier.

Find documented failure behavior. A safe failure should not silently produce an economically surprising result.

Dynamic Fee Hook audit

The PancakeSwap Dynamic Fee Hook adjusts fees in response to market behavior. Official explanations describe higher charges for larger arbitrage opportunities or volatile conditions and lower charges in calmer markets.

Before a swap, check the live quote and route rather than assuming the historical base tier is the final charge. For LP evaluation, determine how fee changes affect volume, adverse selection and returns. A higher fee can protect liquidity in some conditions but does not eliminate impermanent loss.

Dynamic fee versus total execution

The cheapest displayed fee is not necessarily the best trade. Compare input amount, expected output, price impact, minimum received, gas estimate, route complexity and hook dependency. Use net output under the same assumptions when comparing a hook-enabled route with V2, V3 or another Infinity pool.

VIP Discount Hook audit

The VIP Discount Hook has used Brevis zero-knowledge infrastructure to verify qualifying trading volume for supported pools. Identify the eligible pair, time window, threshold, proof dependency and discount shown in the live interface.

A zero-knowledge proof can limit unnecessary disclosure while still introducing verifier and availability dependencies. Confirm what happens if proof generation fails: standard fee, rejected swap or another documented result.

Token Holding Fee Discount Hook audit

A holding-based hook may evaluate average CAKE balance over a period rather than only the wallet’s current balance. Moving tokens into the wallet moments before a swap may not create eligibility. Check supported pools and tiers.

Calculate the discount against the economic risk of holding CAKE. A fee saving does not protect against token-price movement, gas or poor execution.

Fee-Earning Limit Order Hook audit

PancakeSwap’s Infinity limit order is implemented as a concentrated liquidity position at a chosen price. Market activity trades through that position, converting the deposited asset while the maker can earn the configured fee on filled quantity.

This differs from a centralized exchange instruction. Audit the position contract, target price, fee tier, partial-fill behavior, unfilled withdrawal and ownership record. Confirm whether assets are automatically returned or must be claimed.

Old ORBS orders versus Infinity orders

PancakeSwap deprecated creation of its earlier ORBS-powered limit orders. Users managing an old order should follow the legacy withdrawal guidance rather than assuming Infinity controls it.

Identify the product version from its contract and interface. Similar labels do not make receipt, execution or exit procedures interchangeable.

TWAMM hook audit

A time-weighted mechanism divides a large order into smaller executions over a period. Review duration, interval logic, cancellation, unexecuted balance, price protection, keeper requirements and how fees accumulate.

Lower immediate price impact does not guarantee a better final result. The market can trend adversely throughout execution, and interruptions can leave only part of the intended trade completed.

Shared Inventory Hook audit

The Shared Inventory Hook can quote liquidity from a common inventory across several pairs when a swap needs it. PancakeSwap distinguishes this hook inventory from ordinary resident liquidity supplied directly to pools.

Identify the operator, eligible pairs, inventory custody, injection rules, withdrawal controls and what happens if the shared balance is unavailable. Retail LP returns in the pool should not be assumed identical to the operator’s shared-inventory economics.

How Smart Router can involve a hook automatically

PancakeSwap’s Universal Router searches eligible liquidity across versions and Infinity pools. A user can receive a route through a hook-enabled pool without first visiting its liquidity page. The hook’s fee or discount can then affect the quote automatically.

Expand the route before signing. Confirm pool version, intermediate tokens, expected output, price impact, fee and minimum received. If the route details are unclear, compare a smaller amount or manually exclude eligible sources where the current interface allows.

Price impact, slippage and hook fee are different

Term Meaning Main control
Hook/pool fee Charge determined by pool logic Inspect Pool Features and quote
Price impact Effect of trade size on pool pricing Reduce size or compare liquidity
Slippage tolerance Maximum accepted deterioration before revert Set deliberately
Gas Blockchain execution cost Review wallet estimate and network

Raising slippage does not lower the hook fee. It only allows a worse output before the transaction reverts and can increase exposure to adverse execution.

Audit token compatibility

Hooks and Infinity pools may not support every token behavior. Fee-on-transfer tokens, rebasing balances, restrictive transfers, blacklists or callback-enabled tokens can break assumptions. PancakeSwap’s beginner documentation warns that some pool-creation flows do not support fee-on-transfer or rebasing tokens.

Verify both token contracts and current pool documentation. A successful approval does not prove a transfer or withdrawal will behave normally.

Prove the exit path before adding liquidity

Write the exit sequence before depositing:

  1. Open the official position page.
  2. Select the exact network, pool and position.
  3. Determine whether a receipt or NFT is required.
  4. Identify the remove-liquidity or cancel function.
  5. Check penalties, fees, locks and minimum outputs.
  6. Test removal with a small position.
  7. Verify returned tokens and remaining approvals.

If exit relies solely on a custom website with no documented direct contract method, include interface availability in the risk assessment.

Run a small controlled test

A test does not prove that all amounts and market conditions are safe, but it validates the basic path. Use a non-catastrophic amount, record expected actions and stop if the wallet requests an unknown network, spender, unlimited approval or extra signature.

After confirmation, review the transaction hash, emitted events, balance changes, position ownership and approvals. Then test the planned exit where practical.

Read wallet simulation warnings

Modern wallets may simulate balance changes or flag unlimited approvals, unverified contracts and suspicious transfers. Treat warnings as evidence to investigate, not messages to dismiss because the interface looks familiar.

Simulation can be incomplete for custom hooks and external calls. A clean preview is useful but is not an audit.

Revoke approvals after the workflow

When an approval is no longer needed, review it through a trusted explorer or established allowance tool and revoke the exact spender. Revocation costs gas and does not remove assets already deposited into a strategy.

Keep required approvals only when repeated use justifies the exposure. Review again after an upgrade, security notice or change in control.

PancakeSwap Infinity hook risk matrix

Area Lower-risk signal Warning signal
Identity Address linked from official Pool Features Address supplied only through social media
Source Verified deployment and matching repository Unverified or mismatched bytecode
Audit Exact implementation and commit covered Only Infinity Core audit cited
Permissions Limited roles and documented timelock Single wallet can upgrade or seize control
Approvals Expected spender and bounded amount Unlimited approval to unknown contract
Custody Clear ownership and redemption Unclear holder or missing exit method
Dependencies Documented failure behavior Opaque oracle, keeper or operator
Exit Small withdrawal tested Deposit works but removal is unverified

Pre-swap checklist

  • Official PancakeSwap domain opened from a trusted bookmark.
  • Wallet and application show the intended network.
  • Input and output token contracts are verified.
  • Route and Infinity pool are identified.
  • Pool Features and hook address are inspected.
  • Hook creator and source are known.
  • Fee, price impact, minimum received and gas are acceptable.
  • Approval spender and amount are expected.
  • No unexplained signature or custom call appears.
  • Transaction result will be verified onchain.

Pre-liquidity checklist

  • Pool type, range or bins and hook are understood.
  • Add- and remove-liquidity callbacks are reviewed.
  • Administrator, proxy and pause powers are documented.
  • Audit covers the exact relevant implementation.
  • External oracle, proof, keeper or inventory dependencies are identified.
  • Position or receipt ownership is clear.
  • Withdrawal, partial exit and emergency path are known.
  • A small deposit and exit have been tested.
  • Impermanent loss and token risks are evaluated separately.
  • Remaining allowances will be reviewed.

Troubleshooting hook-enabled workflows

The hook is not visible in Pool Features

Confirm network, pool version and exact token pair. You may be viewing V2, V3 or another Infinity pool. Do not import a hook address manually merely to match a guide.

The swap route uses Infinity unexpectedly

The router may have selected it for the quote. Expand the route, compare outputs and inspect the pool feature before signing. Cancel if the route cannot be evaluated.

The fee differs from the advertised base tier

Check whether Dynamic Fees are active, whether a discount applied and whether the quote changed. Pool fee, gas and price impact are separate values.

A CAKE or VIP discount did not apply

Verify pool eligibility, wallet, average-balance or volume window, proof status and current tier. Do not buy more tokens until the actual requirement is clear.

The limit order filled only partly

Review remaining position, converted amount, accrued fees and current withdrawal options. Partial fill is an expected possibility, not necessarily a failure.

Remove liquidity reverts

Check token approvals, position ownership, pool state, hook-specific exit conditions, minimum outputs and gas. Preserve the error and transaction simulation; do not approve an unknown recovery contract.

The explorer shows a proxy

Find the current implementation, verify its source and inspect upgrade admin. Compare the implementation with the audit commit and recent upgrades.

The wallet requests several signatures

Separate connection, approval, permit and execution. Read every request. A familiar first signature does not make later requests safe.

Frequently asked questions

Are all PancakeSwap Infinity hooks created by PancakeSwap?

No. Official documentation states that developers, protocols and community members can deploy hooks. Verify the exact creator and address.

Does every Infinity pool have a hook?

No. Hooks are optional and deployed selectively. Check Pool Features on the exact pool.

Can a pool’s hook be changed later?

The attached hook is selected when the pool is created and is not simply replaced. However, proxy or administrative design inside a contract can still permit logic changes, so inspect upgradeability.

Can Smart Router use a hook-enabled pool automatically?

Yes. PancakeSwap states that its routing system can use eligible Infinity liquidity when it improves the route. Review the path before signing.

Does an Infinity Core audit cover a third-party hook?

Not automatically. Audit scope must name the relevant hook implementation or repository revision.

Do automatic hooks need another token approval?

Not always. Some run during the normal pool action. Specialized position or order hooks may require separate authorization and custody.

Are dynamic fees always cheaper?

No. They can increase under defined market conditions. Compare final output, gas, price impact and alternative routes.

Why did my CAKE holding discount fail?

The pool, tier, wallet or average-balance window may not qualify. Check current official requirements and the live quote.

Can a hook prevent liquidity withdrawal?

A hook can add logic around removal, and external dependencies or bugs can cause failures. Review the remove callbacks and test the exit path before committing significant funds.

Is a small successful test proof that a hook is safe?

No. It proves only that one path worked under one state and amount. It does not replace source review, audit analysis or continuous monitoring.

Final assessment

PancakeSwap Infinity hooks make pool behavior programmable. That flexibility supports dynamic fees, discounts, limit orders, time-weighted execution and shared inventory, but it expands the set of contracts and assumptions a user must understand.

A useful audit starts with the exact pool and network, continues through contract identity, callbacks, approvals, administration and dependencies, and finishes with a tested exit. Evaluate the hook actually attached to the transaction—not the feature name in isolation and not PancakeSwap’s reputation alone.

Official PancakeSwap sources

Open PancakeSwap ↗Official website