Uniswap v4 hooks are smart-contract plugins that can change how a pool handles swaps, fees, liquidity and other lifecycle events. They make v4 more flexible than earlier protocol versions, but they also mean that two pools with the same token pair can have very different behavior and risk. This guide explains hook permissions, interface warnings, dynamic fees, upgrade controls and the checks liquidity providers and swappers should perform before interacting.

Last reviewed: October 30, 2026. Hook deployments, interface warnings, supported networks, pool configurations and governance controls can change. Verify contract addresses and current documentation before signing. This independent guide is educational and is not financial, investment, legal or smart-contract audit advice.

What is Uniswap v4?

Uniswap v4 is a permissionless, non-custodial automated market maker that builds on the concentrated-liquidity model introduced in v3. It adds flexible fee tiers, native ETH support, a singleton architecture and programmable pools through hooks.

The singleton means v4 pools are managed within one core contract rather than deploying a separate core contract for every pool. Flash accounting tracks balance changes during an operation and settles only the net amounts at the end. These design choices can reduce costs and make complex multi-pool actions more efficient.

What is a hook in Uniswap v4?

A hook is a smart contract attached to a v4 pool at creation. It can run custom code at selected stages of the pool lifecycle. A useful analogy is a plugin: v4 Core supplies the AMM foundation, while the hook adds rules or features for one pool configuration.

Possible uses include dynamic fees, time-weighted orders, onchain limit orders, custom oracles, permission checks, automated liquidity logic and external liquidity adapters. The flexibility is broad enough that “v4 pool” alone no longer describes the complete behavior.

Hooks are not wallet plugins

A v4 hook is not a browser extension, wallet application or token installed on a device. It is onchain code called by the protocol during defined actions. A website asking users to download a “Uniswap hook extension” or enter a recovery phrase is not part of the normal flow.

The hook address is part of the pool configuration. Users interact through the Uniswap interface, another router or directly with contracts, but the hook’s logic can still affect the operation.

When can a hook run?

Uniswap v4 supports callback points before and after major lifecycle actions. A hook can be configured for some of the following categories:

  • pool initialization;
  • adding liquidity;
  • removing liquidity;
  • swapping;
  • donating assets to a pool;
  • returning custom accounting deltas for certain operations.

A hook does not automatically receive every callback. Its declared permission set determines which calls v4 Core makes.

What are hook permissions?

Hook permissions identify the lifecycle stages where custom code is allowed to execute. A dynamic-fee hook may need swap-related permissions; a compliance hook may check a user before a swap or liquidity change; another hook may react after liquidity is added.

Permissions are capabilities, not quality ratings. A broad permission can be necessary for a sophisticated product, while a narrow hook can still contain a serious bug. The user must understand why each capability exists and what the implementation does with it.

Why permissions are encoded in the address

In v4, specific bits of the hook contract address signal which callbacks are enabled. This lets PoolManager determine when it should call the hook. A developer deploys the contract at an address whose permission bits match the intended behavior.

Because the address is part of pool identity, an existing pool cannot silently attach a new address with a larger permission set. A pool using another hook address is a different pool configuration.

Immutable permissions do not guarantee immutable behavior

Fixed address bits limit callback categories, but they do not prove that all code and parameters behind a hook remain unchanged. A hook can use a proxy, read an external configuration contract, depend on an oracle or let an administrator change settings.

Ask two separate questions:

  1. Which callbacks can this address use?
  2. What can the current implementation, administrators and dependencies do inside those callbacks?

A permission set may remain constant while fee formulas, oracle sources or access rules change.

Uniswap v4 Core risk versus hook risk

Layer Role What to verify
v4 Core / PoolManager Base AMM, accounting and pool operations Correct official deployment and network
Pool configuration Tokens, fee, tick spacing and hook Every PoolKey component
Hook contract Custom lifecycle logic Permissions, code, audits and control
External contracts Oracle, vault, adapter or checker Dependencies and failure behavior
Token contracts Assets being swapped or supplied Transfer rules, supply and admin powers
Interface and router Quote and transaction construction Route, calldata, approvals and output

Uniswap v4 Core being non-upgradeable does not make every external hook immutable or endorsed by Uniswap Labs.

A v4 pool is more than a token pair

A v4 PoolKey includes the two currencies, fee configuration, tick spacing and hook address. ETH/USDC can therefore exist in several pools with different fees, ranges, hooks and behavior.

Do not choose a position solely from the token symbols. Record the full hook address and pool configuration so the position can be identified later.

Can a hook be removed from an existing pool?

The hook is part of pool identity. Removing or replacing it means using a different pool configuration, not toggling a cosmetic option on the same pool. Liquidity does not automatically migrate to another pool when a preferred hook changes.

This makes pre-deposit review important. A user should understand the attached hook before creating a position, along with how liquidity can be withdrawn if the hook or its dependencies fail.

What are Uniswap hook warnings?

The Uniswap interface can display warnings based on properties of hook code that may affect swapping, adding or removing liquidity and donations. The purpose is to give users additional information before interacting.

Warnings are not a full audit, endorsement, profitability assessment or guarantee. Uniswap Labs says information may be unavailable for new or less-used hooks and does not guarantee warning accuracy or currentness.

No Flags, Standard Flags and Dangerous Flags

Interface result Practical meaning What it does not mean
No Flags No currently recognized warning property is displayed Audited, safe, immutable or approved
Standard Flags The hook has behavior affecting a relevant operation Automatically malicious
Dangerous Flags A potentially harmful capability or effect was identified That every possible danger has been found

Read the exact flag and connect it to the hook’s intended design. Never dismiss a warning because the advertised yield is high.

Why No Flags is not a safety certificate

Automated checks can miss economic weaknesses, indirect calls or new attack patterns. A hook may rely on an unaudited oracle, an upgradeable adapter or an administrator whose key is compromised. The attached tokens can also be malicious even if the hook itself is simple.

No Flags should begin further review, not end it. Verify the address, source code, implementation, dependencies, governance and withdrawal path.

Third-party hooks are permissionless

Independent developers can deploy v4 hooks without approval from Uniswap Labs. This openness enables experimentation, but a pool’s use of Uniswap v4 does not establish who wrote the hook or whether it was audited.

Review the developer’s official domain, repository, deployment records, audit scope, bug bounty, administrator design and incident history. A copied interface or familiar logo is not proof of identity.

Hooks built or configured by Uniswap Labs

Official Labs materials now describe several hook families, including StablePair, VolatilePair, Aggregator Hooks and Permissioned Pools. These have identifiable documentation and deployment context, but users still need to confirm the correct chain, address and configuration.

An official developer does not remove price, smart-contract, token, range or governance risk. The relevant question is what the actual deployed system can do today.

Static fees versus dynamic fees

Property Static-fee pool Dynamic-fee hook
Fee value Fixed by pool configuration Can change under a formula or policy
Response to volatility No direct adjustment May increase, decrease or become directional
Predictability Simpler Requires understanding the model
LP protection Static compensation May reduce adverse-selection losses
Dependencies Fewer custom components May use observations, reference rates or admins

A dynamic fee can improve market design without guaranteeing higher net LP returns. Volume may move elsewhere if quotes are uncompetitive, and the strategy may behave differently during stress.

How dynamic fees affect swappers

A swapper may see a fee that depends on direction, volatility, pool imbalance or another state. The live quote and minimum output are more important than a fee remembered from an earlier trade.

Routers can compare hooked pools with other sources. A pool with a temporarily high fee may be excluded from the best route; a lower fee does not guarantee the best final amount if liquidity is shallow.

How dynamic fees affect liquidity providers

LPs earn fees but also trade against informed flow and arbitrage. A dynamic model can attempt to charge more when the pool risks selling at a stale price and less when incoming trades benefit inventory. Results depend on parameters, market structure and routing.

Compare fees earned with impermanent loss, inventory change, gas, incentives and the value of simply holding the assets. Headline fee APR is not the same as total return.

StablePair Hook as an example

Uniswap Labs describes StablePair Hook for assets expected to trade around a known reference rate. Within a configured band, dynamic fees create a targeted bid/ask spread. Outside that band, the mechanism can treat price-correcting and price-diverging swaps differently.

For corrective flow, a decaying-fee Dutch auction is designed to retain more rebalancing value for LPs. This model still depends on a suitable reference rate, configuration, implementation and asset quality. Two tokens targeting one dollar can diverge permanently.

VolatilePair Hook as an example

VolatilePair Hook targets markets such as ETH/USDC where fair value moves continuously. Its published design recalculates separate buy and sell fees using recent price movement. After a sharp move, the direction that would exploit a stale pool price can face greater cost.

The aim is to preserve value for LPs while maintaining competitive quotes. It does not stop ETH volatility, ensure fee revenue exceeds loss or guarantee the algorithm reacts perfectly to every event.

Aggregator Hooks

Aggregator Hooks wrap an external liquidity source so a Uniswap v4 router can treat it like a pool. Uniswap Labs launched this functionality in the Web App and API on selected networks in October 2026. A route can combine Uniswap pools and external sources and settle in one transaction.

For a swapper, this can expand available liquidity without a separate manual approval merely for the external source. It also introduces the performance and contract assumptions of the adapter and source. Review the complete route and output rather than assuming every segment is native Uniswap liquidity.

Permissioned Pools

A permissioned hook can check whether a wallet is authorized before swapping or adding liquidity. This is useful for tokenized funds or securities whose issuer must enforce holder restrictions. Approval to swap need not imply approval to LP.

The underlying v4 Core remains permissionless to deploy and integrate, while a particular hook imposes rules on its own pool. Users should identify the compliance checker, issuer controls, pause behavior and conditions for forced position unwinding.

Oracle and reference-price risk

A hook may read an oracle or a configured reference rate to calculate fees or validate activity. Failure modes include stale prices, incorrect decimals, manipulation, unavailable updates, wrong-chain data and compromised administrators.

Documentation should explain what happens when data is missing. A safe failure mode may pause a feature or use bounded behavior; silently accepting an old value can create opportunities to drain value from LPs.

Upgradeable hooks and proxy risk

A hook address may point to a proxy whose implementation can change. Review the implementation address, proxy administrator, multisig members, governance process, timelock and emergency permissions. Determine whether an upgrade can change fees, external calls or access rules while retaining the same callback permissions.

Upgradeability can repair bugs and improve market logic. It also means today’s audit may not cover tomorrow’s code. Subscribe to official upgrade announcements where meaningful funds are involved.

Configuration and governance risk

Not every important change requires new bytecode. Administrators may adjust reference rates, fee bands, decay speeds, caps, allowlists or oracle addresses. Identify which parameters are mutable and whether changes are delayed or immediately effective.

A governance-controlled hook is not automatically decentralized for the individual LP. Assess who can vote or sign, how quickly they can act and how a user can exit after a proposal.

Custom accounting deltas

Some v4 permissions allow hook logic to return custom balance deltas. This supports powerful designs but makes transaction economics less intuitive. A reviewer must trace how the hook changes what the user pays or receives and whether amounts are bounded.

Wallet previews and interface quotes should be compared with minimum outputs. Developers should test positive, negative and zero delta paths, rounding, unusual tokens and repeated calls.

Can a hook affect liquidity removal?

A hook with remove-liquidity callbacks can run before or after a withdrawal-related action. Its actual ability depends on permissions and code. The LP should understand whether it can reject, charge, redirect or condition an operation and what happens when a dependency is paused.

Do not assume every v4 position has the same exit path. Test with a small position and confirm removal through the intended position manager before committing a large amount.

Donation callbacks

Uniswap pools can receive donations, which are not the same as ordinary liquidity deposits. A hook may execute around donation actions. Users should not sign a donate transaction merely because a promotion describes it as claiming rewards or activating a pool.

Verify the method, assets and destination. Donations may be irreversible and do not necessarily create an LP position.

External calls expand the attack surface

A hook can depend on vaults, adapters, oracles, bridges or compliance contracts. Auditing only the main hook file is insufficient when value or control flows elsewhere. Each external call can introduce reentrancy, access-control, upgrade and availability risk.

Map the full call graph and identify what happens if an external contract reverts, returns unexpected data or becomes malicious.

Token risk remains separate

A well-designed hook cannot make a malicious token safe. Token contracts can impose transfer taxes, block sellers, rebase balances, pause transfers, mint supply or blacklist addresses. Concentrated ownership can also create abrupt price collapse.

Review token warnings and issuer controls separately from hook warnings. Verify both contract addresses and never infer legitimacy from a high TVL shown by one interface.

Concentrated-liquidity risk still exists

Uniswap v4 retains concentrated liquidity. An LP selects a price range; the position earns trading fees while active within that range. If price moves outside, it can become single-sided and stop earning swap fees until price returns or liquidity is repositioned.

A hook can modify fee or liquidity behavior but does not eliminate impermanent loss. Narrow ranges improve capital efficiency while increasing sensitivity to price movement and management requirements.

What the position NFT represents

The Uniswap position manager can issue an NFT representing control of a liquidity position. The NFT is not a separate promise of principal protection. Transferring or approving it can transfer authority over the position.

Never send a position NFT to someone claiming to be support. Review NFT operator approvals and position-manager permissions as carefully as token allowances.

Permit2 in a hooked-liquidity workflow

The official interface flow can include an onchain approval for Permit2, an offchain Permit2 signature and a final transaction creating the position. These are distinct actions. Confirm token, amount, spender, expiration and network at every stage.

An offchain signature can still authorize token movement under its terms even though signing it costs no gas. “No network fee” does not mean “no authority granted.”

How to verify a hook address

  1. Find the address in the developer’s official documentation.
  2. Confirm the exact blockchain network.
  3. Compare the complete address, not the first and last characters only.
  4. Open it through a reputable block explorer.
  5. Check whether source code is verified.
  6. Identify a proxy and its current implementation.
  7. Review administrator, multisig and timelock controls.
  8. Compare the permission set with the described purpose.
  9. Check audits, incidents and official announcements.
  10. Match the address shown in the liquidity transaction.

How to read a hook audit

Confirm the auditor, date, repository commit, contracts and deployment version within scope. Read unresolved findings and limitations rather than relying on a badge. An audit of a template may not cover the final configuration, proxy or external oracle.

Audits reduce uncertainty but cannot guarantee economic performance or discover every vulnerability. Multiple reviews and public testing provide useful evidence, not certainty.

TVL, volume and pool age

Total value locked, trading volume and operating history can show adoption. High TVL may also be concentrated in one depositor or driven by short-term incentives. It does not prove that administrators are safe or code is bug-free.

Compare volume with active liquidity and fees. A pool with high advertised APR but little organic volume may depend on rewards that can end abruptly.

How hooked pools affect swappers

A router may select a hooked pool because it improves the final quote. The user may not need to call the hook directly, but its fee and execution logic can affect the trade. Review the route, input, output, price impact, minimum received and wallet request.

For Aggregator Hooks, a route may use external liquidity. The final amount and transaction guarantees matter more than an assumption that every hop uses a traditional Uniswap pool.

How hooked pools affect liquidity providers

An LP accepts a wider risk stack:

Token risk + range risk + impermanent loss + hook code + administrators + dependencies + incentive risk

Model returns after all layers. A dynamic fee can reduce one form of adverse selection while introducing implementation and governance assumptions.

A cautious process for adding liquidity

  1. Open the verified Uniswap Web App.
  2. Confirm both token contracts and the correct network.
  3. Review TVL, volume and existing pools.
  4. Obtain the intended hook address from a primary source.
  5. Read every hook and token warning.
  6. Inspect permissions, source, implementation and administrators.
  7. Understand the fee model and external dependencies.
  8. Select an intentional fee configuration and price range.
  9. Review each Permit2 approval and signature.
  10. Create a small test position.
  11. Confirm the position NFT and displayed balances.
  12. Test collecting fees and removing liquidity when practical.

Monitoring after deposit

  • Whether the position is in range.
  • Current token composition and uncollected fees.
  • Dynamic-fee behavior and trading volume.
  • Hook implementation and proxy events.
  • Governance proposals and parameter changes.
  • Oracle health and reference-rate changes.
  • Token issuer pauses, upgrades or blacklists.
  • New interface warnings or security notices.
  • Approvals granted to Permit2 and position managers.

A position is not passive merely because the deposit transaction completed successfully.

Incident-response plan

  1. Stop adding liquidity or increasing approvals.
  2. Verify the report through official project and Uniswap channels.
  3. Check the exact hook, implementation, pool and network affected.
  4. Inspect whether normal removal remains available.
  5. Use a trusted device and verified interface for any exit.
  6. Reject direct-message “migration” or “rescue” links.
  7. Save transaction hashes, warnings and contract addresses.
  8. After exit, revoke unnecessary token and NFT permissions.
  9. Review connected wallets for broader compromise.

During a live exploit, rushed transactions can create a second loss. Confirm the proposed response and contract before signing.

Common Uniswap v4 hook mistakes

  • Assuming every v4 hook is built by Uniswap Labs.
  • Treating No Flags as an audit certificate.
  • Choosing a pool from token symbols alone.
  • Failing to verify the hook address and network.
  • Ignoring proxy implementations and administrator powers.
  • Looking only at advertised fee APR.
  • Assuming dynamic fees eliminate impermanent loss.
  • Confusing hook warnings with token warnings.
  • Using Max for the first position.
  • Signing Permit2 messages without reading amount and expiration.
  • Sending a position NFT to fake support.
  • Never testing the remove-liquidity path.
  • Ignoring upgrades, governance and oracle changes.

Pre-deposit hook checklist

  • Official hook address independently confirmed.
  • Correct network and PoolKey components confirmed.
  • Source code and current implementation identified.
  • Callback permissions match the stated purpose.
  • All interface warnings understood.
  • Audit scope and unresolved findings reviewed.
  • Admin, multisig, governance and timelock documented.
  • Oracle, vault and adapter dependencies reviewed.
  • Dynamic-fee calculation understood.
  • Token contracts and warnings reviewed separately.
  • Price range and out-of-range consequences accepted.
  • Emergency withdrawal route understood.

Frequently asked questions

What is a Uniswap v4 hook?

It is a smart contract attached to a v4 pool that can run custom logic during permitted lifecycle events such as swaps and liquidity changes.

Are Uniswap v4 hooks safe?

Safety depends on the individual hook, deployment, configuration, administrators and dependencies. Using v4 Core does not automatically validate third-party code.

Are all hooks made by Uniswap Labs?

No. Anyone can deploy a hook permissionlessly. Confirm the developer and contract through primary sources.

What are hook permissions?

They specify the pool lifecycle callbacks the hook can receive, including before or after swaps, liquidity changes, initialization and donations.

Why are permissions encoded in the address?

Address bits let v4 Core identify enabled callbacks efficiently. They fix callback categories for that address but do not prove the full implementation is immutable.

Can a hook be upgraded?

Some hooks can use proxies or mutable external configuration. Review the implementation and admin controls instead of assuming one address means fixed behavior.

What does No Flags mean?

It means the interface did not display a currently recognized hook warning. It does not mean audited, endorsed or risk-free.

What is a Dangerous hook warning?

It indicates that a potentially harmful property or effect was identified. Read the exact warning and avoid proceeding unless the behavior and risk are fully understood.

Does Uniswap Labs audit every hook?

No. Permissionless third-party hooks are not automatically reviewed or endorsed by Uniswap Labs.

Can a hook change swap fees?

Yes. A dynamic-fee hook can calculate fees based on market state, direction, volatility or other configured inputs.

Can a hook block liquidity removal?

Behavior depends on its permissions and code. Hooks with remove-liquidity callbacks require particular attention to exit conditions and failure modes.

Does a dynamic fee guarantee better LP returns?

No. It may reduce adverse selection, but total returns still depend on volume, price movement, range, tokens, incentives and implementation.

Does a hook eliminate impermanent loss?

No. LP inventory still changes as prices move, and concentrated liquidity can become single-sided outside the chosen range.

Can swappers use hooks without selecting them manually?

Yes. A router may select a hooked pool or Aggregator Hook when it produces a suitable route. Users should review the final quote and transaction.

Is a hook warning the same as a token warning?

No. Hook warnings concern custom pool logic; token warnings concern the asset contract and behavior. Both must be reviewed.

How can I verify a hook?

Confirm its address and network, inspect verified source and implementation, review permissions, audits, administrators, dependencies and interface warnings.

Can I remove a hook from my existing pool?

No. The hook is part of pool identity. Moving to a configuration without it requires withdrawing and using another pool.

Final takeaway

Hooks turn Uniswap v4 into a programmable liquidity platform. Dynamic fees, aggregation, permission checks and custom market structures can improve execution and capital use, but every additional behavior introduces assumptions beyond the v4 Core.

Evaluate the full PoolKey, not just the pair. Treat warnings as information rather than certification, separate immutable permissions from upgradeable behavior, and test both deposit and withdrawal with limited value. A hook should be understandable enough that the user knows who controls it, what it can call and how to exit if its assumptions fail.

Related One Crypto Library guides

Official Uniswap resources

Open Uniswap ↗Official website