Hooks and the AI Hook Builder

Uniswap v4 moves swap logic out of the core pool contract and into attachable hook contracts. HookPad's entire launch model depends on this: the factory creates a pool, attaches a hook, and that hook becomes the enforcement layer for trading tax, anti-snipe protection, and ETH routing on every swap. Today every pool uses the same deployed hook. The Hook Builder workspace is the product surface where custom hooks are being designed before they graduate into a selectable template library at launch time.

The production hook: HookPadHook

Every token launched through HookPadLaunchFactory on Robinhood Chain shares one hook address, configured at factory deployment time. The hook implements Uniswap v4's BaseHook interface and requests the minimum permission set required to intercept swaps and return fee deltas. It does not modify pool initialization parameters beyond what the factory sets at creation.

Permission set

The hook enables beforeSwap and afterSwap callbacks so it can inspect the swap direction, apply the applicable tax rate, and collect ETH on the swap path. It does not enable liquidity modification hooks, donate hooks, or return delta hooks beyond what is required for fee collection. This keeps the attack surface narrow: the hook cannot drain LP positions or alter tick ranges after initialization.

State tracked per pool

Tax computation on each swap

On every swap, the hook executes the following decision tree in order:

1. If the swap is a buy and the pool is within five seconds of initialization and the sender is not whitelisted, apply the flat 60% anti-snipe rate and route 100% to the treasury. Skip the dynamic schedule.
2. If the swap is a sell and the post-snipe sell counter is below five, apply the flat 30% cooldown rate and route 100% to the creator via HookPadFeeLocker. Skip the dynamic schedule.
3. Otherwise, read the applicable trade counter (buy or sell), compute the position in the cycle, look up the tier rate (base rate or fixed tier), and route to the creator or treasury according to the schedule documented on the launcher page.
4. Increment the trade counter and emit a TaxCollected event with the token address, direction, snipe flag, gross ETH, effective rate, and both cut amounts.

ETH-only collection

All tax is collected and routed in native ETH. The creator never receives their own token as tax revenue. This is enforced at the hook level: fee deltas are applied on the ETH leg of the swap regardless of pool token ordering. Withdrawal happens through HookPadFeeLocker.claimFees, which transfers the full accrued balance to the creator's wallet in a single transaction.

The planned template library

A single hook works well for the default launch model, but different token designs need different swap behavior. HookPad is building a library of audited, deployable hook templates that creators select at launch time instead of accepting the default. Each template is a standalone hook contract that implements the same factory registration interface but encodes different rules.

Templates in the builder seed tree

The Hook Builder file tree is seeded with example contracts that represent the first wave of planned templates. These files are reference implementations today; they are not yet wired into the launch factory.

How template selection will work at launch

When the library ships, the launch form will expose a template picker alongside the existing tax and whitelist settings. The factory will deploy or attach the selected hook address instead of the default HookPadHook. Each template declares its treasury routing rules upfront, and any treasury directed tax in a template accrues to the same protocol treasury that feeds the planned $HOOKP buyback program. Creator directed tax in every template will continue to flow through HookPadFeeLocker in ETH.

The AI Hook Builder workspace

The Hook Builder is a product surface at /hook-builder, reachable from the main navigation. It is designed as a split pane workspace: a file tree and code preview on the left, an AI chat assistant on the right. The goal is to let a creator or developer describe swap behavior in plain language and receive scaffolded Solidity that conforms to Uniswap v4 hook conventions, without requiring them to write the permission manifest and callback stubs from scratch.

Current implementation

How the chat assistant works today

Messages are processed client side. When you send a prompt, the assistant waits briefly and returns one of several predefined responses based on keyword matching in your input:

• Prompts mentioning "sniper" receive a reply describing a beforeSwap guard that rejects buys in the first three blocks and caps wallet size, with an offer to add it to SniperGuardHook.sol.
• Prompts mentioning "fee" or "tax" receive a reply describing an afterSwap fee forward to a treasury address, with a follow up question about the percentage.
• Prompts mentioning "dynamic" receive a reply describing a volatility or volume window fee range, with an offer to wire it into DynamicFeeHook.sol.
• All other prompts receive a generic reply asking for more detail about the desired swap behavior.

The welcome message identifies the assistant as "HookPad AI" and sets the scope: dynamic fees, sniper protection, creator tax, or custom beforeSwap logic. This establishes the vocabulary the full model backed version will use when it ships.

Example prompts the builder is designed to handle

File manifest structure

The seed tree mirrors a Foundry style project layout that the production builder will target:

• hooks/BaseHook.sol: extends v4-periphery/BaseHook.sol, declares getHookPermissions with beforeSwap: true as the starting point.
• hooks/DynamicFeeHook.sol, SniperGuardHook.sol, CreatorTaxHook.sol: specialized implementations built on the base scaffold.
• interfaces/IHookPad.sol: a minimal deploy interface stub for future factory integration.
• README.md: workspace instructions ("edit hook files on the left, chat on the right").

What ships next for the builder

1. Connect the chat to a model backed code generation pipeline that reads the active file context and returns diffs rather than prose descriptions.
2. Make the file tree editable: create, rename, and delete files from the UI, with chat driven patches applied to the selected file.
3. Add a compile step (local Foundry or remote sandbox) that surfaces syntax and permission errors before any deployment is offered.
4. Wire audited templates into the launch factory as selectable options, replacing the single default hook.

Until those steps ship, use the builder to explore hook designs and read the production behavior on the launcher and fee structure pages for tokens you deploy today.