Hookr developer docs

Hookr is a Uniswap v4 hook that serves many pools. A pool opened through Hookr freezes a configuration at creation and the hook reads that frozen record on every callback, so nothing about the pool's rules can change afterwards, including by the Hookr owner.

The hook runs today's rules, each independently switchable per pool:

• A surge LP fee that rises with trade size relative to in-range depth.
• A temporal guard window on newly launched tokens: a per-block quote buy cap, a snipe tax, exact-output buys blocked, and outside liquidity blocked.
• An auto-burn of a share of subject output on buys.
• An in-swap LP reward donated to in-range liquidity.
• An Nth-buy pot paid to the buyer who trips the counter.

Every current rule works on any quote currency: native ETH, HOOKR, USDG, a Robinhood tokenized stock, or any other ERC-20. More rules and profiles keep sealing over time.

Two Lanes

A new-token market deploys a fixed-supply ERC-20, places the whole supply in one coordinator-held, token-only sell band, and optionally executes a creator buy in the same transaction. The band cannot be removed. This lane can use the guard window.

An existing-asset market initializes a fresh pool for a token that already exists. It adds no liquidity and holds no position; LPs use ordinary v4 periphery. This lane has no founding position, no guard window, and no creator buy. Opening one is permissionless while market opening is not paused, and records only who opened it, not who owns the token.

The Fee Model in One Table

The protocol never takes a slice of the base LP fee. It takes a share from inside each opted-in add-on, 20% at the deployed default, and the trader pays exactly the amounts the pool was configured with.

The deployed default is protocolShareBps of 2000, and the module constant MAX_PROTOCOL_SHARE_BPS is 5000 (50%). In general the split is 1-s to the LP side and s to the protocol, where s is the share frozen into the pool's immutable module config when the market was opened. A creator tier of zero means the protocol takes nothing from that creator's pools.

The worst case for any future pool is a 50% slice of the opted-in add-ons, and never any slice of the base LP fee. A pool that opts into nothing but a base fee generates zero protocol revenue.

Fee model carries the per-quadrant arithmetic, in integer form, the way the contracts compute it.

What an Integrator Needs to Know

• The pool's fee field carries the v4 dynamic fee flag 0x800000. The hook sets the effective fee per swap.
• The hook address encodes flags 0x28cc: beforeInitialize, beforeAddLiquidity, beforeSwap, afterSwap, beforeSwapReturnsDelta, afterSwapReturnsDelta. Removing liquidity is not hooked.
• A swap through the Universal Router with empty hookData behaves normally. Every rule applies except the pot leg, which needs an authenticated recipient the hook can only get from the Hookr router or quoter.
• A pool with any input cut on an exact-input buy requires the canonical full-fill price limit. Base-fee-only pools accept partial fills.

Where the Code and the Addresses Live

The contracts are live on Robinhood Chain, chain id 4663. The default root hook is 0xb3cA29cF721380CEe8b8e4755F3865Ebc68Fe8cC, mined so its low fourteen address bits equal 0x28cc, and it is the root this documentation describes unless a page says otherwise.

It is not the only root. Four further roots run the same five rules at the same flag word and add an arbitrage-correction lane of their own, each with its own kernel id and its own sealed profile; a pool names exactly one root at creation, permanently. The current one is 0xb914f955294799de4b891bd2EA8AF628Fa1c68CC, and it is not offered in the Hookr app's launch flow. Arbitrage recapture is where that lineage is described.

Every address on this site is rendered from one deployment record, the same file published as deployments/robinhood-4663.v2.json in the public contracts repository. The source commit behind the deployed code is 8db7fc940938f811f508ba9cb0c8f2d3f24c9a25, built with release (bytecode_hash=ipfs, via-IR, optimizer 200, cancun, solc 0.8.26).

• Contracts and addresses: every deployed address, the linked libraries, the upstream dependencies, and the wiring read back from the chain.
• ABIs: the published ABI of each deployed contract, served as JSON.
• Verification: the build settings and the explorer status of every address.

The contracts are deployed and unaudited. Read Known limitations before treating anything here as a guarantee.

Where to Read Next