How Hookr works
Hookr composes token-market behavior block by block and makes the resulting parameters readable before execution. The addresses below belong to an earlier, permanently read-only deployment. The behavior described here is the reviewed source; it is a candidate until a new release manifest is verified on chain.
Writes are paused · Trading and launches are paused. The contracts currently linked are an earlier read-only deployment; writes open once the new addresses and runtime hashes, the bounded Hookr router, every deployment and blueprint receipt, the block-linkage evidence, and the full canary sequence are verified on chain.
Release manifest gate
One versioned manifest supplies every read address and every browser-write and agent release gate. Opening writes requires a deployment newer than the read-only slots already on chain, four nonzero address/runtime-hash pairs, the bounded Hookr router, a reviewed source commit, and one block shared by the fork and linkage readback.
The ordered deployment evidence is launchpad, hook, router, setHook, then all five blueprint receipts. The canary evidence is atomic launch-and-graduate, bounded-router buy, token approval, then bounded-router sell. Every receipt is required; a production boolean alone cannot open writes.
Current machine blockers: RELEASE_VERSION_TOO_LOW · PRODUCTION_NOT_ALLOWED · ROUTER_NOT_BOUNDED · LEGACY_ROUTER_FORBIDDEN · SOURCE_COMMIT_MISSING · DEPLOYMENT_RECEIPTS_INCOMPLETE · FIXED_BLOCK_FORK_MISSING · LINKAGE_READBACK_MISSING · CANARY_RECEIPTS_INCOMPLETE
1 · The bonding curve
A launch mints a fixed supply of 1,000,000,000 tokens with no owner, no mint function, no pause, no blacklist and no transfer tax. 80% of that supply sells along a stepped bonding curve of ten tranches; each tranche is priced 70% above the one before it. Buys and sells both work while the curve is live, and each pays a 1% curve fee split evenly between the creator and the protocol.
2 · Graduation
When the last tranche sells out the launch graduates in the same transaction. The ETH raised and the remaining 20% of supply become a full-range Uniswap v4 position at exactly the price the curve ended on, with the creator's hook attached and a dynamic fee. The position is owned by the launchpad contract, which has no function to remove liquidity — the liquidity is locked by construction, not by promise. Any supply that did not fit the position is burned by default, or placed as token-only bands if the creator configured them; see section 3. Trading fees earned by these positions can be collected by anyone; the ETH side splits between creator and protocol and the token side is burned.
3 · Creator fees and liquidity placement
These are set per launch, not on a hook. A hook blueprint is reusable by anyone, so it can only carry rules that hold for every launch; payout addresses and how a raise is placed belong to one launch.
Fees. There are two separate paths. While the token is on the curve, the 1% curve fee is a fixed even split between the creator and the protocol. After graduation, the pool position earns trading fees that anyone can collect; the ETH side splits by a share the creator chose at launch — 50% by default, 80% at most — and the token side is burned. Only that post-graduation share can be divided, across up to four addresses, each credited on chain so a recipient can claim without depending on the creator.
Liquidity. By default the entire raise becomes one full-range position and any supply that did not fit is burned. A creator can instead place up to four bands at chosen price multiples above the graduation price. Bands hold tokens only — they can never draw ETH — so they act as scheduled sell-side depth rather than a second market. A band that would not fit the tick grid is skipped rather than silently shifted, and fee collection pokes every band that was actually created.
4 · The five hook blocks
- Anti-Snipe — for a set number of blocks after graduation, buys are capped at a share of supply and pay an extra LP fee. Exact-output buys are blocked during the window so the cap cannot be routed around.
- Surge Fees— the LP fee scales with how much of the pool's in-range depth a trade consumes, from your base fee up to your ceiling. No oracle involved.
- Auto Burn — a configured share of actual exact-input buy token output goes directly to the dead address. There is no ETH vault, keeper or separate market buy.
- LP Rewards — an ETH-side share of an exact-input buy is donated to in-range liquidity providers inside that swap.
- Nth-buy Pot — an ETH-side share fills a deterministic pot. A public counter advances at most once per pool per block, and the Nth qualifying slot wins. A minimum buy applies. Qualifying swaps must canonically bind a nonzero recipient, the production router supplies that binding automatically, and claimants can redirect payout. A funded pot remains claim-backed for the next scheduled winner; there is no permissionless flush.
What Hookr does not claim
- Nothing here is independently audited. The contracts are a tested source candidate, not a deployment. Tests and a canary are evidence, not an audit.
- The Nth-buy Pot is not random. The public
potBuyCountdetermines the next slot, so expect it to be raced. The one-advance-per-block rule stops a single atomic call from manufacturing every remaining slot; it does not make the outcome fair or private. - No fairness, anti-bot or anti-MEV guarantee. The anti-snipe block caps per-swap size for a window; it does not identify people and cannot stop someone using many wallets.
- Hook fee cuts apply to exact-input buys only.Sells and exact-output buys pay only the LP fee. Auto Burn is an output-token share; LP/pot shares are ETH-side. The guard's size cap and snipe tax are buy-side too.
- Routing is release-pinned. The legacy PoolSwapTest router is not an approved execution boundary. Trading stays closed until the bounded router has a deployed address and verified runtime hash.
- Rules are immutable after graduation. A hook cannot be edited or replaced on a live pool. Changing rules means launching a new token.