Token launch (pumpfun / bonk / bags / meteora_dbc / meteora_cpamm)

Quote asset for the launch. wallets[].amount is always denominated in it. The accepted values and the failure mode differ per platform — do not generalise from one to the other.

pumpfun: "SOL"/"wSOL"/the wSOL mint (or omitted), or USDC — either the string "USDC" or the mint EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v. Anything else is a 400 — never a fallback (since 2026-07-31; before that an unrecognized value silently launched in SOL, so a mistyped or wrong-cased USDC gave you the wrong asset with no error). The amount and any feeBps are denominated and charged in the chosen asset.

bonk: "SOL"/So111…112 (default) or "USD1"/USD1ttGY1N17NEEHLmELoaybftRBUSErhqYiQzvEmuB. Anything else is a 400 — never a fallback, and the server additionally reads the launchpad config's own quote_mint back and refuses if it disagrees. USDC is not accepted here: LaunchLab has no USDC global_config.

bags: "SOL"/So111…112 or omitted. Anything else is a 400 — never a fallback. Bags' configs are SOL-quoted and their API takes the first buy in lamports.

bs58-encoded 64-byte mint secret key. The create transaction is signed locally with it, so the returned bundle needs only your wallet signatures. Wins over mintPubkey if both are sent. Accepted on both platforms.

Omitting it differs per platform: on pumpfun the server reaches for a …pump vanity mint; on bonk it just generates a keypair in-process — the official …bonk suffix only exists behind letsbonk's own endpoint and is not available here.

bs58-encoded 32-byte mint address. On pumpfun: a Pump.fun vanity mint you already reserved — the mint signature slot is filled via the Pump frontend API, and the wallet legs stay unsigned for you to complete. Ignored when mintKey is also present.

On bags (since 2026-07-31): the …BAGS mint a provisioning call reserved, accepted only together with feeShareConfigKey and token.metadataUri — the follow-up launch then reuses it instead of burning a second mint. Without the key it is a 400.

On bonk this is a 400, not a silent downgrade: the base mint must sign initialize and LaunchLab has no equivalent of pump's sign-create-tx, so an address without its secret is unsignable by anyone. Send mintKey instead.

Buy slippage tolerance, 0–10000. Defaults to 9900 (99%) on pumpfun, 500 (5%) on bonk, and 500 (5%) on bags — on both of the latter the later buyers' prices are modelled exactly against the curve, so a 99% floor would be protection in name only.

bonk only. Selects the LaunchLab platform_config, which decides the swap fee and whether the token creator earns anything. letsbonk's own three modes, with their own names accepted as aliases:

| value | address | swap fee | creator fee | |---|---|---|---| | standard · letsbonk · memes · platformId | FfYek5vE… | 1.25% | 0 | | bonkers · tech · techPlatformId | 82NMHVCK… | 1.00% | 0.05% | | balanced · balancedPlatformId | BuM6KDpW… | 1.25% | 0 |

🔴 Changed 2026-07-30. bonkers used to resolve to BuM6KDpW…, which is letsbonk's Balanced mode — 1.25% and no creator fee, the same economics as standard, and the opposite of what their UI promises for the mode it labels "Bonkers" ("This mode has creator fees"). It now resolves to 82NMHVCK…. If you were sending bonkers and want the old target, send balanced.

Any other value is rejected. For a config none of these names covers, pass platformConfig.

bonk only. Explicit LaunchLab platform_config address — there are ~2000 on chain and 30 alone are named letsbonk.fun, so the named modes above cannot cover them. Also accepted as platformId.

Mutually exclusive with bonkType: sending both is a 400, because two sources of truth for the same account is how a caller ends up on a config they did not pick.

Verified on chain before use — the account must exist, be owned by the LaunchLab program and carry the PlatformConfig discriminator. A wrong value is a 400, never a silent fall back to the default.

Since 2026-07-31 the config's on-chain fee rates (fee_rate, creator_fee_rate, plus the global trade_fee_rate) also price the buys: every minimumAmountOut floor is computed with the real total fee of the config you picked, not LetsBonk's 1.5%.

💰 Funding floor (bonk, all configs): a LaunchLab create debits wallets[0] 24_532_480 lamports (0.02453248 SOL) of rent and Metaplex fees — mint 1_461_600 + pool 3_876_720 + two vaults 2_039_280 each + metadata 15_115_600 (of which 10_000_000 is the Metaplex fee). Measured on three mainnet creates, reconciled to the lamport. On top of that the server's pre-check counts, because the runtime deducts or debits them too: the create transaction's own fees (10_000 base + the priority fee on the requested compute units — 20_000 at the defaults, scaling with computeUnitPrice); and, when the first buy is fused in: 2_039_280 for the creator's token ATA, the buy amount itself, another 2_039_280 for the transient wSOL account (recovered at close, but payable mid-transaction), the feeBps cut and any tipLamports. The rejection names the exact lamport total instead of letting the bundle die on chain after the vanity mint and the IPFS pin are already spent.

bonk only. Total token supply in base units. Defaults to the LetsBonk shape (1e15). Must be ≥ the launchpad's on-chain min_supply_a.

⚠️ Send this as a string from JavaScript. It is a u64, and the letsbonk UI offers supplies up to 1e18 base units — well past Number.MAX_SAFE_INTEGER (9.007e15), so a numeric literal like 123456789123456789 is already rounded to …780 before your request is sent. A decimal string carries all 64 bits, and letsbonk's own frontend sends it that way. Numbers are still accepted (added 2026-07-30; before that a string was a 422).

bonk only. Tokens sold on the curve before graduation; the remainder seeds migration liquidity. Defaults to 793_100_000_000_000 (79.31% of the default supply). Must satisfy the launchpad's min_sell_rate_a and min_migrate_rate_a.

bonk only. Amount raised on the curve before graduation, in whole quote tokens — 85 means 85 SOL on a SOL-quoted launch, 5000 means 5000 USD1 on a USD1-quoted one. Must be ≥ that config's on-chain min_fund_raising_b (24 SOL / 5 000 USD1 at the time of writing — read live, so treat these as indicative). Defaults to 85 SOL on a SOL launch; required on a USD1 launch.

bonk only. SOL-denominated alias for fundRaisingQuote, kept for compatibility. fundRaisingQuote wins when both are sent, and sending this on a non-SOL launch is rejected rather than reinterpreted.

bonk only. Base mint decimals. Defaults to 6.

meteora_dbc / meteora_cpamm only, both of which return 501 today.

Rejected on pumpfun, bonk and bags (since 2026-07-30) rather than ignored: it used to be accepted and dropped there — including values that are not even valid base58 — so a caller could not tell "ignored" from "accepted" without deserialising the returned transaction and reading which config it references. On bonk, use bonkType or platformConfig.

Note the casing: ...Sol, not ...SOL.

Custom tip recipient wallet (defaults to the Raze relay tip wallet).

Flat tip in lamports attached once to the create tx (payer pays). feeTipLamports is the legacy alias.

Legacy alias for tipLamports.

Custom fee recipient wallet. Only charged together with feeBps.

Percentage fee in basis points of each buyer's raw quote amount, paid by that buyer alongside its buy. pumpfun and bonk differ here: on bonk the creator's buy fused into the create is charged like any other buyer; on pumpfun the fee rides the buy transactions only, so wallets[0]'s fused buy is not charged. On a USD1-quoted bonk launch the fee is an SPL transfer in USD1 (the fee wallet's associated account is created if missing, paid for by the buyer); otherwise it is a lamport transfer. This is our fee leg, unrelated to LaunchLab's native share_fee_rate, which we always send as 0.

On a USDC-quoted pumpfun launch the fee is an SPL transfer in USDC (the fee wallet's associated account is created if missing, paid for by the buyer), exactly as on USD1-quoted bonk — the fee is always charged in the quote asset, never mis-scaled.

bags only. The fee template (Bags' MeteoraConfigType id). It decides the swap fee, the pre- vs post-migration split, how much compounds back into liquidity and, in some templates, how much of the supply is locked.

Omitted ⇒ ba28db46-ea6f-4452-8218-5587f6aca0a1 (DEFAULT_96_LOCKED), the value Bags' own SDK defaults to. We always send it downstream rather than leaving it out, so the template can never change under a caller because Bags changed a server-side default. Choosing one here overrides our pin, not theirs.

Rejected on pumpfun and bonk, which have no fee-share config — and rejected alongside feeShareConfigKey, where the template is already frozen in the on-chain config.

bags only. The Meteora DBC PoolConfig a provisioning call created for this launch, already landed on chain — the launch then completes in one call. Always sent together with mintPubkey and token.metadataUri from the same provisioning response: one config per LAUNCH. Without mintPubkey it is rejected — Bags' claim attribution is per mint, and a config reused for a different mint makes that token's trading fees unclaimable (measured 2026-07-31).

This input moves money: the token's trading fees go to the fee_claimer frozen inside the config. The server validates the account (exists, owned by the DBC program, carries the PoolConfig discriminator, SOL-quoted) and returns the config's feeClaimer so you can verify the destination before signing — but it cannot prove the config pays any particular claimer list, which is why bagsFeeClaimers / bagsConfigType are rejected alongside it.

Not configAddress (a Meteora field of ours, still rejected on bags): this key names a config of Bags'.

Jito tip in SOL embedded by the server on the LAST buy transaction of the bundle, on both pumpfun and bonk. Omitting it means no tip — attach your own, which is what most integrators do. Note the exact casing: ...Sol, not ...SOL — an unrecognised key is silently ignored, which also lands you on no tip.

Priority fee in micro-lamports per compute unit, emitted as a SetComputeUnitPrice instruction. Defaults to 50000 on both platforms. There is no priorityFeeSol / priorityFee field — this is the only priority-fee knob, and an unrecognised key is dropped silently.

The compute budget costs 52 bytes (a program key plus the two instructions), and the widest bonk shapes land within that of the 1232-byte wire limit. Rather than reject a launch that would otherwise fit, a transaction gives things up in a fixed order, recoverable losses first:

1. a rent-reclaim instruction — on a SOL launch the trailing close_account, which leaves ~0.00204 SOL of rent (not funds) in your own wSOL account for you to close whenever you like; on a USD1 launch an idempotent account create that was a no-op anyway. 2. the default compute price. 3. the default compute limit, i.e. the whole budget.

Stranded rent is undone with one instruction at any time; a priority fee that was never attached cannot be recovered — hence that order. A bonk create with a long name, a USD1 fee leg and a tip measures 1196 bytes with the whole budget dropped (it needed all three rungs; keeping just the limit would have been 1236, four bytes over). It lands, with no priority fee, and the server logs the rung it settled on.

Nothing you asked for is ever on that list — not the fee leg, not the tip, not the swap, and not a computeUnitPrice / computeUnitLimit you sent explicitly. If an explicit value cannot fit, the request fails and says so rather than returning a transaction without the priority fee you were told you would pay. Want a fee on a shape that tight? Shorten token.name / token.symbol / the metadata URI, or drop a wallet — the error names those options.

Compute-unit cap. Sent explicitly, it applies to every transaction in the launch. Omitted, each transaction gets a per-shape default:

pumpfun — 400000 on the create / deploy-buy, 600000 on the buys.

bonk — 400000 on the create (+ fused first buy), 120000 on each subsequent buy. These are ≈1.8× the measured worst case (219000 CU for a create with a fused buy; ~70000 for a buy), not copied from pumpfun: Solana charges the priority fee on the units requested, not consumed, so an inflated limit costs real money.

Set by /utils/sol/launch — the mint of the launched token.

Set by /utils/sol/launch and /utils/sol/fees/claim.

Set by /utils/sol/launch when a lookup table was created for the bundle — the address the stage transaction provisions.

Venue pool/curve address, returned by launches that derive one up front (bonk, bags). Absent on pumpfun, whose bonding curve is derivable from the mint alone.

Venue config account, when the venue keys its curve on one. Present on bags: the Meteora DBC PoolConfig the launch runs against. You need it to build any later swap of your own, it is not derivable from the mint — and on a provisioning response it is the feeShareConfigKey to pass on the follow-up call, together with the returned mint and metadataUri (the config belongs to that mint only — see feeShareConfigKey).

bags launches: where the config sends the token's trading fees — the fee_claimer frozen in the on-chain PoolConfig. Echoed for your records; you do not have to police it, since the server only lets you launch against the config provisioned for your own mint (see feeShareConfigKey).

bags provisioning responses: the reserved mint's metadata URI. Pass it back as token.metadataUri (with mintPubkey = the returned mint) on the follow-up launch call.

Set by /utils/sol/launch — true when the wallet count pushed the launch onto the multi-stage / lookup-table path.