uniswap/uniswap-ai/v4-hook-generator

v4 Hook Generator

Generate Uniswap v4 hook contracts via the OpenZeppelin Contracts Wizard MCP tool. This skill guides you through selecting the right hook type, configuring permissions and utilities, assembling the canonical MCP JSON, and invoking the MCP tool to produce ready-to-compile Solidity code.

Security companion: Generated hook code touches fund-handling contracts. Always apply the

v4-security-foundations skill immediately after generation to audit permissions, delta

accounting, and access control before deploying to any network.

When to Use This Skill

Use this skill when you need to:

• Scaffold a new Uniswap v4 hook contract from scratch
• Select the right base hook type for a specific use case (fees, MEV protection, oracles, etc.)
• Configure hook permissions, utility libraries, shares, and access control
• Produce the canonical MCP tool call JSON to invoke the OpenZeppelin Contracts Wizard
• Understand trade-offs between hook configuration options before committing to an implementation

Prerequisite / companion skill: v4-security-foundations — run it before writing custom logic and again before deployment. Hook misconfiguration can drain user funds.

Hook Type Decision Table

Choose the base hook type that matches your primary goal. If your hook has multiple goals, choose the type that covers the most critical concern and layer additional logic on top.

Selection tips:

• BaseHook is the general-purpose starting point — choose a specialized type only when the

built-in logic provides concrete value.

• BaseCustomCurve replaces the entire AMM math; only use it if you are implementing a novel

pricing algorithm.

• AntiSandwichHook and LiquidityPenaltyHook both address MEV but target different actors

(traders vs. JIT LPs). Clarify which attack vector you are mitigating.

• OracleHookWithV3Adapters is appropriate when downstream integrations expect a Uniswap v3

IUniswapV3Pool-compatible oracle interface.

Minimal Decision Checklist

Before calling the MCP tool, confirm all six decisions:

1. Hook type — chosen from the decision table above
2. Permissions to enable — only the callbacks your logic actually uses (beforeSwap, afterSwap, etc.)
3. Utility libraries — currencySettler, safeCast, transientStorage as needed
4. Shares — false, ERC20, ERC6909, or ERC1155
5. Access control — ownable, roles, or managed
6. Hook inputs — blockNumberOffset, maxAbsTickDelta (only for hook types that use them)

Permission Configuration

All 14 permission flags with guidance on when to enable each. Start with all flags false and enable only what your hook logic requires. Every enabled permission increases the hook's attack surface and requires a specific bit to be set in the hook's deployed address (see address encoding note below).

Address encoding note: Permissions are encoded as bits in the hook contract's deployed address. The address must have the correct bits set at deployment time or the PoolManager will revert. Use HookMiner (from v4-periphery) to mine a salt that produces an address with the correct bit pattern. Never change permissions after deployment — the address is immutable.

Utility Library Selection

Three optional utility libraries can be included in the generated hook. Include only what your hook logic uses.

Guidance:

• currencySettler is almost always needed when beforeSwapReturnDelta,

afterSwapReturnDelta, afterAddLiquidityReturnDelta, or afterRemoveLiquidityReturnDelta are enabled — it provides settle and take helpers that implement the correct sync → transfer → settle sequence.

• transientStorage is a gas-efficient alternative to storage slots for intra-transaction state.

Use it to pass a flag or value from beforeSwap to afterSwap without paying 20k gas for a cold SSTORE.

• safeCast is advisable whenever you compute amounts derived from int256/uint256 conversions,

especially for fee calculations.

Shares Configuration

The shares option controls whether the generated hook issues a token representing user shares (e.g., LP positions in hook-owned liquidity pools).

Trade-offs:

• false: smallest bytecode, no share accounting overhead; appropriate for fee hooks and oracles.
• ERC20: simplest fungible share; good DeFi composability (e.g., used as collateral).
• ERC6909: gas-efficient multi-token with a minimal interface; preferred for new protocol designs.
• ERC1155: widest ecosystem support (wallets, explorers, NFT marketplaces); higher gas cost per

transfer than ERC6909.

Access Control Options

The access option shapes the constructor and administrative interface of the generated hook.

Guidance:

• ownable is the simplest — one address can perform all privileged operations. Suitable for

early-stage hooks and personal tools.

• roles adds ADMIN_ROLE, PAUSER_ROLE, etc. via OpenZeppelin AccessControl. Use when

different team members need different privileges (e.g., a keeper bot that can update fees but cannot upgrade the contract).

• managed delegates all permission checks to a separate AccessManager contract. Use when

you need a unified governance layer across multiple contracts or want timelocked admin actions.

Note: Changing the access option changes the constructor signature. Update deployment

scripts and initialization logic accordingly. When using ownable, ensure the initialOwner

is not the zero address — OpenZeppelin's Ownable reverts on zero address since v5.

Hook Inputs Reference

Some hook types accept numeric configuration inputs that tune behavior. These are passed as the inputs object in the MCP tool call.