Uniswap v4 Hook Audit: Permissions, Callbacks and Accounting

Understand what the hook changes

Uniswap v4 hooks can execute custom logic around pool lifecycle operations. Hook permissions are encoded in address bits, and a hook can serve multiple pools. Source 1 explains the callback and permission model. Reviewing a custom hook therefore requires its deployment configuration as well as its Solidity source.

Turn the design into reviewable rules

List every enabled callback and describe its intended effect on a swap, liquidity change, or other supported operation. State which callers are permitted, which pools are supported, and what the hook is allowed to charge or retain. Reviewers can then compare implementation paths against explicit requirements instead of inferring the product design from code.

Example: accounting shared across pools

Suppose a hook maintains reward or fee state for multiple pools. A useful review scenario is to update one pool and then read or claim from another. Test whether identifiers and authorization checks keep balances isolated, including when tokens are shared across pools. This is a proposed isolation test, not a claim that the v4 protocol has this defect.

Follow custom amounts through settlement

For a hook that changes fees or accounting, trace what the trader pays, what liquidity providers receive, and what the hook retains. Define conservation rules and test rounding at very small amounts. Add sequences of operations rather than testing callbacks only in isolation; a valid local calculation can be inconsistent with the final settlement model.

Include dependencies and administrative actions

If a hook reads an oracle, calls another contract, or relies on an administrator to set parameters, add those boundaries to the scope. Test unavailable or stale dependencies, unauthorized parameter changes, and behavior at allowed extremes. Document which actions can interrupt trading or change the user's execution assumptions.

Prepare an audit package

Share the hook source and commit, permissions, deployment scripts, supported pool configurations, tests, and the intended fee or reward specification. Include routers and integration code where they establish assumptions used by the hook. Agree whether deployment verification and subsequent remediation review are included in the engagement.

Review Checklist

• Match deployed address permissions to the intended callbacks.
• Check caller authorization and separation of state across pools.
• Test end-to-end asset conservation under boundary amounts and failed dependencies.

Sources and Further Reading

1. Uniswap: v4 hook concepts and permissions

The linked sources describe the standards or research discussed above. Review scenarios are practical planning examples, not findings from an audit of a specific project.