Skip to main content
The launch service builds the transactions that deploy a token on a launchpad: the create, with the creator’s buy inside it, then one buy per other wallet. It never signs for your wallets and never sends. You sign each transaction with its wallet and broadcast them as you like: one by one, as Jito bundles, in batches.

Solana

Pump.fun, Raydium LaunchLab (LetsBonk, USD1, StonkFun…), Meteora DBC through Bags

Robinhood Chain

pons.family V2 and V1

​
Routes

The same routes answer under /v1/launch. The service has no authentication and no rate limit: keep it behind your firewall or your own gateway.

​
Chains and launchpads

Launchpads that are catalogued but not built yet (for example surge on Solana, hood.fun on Robinhood Chain, fourmeme on BNB Chain) answer 501 not_implemented. An unknown chain or platform is 400.

​
Response shape

Every answer is { ok, data, error, nextCursor }:

​
The Solana transaction plan

One shape for every Solana launch, up to 50 wallets (wallets[0], the creator, included):
legs[i] says who signs transactions[i]:
  • kind is create or buy. A wallet that buys nothing gets no transaction, so walletIndex can skip.
  • The buys are priced along the bonding curve in the order returned: send them in that order, or the later buys’ slippage bounds no longer hold.
  • A Jito tip (jitoTipSol > 0) rides the last buy only, never the create. With no buy transaction there is no tip.
  • A product fee (feeWallet + feeBps, both or neither) is paid by each buyer inside its own transaction, as a share of what that buy spends.

​
v1 transactions

Every Solana transaction is v1 (SIMD-0385): up to 4,096 bytes, no address lookup tables, and the compute budget inside the message (computeUnitLimit, the priority fee from computeUnitPrice, and the loaded-data limit). Your signer must be able to sign v1 transactions. The one exception is the Bags launch transaction (platform: "meteora"), which Bags builds and partly signs as v0: its legs[0].version is 0. The mint’s signature is already in the create, and the blockhash is fetched at build time. If the transactions expire before you send them, build again: the mint’s signature covers the blockhash, so you cannot swap in a new one.
Earlier builds of the service answered v0 transactions, without legs, and fit Pump.fun launches into 1,232 bytes with lookup tables and at most 21 wallets. This documentation describes the v1 build.

​
Mint keys

The mint signs the create, so the service needs the mint’s secret:
  • mintKey: the mint’s 64-byte secret, base58. Use it for a vanity mint you generated yourself.
  • No mintKey: a mint is generated and returned as mint. Its secret is not returned (the create is already signed).
  • A 32-byte public key is refused on Pump.fun and LaunchLab. Pump.fun’s own vanity mints are signed by pump.fun’s API, which signs only v0 transactions.
Bags reserves the mint itself (a …BAGS vanity): see Bags.

​
RPC

Send your RPC in the body as rpcUrl (alias rpc). Without it the service falls back to its own environment (SOLANA_RPC for Solana; for Robinhood Chain HOOD_RPC, then a public node). A Solana launch with neither answers 400 rpcUrl is required.

​
Metadata

token: { name, symbol, description, image } (plus twitter, telegram, website). With token.metadataUri (or uri) set to an http, https or ipfs URL, nothing is uploaded. Without it, the service downloads the image (JPEG, PNG, GIF or WebP, within 10 s) and uploads the image and the metadata JSON to Raze’s IPFS node.