How to Audit a Uniswap V4 Hook Before Deploying Capital: Smart Contract Review Checklist

Uniswap V4 introduced hooks—custom smart contracts that intercept and extend core swap and liquidity operations with arbitrary logic. A hook can execute before or after a swap, modify fees dynamically, enforce special conditions on liquidity provision, or integrate external oracles. This flexibility is powerful; it is also a direct vector for loss. A malicious or poorly audited hook can drain liquidity, manipulate prices, extract MEV unfairly, or redirect fees to an unauthorized address. Unlike earlier Uniswap versions, where the core protocol itself was the only trusted surface, V4 pushes verification responsibility directly onto liquidity providers and traders who choose to interact with a pool.

An LP who deposits $100,000 into a V4 pool with a custom hook has approximately 30 seconds to several minutes to understand what that hook actually does. Reading smart contract code is not optional for capital deployment in this environment. A structured audit checklist—covering permissions, upgradability, external calls, fee logic, and behavioral edge cases—can reduce the risk of deploying into a trap. This is not a substitute for a formal security audit by a professional firm, but it provides a framework that any experienced developer or motivated investor can follow to identify obvious red flags before committed funds are irretrievable.

Understanding Uniswap V4 hook execution flow

Uniswap V4 uses a hook contract to define callbacks that run at specific points in the protocol’s lifecycle. When a swap occurs, the hook can intercept before the swap executes (beforeSwap), after the swap settles (afterSwap), before liquidity is added (beforeAddLiquidity), and after liquidity is removed (afterRemoveLiquidity). The hook contract inherits from a base interface and defines which callbacks it implements by setting specific flags in the initialization parameters. A hook that implements no callbacks is still deployed, but it becomes a no-op—code that exists but takes no action.

The critical insight is that a hook’s position in the execution flow determines what it can observe and modify. A beforeSwap hook sees the proposed swap parameters and can reject or alter them before any state change occurs. An afterSwap hook runs after the swap completes and can enforce invariants, capture fees, or trigger external logic. The order matters because a beforeSwap modification can reshape the input that an afterSwap hook receives. If a hook claims to “ensure fair pricing” but implements its check afterSwap, it may validate a price that was already manipulated by an earlier step.

For an LP auditing a hook, the first step is mapping this execution sequence in writing. Document what callbacks the hook implements, in what order they are invoked relative to the core swap or liquidity operation, and what state the pool reaches at each step. This straightforward exercise often reveals logical inconsistencies. A hook that modifies the swap amount after observing the pool’s current price, for instance, creates a different risk profile than a hook that rejects the swap if pricing deviates beyond a threshold. The same hook address and description can conceal either behavior.

Permission boundaries and ownership risks

A Uniswap V4 hook contract must define who can call which functions. Ideally, core pool operations (swap, liquidity management) are executed only through the PoolManager, never directly by user calls. Fee extraction, emergency pauses, or parameter changes may have their own access controls—often managed through an owner address, a multi-signature wallet, or a governance contract. The first red flag is a hook that allows any address to call sensitive functions, such as withdrawing accumulated fees, pausing the hook, or changing fee parameters. Such a design is not necessarily hostile; it may be an oversight. But deploying capital into a pool where an unknown address can lock all liquidity or redirect fees is economically indistinguishable from handing control to that address.

Ownership structure is equally important. A single-address owner gives one person or wallet complete control over the hook’s future behavior. That owner can upgrade the hook logic (if the code is upgradeable), withdraw fees, or modify fee structures without further approval. For high-value pools, a multi-signature requirement or timelock—a delay between announcing a change and executing it—significantly reduces the risk of sudden, coordinated attacks. A timelock of 48 hours gives the community time to withdraw liquidity if an announced change is deemed unacceptable. A 5-minute timelock may be window dressing that does not meaningfully increase safety.

The hook’s relationship to the PoolManager itself is also worth checking. The PoolManager has power to add or remove liquidity from any pool and to trigger hook callbacks. If a hook somehow gains escalated permissions to the PoolManager—or if the PoolManager’s access control is weak—a compromise of the hook could affect other pools. Uniswap V4 is designed to prevent this cross-contamination by isolating pools and their associated hooks, but integration errors or advanced patterns can introduce unexpected privilege escalation. Verify that the hook never calls into the PoolManager with delegated or elevated permissions and that the hook’s own authorization checks are independent of the PoolManager’s state.

Upgradeable hooks and proxy patterns

A hook deployed behind a transparent proxy or UUPS proxy can be upgraded without changing its address. From an LP’s perspective, this is a double-edged risk. On one hand, a team can fix bugs or adapt to protocol changes without requiring all liquidity providers to migrate to a new pool. On the other hand, the hook’s logic can be changed at any time, potentially transforming a safe hook into a malicious one. An admin can upgrade the hook to extract all accumulated fees, redirect swaps to a favored router, or silently change fee structures in their favor.

When evaluating an upgradeable hook, determine the upgrade path. Is there a timelock requiring that an upgrade be announced and frozen for a period? Is the upgrade governed by token holders or a multi-signature wallet? Does the upgrade function contain a contract verification step to ensure the new implementation matches a published code hash? An upgradeable hook with no timelock and a single-address upgrader is essentially a hook that can mutate unexpectedly. The LP is trusting that single address for the entire duration of the capital deployment.

An alternative is an immutable hook—code that has been verified and locked in place. The trade-off is that critical bugs cannot be patched without migrating to a new pool. Some projects deploy immutable hooks for core logic but use governance to vote on non-emergency changes, accepting the migration cost as a check against arbitrary modification. For Uniswap V4 specifically, a hook’s immutability can be verified by checking the contract code for an upgrade function and by confirming that the bytecode cannot be self-modified through delegatecall or other patterns.

External calls and oracle dependencies

A hook can call external contracts—price feeds, other DEXes, lending protocols, or governance systems. Each external call introduces two risks: the external contract could be unavailable or malicious, and the hook’s logic may depend on assumptions about that contract’s behavior that do not hold. A hook that queries a Chainlink oracle to enforce price bounds is sensible; a hook that sends all accumulated fees to an external treasury contract without validating the recipient is not.

The first audit step is listing every external call. Use the Etherscan code viewer or a static analysis tool to find all address() calls, delegatecall, and staticcall patterns. For each external contract, note what it does and why the hook depends on it. If the hook calls an oracle, what happens if the oracle fails to respond? Does the hook revert, or does it continue with a stale or missing price? A hook that reverts when an oracle is unavailable makes it impossible to execute swaps during an outage. A hook that assumes a missing price is zero could enable massive price manipulation. Neither is ideal, but the latter is catastrophic.

Fee extraction logic deserves particular scrutiny. If a hook accumulates fees and later transfers them to a treasury address, verify that the treasury address is hardcoded correctly and that the transfer function does not have unintended side effects. A common vulnerability is for a hook to use delegatecall to transfer funds, which can inadvertently execute arbitrary code if the treasury address is a contract with a fallback function. Static calls are safer: they do not allow the called contract to change state. Verify that fee transfers use safe patterns such as safeTransferFrom from OpenZeppelin’s SafeERC20.

Fee calculation and extraction mechanisms

Uniswap V4 hooks can implement custom fee structures. A hook might charge a flat fee on every swap, a percentage of the swap output, a dynamic fee based on pool conditions, or even a zero fee with revenue from another source. The auditor’s job is to ensure that the fee calculation is correct and that no fees are extracted in hidden ways.

Start by identifying where fees are calculated. In many hooks, a beforeSwap callback computes the fee based on the swap amount and pool state, then modifies the swap amount or sets a hook-specific state flag. An afterSwap callback then transfers the fee to a treasury. This two-step pattern is common but creates a window where the fee logic must be consistent across both callbacks. If the afterSwap hook calculates fees differently from beforeSwap, LPs might accumulate fees that are never withdrawn or fees that exceed the stated limit.

For dynamic fees, examine the inputs used in the calculation. A fee that depends on slippage, volatility, or recent trading volume can be legitimate, but it can also obscure price-steering. A hook that charges higher fees when the pool is losing money is economically rational but may be disclosing more information than desirable. A fee that changes based on an external oracle price is auditable; a fee that changes based on the hook owner’s private judgment is not. Always demand that the fee formula be documented and reviewable.

Verify that accumulated fees are actually withdrawn by authorized parties and that no fees are left stranded in the contract. A common pattern is for the hook to maintain a balance sheet mapping accounts to outstanding fees, then allow those accounts to withdraw on demand. This avoids a single point of failure where one withdrawal fails and blocks all others. Ensure that the withdrawal function is protected against reentrancy—a vulnerability where a malicious fee recipient can call back into the hook and drain additional funds before the balance is updated.

Pool initialization and parameter validation

When a pool is created with a hook, the hook’s initialization function is called. This is the moment when core parameters are set: which tokens are in the pool, what the initial price is, what fee tier applies, and any hook-specific settings. If the initialization function does not validate these parameters, an attacker could create a pool with dangerous settings and lure unsuspecting LPs into deploying capital.

Examine the initialization code for three categories of checks. First, validate that the tokens are legitimate ERC-20 contracts and not zero addresses or contracts that are known to be dangerous (for instance, flash loan tokens or rebasing tokens). Second, confirm that the fee tier is within an expected range. A pool with a 100% fee will effectively prevent swaps, but a pool with a 0.00001% fee might be exploitable by MEV bots that front-run and extract more than the stated fee. Third, check that any hook-specific parameters (such as oracle addresses, treasury recipients, or configuration flags) are not pointing to suspicious or unverified addresses.

A less obvious audit point is the initialization order. Some hooks initialize state in a way that depends on external conditions—for instance, reading an oracle price to set initial parameters. If the oracle has been manipulated or is returning an unusual value during initialization, the pool could start with distorted pricing. A hook that is robust against this risk either uses a reliable oracle with circuit breakers, or it explicitly allows governance to correct the initial state before LPs deposit liquidity.

Testing patterns and behavioral edge cases

A hook’s code may be correct for the “happy path”—the standard swap or liquidity operation executed by well-behaved users. Edge cases expose the difference between correct code and safe code. Flash loans, very large swaps, zero-amount operations, and rapid consecutive calls can expose subtle vulnerabilities that do not appear in normal use.

If available, examine the hook’s test suite. A well-tested hook typically has test cases covering the following: minimum viable swaps (1 wei of input); maximum swaps that approach or exceed available liquidity; consecutive operations that might interact with pooled state; and recovery from failed external calls or reverts. A hook with no tests or only happy-path tests is a red flag. If the developers did not test edge cases, they may not have considered them.

Simulate specific scenarios mentally or using a local fork. What happens if a swap amount is zero? Does the hook revert cleanly, or does it enter a state where subsequent swaps fail? What if the pool runs out of one token? A hook that attempts to extract fees by transferring more tokens than are available will revert, but the revert may be unclear and confuse users about what went wrong. What if the hook receives a call to an unexpected function—not a standard swap or liquidity operation? A robust hook should define a fallback function that explicitly reverts with a clear message rather than silently accepting or misinterpreting the call.

Finally, check for reentrancy. A hook that calls an external contract and then modifies its own state creates an opportunity for reentrancy: the called contract can invoke the hook again before the first call completes, observing a state that is inconsistent with the final result. Uniswap V4 uses reentrancy guards in the core PoolManager, but a hook that makes external calls outside of the PoolManager’s protection may need its own guards. Look for the nonReentrant modifier or similar patterns to ensure that recursive calls are blocked.

Verification and deployment checklist

Before approving a hook for capital deployment, follow this structured verification workflow. Step one: obtain the hook’s source code from the project’s GitHub repository and verify that it matches the bytecode deployed on-chain using Etherscan’s contract verification tool. A mismatch indicates either a compiler discrepancy or tampering; do not proceed without resolution. Step two: run a static analysis tool such as Slither or Mythril against the code to identify common vulnerabilities such as unchecked external calls, integer overflows, or delegatecall to arbitrary addresses. Step three: manually review the contract for permission boundaries, upgradeable patterns, fee extraction logic, and external dependencies according to the checklist outlined above.

Step four: verify the hook’s deployment history. When was it first deployed? Has it been upgraded, and if so, when and to what address? Are the upgrade transactions explained by the development team? Step five: check for formal security audits. An audit from a recognized firm such as Trail of Bits, OpenZeppelin, or CertiK provides stronger assurance than self-review, though audits are not guarantees and may be outdated if the code has been modified since. Step six: contact the development team with specific technical questions. Their responsiveness and depth of understanding is a signal of project quality. Step seven: if possible, interact with the hook using a small amount of capital on a testnet, then observe the behavior on mainnet before committing meaningful funds.

Document your findings in a shared format so that other LPs can review your work. A one-paragraph summary is insufficient; provide the specific code sections you examined, the potential risks you identified, and the assumptions you made about what constitutes acceptable risk. A hook that centralizes fee extraction to a single address may be acceptable if the project is early-stage and the team is trusted, but unacceptable if the hook will manage billions of dollars or the team is anonymous. Risk tolerance is personal, but transparency about risk is non-negotiable.