Integrating Hooked tokens.

Start here

A token launched on Hooked is an ordinary Token-2022 mint with a transfer hook, trading on its own Meteora Dynamic Bonding Curve pool. The hook is a Solana program that runs on every transfer of the token, buys and sells included, and refuses the ones its rule doesn't allow. Nothing else about the token is unusual: name, ticker and image are in its metadata, supply starts at 1,000,000,000, and decimals are 9 (or 6, the creator's choice).

• One pool, one config per launch. Every launch creates its own DBC config and pool. Most are priced in SOL; paired launches are priced in a tokenized stock or another coin (the config's quote mint says which).
• Curve. A graduating token moves to Meteora DAMM v2 when its curve fills, and its hook is removed then (see Graduation). A permanent one stays on its curve, and its rule, for good.
• Trading. Most rules trade on any route that resolves Token-2022 transfer-hook accounts, including Meteora's own SDK. A few need Hooked's own route or one particular app (see Where each rule trades).

This page is about these tokens. Tokens of the separate Hooked standard are a different kind of token on Hooked's own programs, with their own integration docs.

Recognising a Hooked token

Any one of these is enough; together they are certain.

• The launch signer. The transaction that creates every Hooked pool carries HookAsdGBN9ukg6QcaGZj7xsTtEk1TC3apMFyR5oxkeZ as an extra read-only signer, the way other launchpads tag their launches. No instruction uses it; it is there to be indexed.
• The fee claimer. The DBC config of every Hooked pool has 2oXT6oMgNPfToahWG48QTBPWS9UJ8a7TSSeEoeoSLMGt as its fee claimer (mainnet).
• The hook. The mint's TransferHook extension names one of Hooked's hook programs (the table below). That program tells you which rule, or family of rules, the token has.
• The list. GET https://www.hookedpad.com/api/launches returns every token launched on Hooked with its rule, pool and creator (see The HTTP API).

Addresses

The hook programs, and the rules each one enforces. The rules engine runs every rule written as rules (the Custom, Editable, DAO and AI hooks and the ready-made rules built on it); every other program runs one rule or one family.

The programs are upgradeable by Hooked. Check any of them with solana program show <address>.

The HTTP API

Public, no key, JSON. Responses are cached for about 10 seconds, so polling faster than that returns the same data.

• GET /api/launches: every token launched on Hooked, as { ok, launches: [...] }.
• GET /api/launches?lite=1: only what changes from minute to minute, one row per token: [first 8 characters of the mint, market cap in SOL, market cap in USD, curve progress 0..1, status]. Poll this; fetch the full list again when a token appears that you haven't seen.
• GET /api/pool?mint=<mint>&pool=<pool>: one curve's SOL raised, the SOL at which it graduates, its progress, market cap and whether it has graduated.
• GET /api/icon/<mint>: the token's image.
• POST /api/rules/check with { "rules": "<rule text>" }: the plain-English reading of a rule set (CORS on).
• GET /api/rules/state?mint=<mint>: for a token whose rules can change (Editable, DAO, Hooki), its rules as they are on-chain right now.

A launch row:

{
  "mint": "…", "name": "…", "symbol": "…",
  "ruleId": "social", "ruleName": "Social trading",   // the token's rule (see the table above)
  "group": "trade", "verified": true,
  "imageUrl": "/api/icon/<mint>",
  "pool": "…",                                         // its Meteora DBC pool
  "creator": "…",                                      // the launching wallet
  "socials": { "x": "…", "telegram": "…", "website": "…" },
  "launchedAt": "2026-10-24T18:01:14.384Z",
  "mcapSol": 49.84, "mcapUsd": 5032.94,                // null when the pool couldn't be read
  "progress": 0.12,                                    // 0..1 toward graduation
  "status": "bonding" | "permanent" | "graduated"
}

Every token has a page at https://www.hookedpad.com/t/<mint> with its rule in plain words, its settings and a trade box. Link there for anything a user should read before trading.

Trading

A buy or sell is a normal Meteora DBC swap on the token's pool, plus the hook's accounts. Token-2022 calls the hook during the transfer, and it needs every account the token's extra-account-metas list names: the account at ["extra-account-metas", mint] under the hook program. Resolve them the way the real transfer will run:

• A buy moves tokens from the pool's base vault to the buyer's token account.
• A sell moves them from the seller's token account into the pool's base vault.
• The buyer's token account is a Token-2022 associated token account; create it in the same transaction (idempotent) if it doesn't exist yet.

Meteora's SDK does all of this itself. This buy, built with nothing but the stock SDK, trades a Hooked token:

import { DynamicBondingCurveClient } from "@meteora-ag/dynamic-bonding-curve-sdk";

const client = new DynamicBondingCurveClient(connection, "confirmed");
const tx = await client.pool.swap2WithTransferHook({
  owner: buyer, payer: buyer, pool,            // pool = the launch row's "pool"
  swapBaseForQuote: false,                      // false = buy, true = sell
  swapMode: 0,                                  // exact in
  amountIn: new BN(lamports), minimumAmountOut: new BN(minTokensOut),
  referralTokenAccount: null,
});

Building it yourself: take the hook's accounts from a transfer instruction resolved by @solana/spl-token (createTransferCheckedWithTransferHookInstruction with the vault and the trader's account as above; everything after its first four accounts is the hook's) and pass them to the swap as its transfer-hook remaining accounts.

• Simulate first. A rule can refuse a trade; the simulation says so, with the reason (see When a trade is refused). Set the compute limit from the simulation; hooks add some compute to a swap.
• Paired launches are priced in their config's quote mint rather than SOL. Route through that token, or trade it directly.

Where each rule trades

• Any route that resolves the hook's accounts: every rule not listed below.
• Only through Hooked's own swap: Shielded Trading, Pegs, Buyer rewards, Holder vesting, Tithe token, Allowlist token, Holder-gated. Their hook needs an account derived from the buyer, or something carried in the trade (an allowlist proof, a payment to the token's cause), that a general router doesn't build. Send users to the token's Hooked page.
• Only in one app: FOMO-only buys, Pump App only, Social trading, Social Trading Wars, OpenSea only. Their hook only lets buys (and on Social trading and Social Trading Wars, sells too) through when the trade comes from that app; see FOMO-gated rules.

The launch row's ruleId tells you which applies. On a graduated token none of this applies any more.

When a trade is refused

The transaction fails in the hook, and the logs say why.

• Rules-engine tokens (program 9eQyvzp3…) log rules: rule N refused this transfer and fail with custom error 10000 + N: rule 1 is 10001. N counts the token's rules from 1, in order; the token's page shows them in plain words.
• Every other hook fails with a named Anchor error. Show its Error Message line from the logs: it is written for traders. Some you will see: BlockZero and CreatorCantSend (Block Zero Protection), NotCoSigned (FOMO-only buys), NotThroughApp (Pump App only), NotThroughApps (Social trading, Social Trading Wars), NotThroughOpenSea (OpenSea only), SellsTurn (Ping Pong), Closed (Trading hours).

A refused trade moves nothing; the trader pays only the network fee. Whether a rule can refuse sells as well as buys is on the token's page.

Block Zero Protection

Tokens launched on Hooked since 2026-10-23 come with Block Zero Protection, enforced by their hook:

• Until the creator's first buy, nobody else can buy. The launcher makes that buy in the transaction that opens trading.
• In the block of that first buy, nobody but the creator can buy. A bundle riding with the launch buy fails.
• The creator's wallet can never send its tokens to another wallet. It can sell.

So buys aimed at a Hooked launch in its first block fail with BlockZero (on rules-engine tokens, with the refusal of the Block Zero rule). From the next block on, trading is open under the token's own rule.

Which tokens have it. Rules-engine launches carry it as their last two rules; Combine rules launches always include it. On the other hook programs a token that has it has a record at ["block-zero", mint] under its hook program, listed in its extra-account-metas list: 80 bytes, "HKBZERO1" | mint (32) | creator (32) | slot of the creator's first buy (u64, 0 = not yet). On those programs it is used by: Pegs, Blocklist, Venue-locked, Hot potato, Anti-dump caps, Sliding caps, Graduated sell caps, Max per wallet, Chapters, Rising max per wallet, Sniper-fee cap, Trade guard, Anti-bundle, DEX-only, FOMO-only buys, Pump App only, Social trading, Social Trading Wars, OpenSea only, Ping Pong, Breathing cap, Momentum, Resonance, Coupled resonator, Market hours, King of the Hill, Loans, no liquidations, Lock & earn, Trading hours, Beacon, Hooked Paint, Agent Gate. It isn't on Plague, P2P-only, Buyer rewards, Allowlist token, Tithe token, Holder-gated, Holder vesting, on two-token launches (Polarity, Reactive pair, a Beacon launched with its Entangled token) or launches priced in a stock, nor on tokens launched before 2026-10-23.

FOMO-gated rules

These rules are built around FOMO and the Pump app. Each reads the whole transaction through the Instructions sysvar and checks for FOMO's signing wallet, AgmLJBMDCqWynYnQiPCuj9ewsNNsBJXyzoUhD9LJzN51, as a signer of some instruction in it (a wallet that only pays the fee doesn't show up there; FOMO lists it as the payer of the create-token-account instruction in every buy). The signature itself is checked by the runtime, so nobody else can put that wallet in.

On all of them the token's creator is exempt, so the launch buy goes through before either app has seen the token. Block Zero still applies to everyone else.

Sending

A wallet-to-wallet transfer runs the hook too, so it needs the same extra accounts. A plain transferChecked (what most wallets' Send buttons build) fails; build it with createTransferCheckedWithTransferHookInstruction from @solana/spl-token, which reads the token's list and adds them. Some rules limit sends (the creator's wallet under Block Zero, for one), and say so on the token's page.

Graduation

A graduating token's curve fills on a buy, and Meteora moves it to a DAMM v2 pool. Meteora removes the token's hook in that same buy: from then on its mint names no hook program, the rule no longer applies, and it trades like any other Token-2022 token. Its launch row then has status: "graduated". A permanent token never graduates and keeps its rule.

Building on Hooked, or stuck? Reach us on X at @hookedpad.