> ## Documentation Index
> Fetch the complete documentation index at: https://docs.raze.bot/llms.txt
> Use this file to discover all available pages before exploring further.
# Launch overview
> Unsigned token-deploy transactions: a create and the first buys, from up to 50 wallets.
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.
Pump.fun, Raydium LaunchLab (LetsBonk, USD1, StonkFun…), Meteora DBC through Bags
pons.family V2 and V1
## Routes
| Route | What |
| - | - |
| [`GET /launch`](/api-reference/launch/catalog) | Every chain, with its live and not-yet-wired launchpads |
| [`GET /launch/{chain}`](/api-reference/launch/platforms) | The launchpads of one chain, with their aliases |
| [`POST /launch/{chain}`](/api-reference/launch/create) | Build a launch |
| [`GET /health`](/api-reference/launch/health) | Liveness |
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
| Chain | `platform` | Builds |
| - | - | - |
| `sol` (`solana`) | `pump` (default) | Pump.fun |
| | `raydium`, `letsbonk`, `launchlab`, `usd1`, `stonkfun`, `bonkers`, … | Raydium LaunchLab |
| | `meteora` (`bags`) | Meteora DBC through Bags |
| `robinhood` (`hood`, `rh`, `4663`) | `pons` (default) | pons.family V2, or V1 with `ponsVersion: "v1"` |
| `eth`, `bsc`, `base` | — | Nothing yet: `501` |
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 }`:
```json theme={null}
{ "ok": true, "data": { "platform": "pump", "mint": "…", "transactions": ["…", "…"], "legs": [ … ] }, "error": null, "nextCursor": null }
```
```json theme={null}
{ "ok": false, "data": null, "error": { "code": "bad_request", "message": "wallets[0] is required (creator / payer)" }, "nextCursor": null }
```
| HTTP | `error.code` | Meaning |
| - | - | - |
| 400 | `bad_request` | The request is wrong: unknown chain or platform, missing wallets or metadata, more than 50 wallets, bad JSON |
| 501 | `not_implemented` | The chain or launchpad is catalogued but has no builder |
| 502 | `launch_failed` | The builder refused or an upstream failed: an RPC, the launchpad's program rules, IPFS, Bags. **Read the message**: many of these are fixable inputs (a wrong `mintKey`, an underfunded payer, a curve setting out of range). |
| 504 | `upstream_timeout` | The build took more than 90 s |
## The Solana transaction plan
One shape for every Solana launch, up to **50 wallets** (`wallets[0]`, the creator, included):
```
transactions[0] create, with the creator's buy inside it when wallets[0] buys
transactions[1..] one buy per other wallet that buys, in wallet order
```
`legs[i]` says who signs `transactions[i]`:
```json theme={null}
{ "kind": "create", "wallet": "", "walletIndex": 0, "version": 1 }
```
* `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](https://github.com/solana-foundation/solana-improvement-documents/pull/385)): 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](/launch/solana#meteora-dbc-through-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.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.