Skip to main content
POST
Both hosts serve this path, but the request bodies differ. Solana amounts are integer lamports; EVM amounts are integer wei strings. Each host rejects the other’s fields rather than ignoring them, so a body written for one chain will not run on the other.

Choosing a host

Pick the host from the chain you are launching on, and use that host’s key — keys are not interchangeable. The two Solana regions are interchangeable — same account, wallets, keys, and request format. See Regions.
The chains that serve deploys are not the same as the ones that serve swaps. ink deploys but does not swap; eth and base swap but do not deploy. Don’t reuse a swap’s chain value without checking it here first.
Because chain defaults to rbh, an EVM deploy that omits it launches on Robinhood. Set it explicitly for every other chain.

Amounts

This is the most common source of broken deploy requests.
On EVM every amount is a string, never a JSON number — an integer of up to 78 digits. Sending a number fails with INVALID_REQUEST naming the field and the expected type. Solana amounts are the opposite: plain integers, except the priority fees, which are decimal SOL.

Fields the EVM host rejects

These are Solana-only. The EVM host rejects them with INVALID_REQUEST (<field> is not supported on EVM) rather than ignoring them, so strip them when porting a body across:
  • creator_buy_sol_amount
  • jito_tip
  • mint_private_key
  • creator_priority_fee_sol
  • buys[].sol_amount and buys[].priority_fee_sol
bundle_mode: "sniper" is Solana-only too, but fails with INVALID_BUNDLE_MODE instead.

Launchpads by chain

configs takes at least one entry, and at most one per dex — a repeat fails with DUPLICATE_DEX. On EVM, dex is matched case-insensitively and must be allowed on the chain you selected; anything else fails with INVALID_DEX_CONFIG, and the message lists the ones that are.
bags exists on both hosts with different data shapes. Solana takes fee_claimers, a list of objects each carrying its own bps. EVM takes two parallel arrays, claimers and percent. Neither shape works on the other host.
trench is not available on the public API and is rejected with INVALID_REQUEST.

Launchpad data rules

Each entry in configs is dex plus a data object holding that launchpad’s own settings. data must be an object; on EVM, omitting it is treated as an empty object. Throughout these tables:
  • wei — an integer string, up to 78 digits.
  • addr — 0x followed by 40 hex characters.
  • hash32 — 0x followed by 64 hex characters.
  • bps — basis points, where 10000 = 100%.
  • Fields are optional unless marked required.
A rule failure returns 400 INVALID_DEX_CONFIG with a message naming the index of the offending entry.

EVM

The fee split uses parallel arrays: claimers and percent must be the same length, and percent must total exactly 100 (10000 bps). Send both or neither. An invalid split fails with BAGS_FEE_CLAIMER_BPS_INVALID.
data is passed through as sent. The API applies no rules of its own, so any error surfaces at launch time rather than on validation.
token_tax is optional, but sending it brings its own rules:Those six rates — burn_rate, divide_rate, liquidity_rate, recipient_rate, giggle_charity_rate and binance_charity_rate — must total exactly 100.
tax is optional, but sending it brings its own rules:The four allocation fields are the same set arguspad uses, and all four must be present even when one is zero.
The four split fields are top-level in data, not nested.
These rules are checked by the API before the launch is submitted. Passing them does not guarantee the launchpad itself will accept the configuration — a rejection downstream also comes back as INVALID_DEX_CONFIG.
Arc denominates in USDC, and the decimals are worth confirming. Arc’s native gas token is USDC, but the native unit and the ERC-20 view of USDC do not use the same number of decimals. Before launching on arc with real value, test creator_buy_wei, buys[].amount_wei and the *_usdc config fields with a small amount and check what actually lands.

Solana

bps across all claimers must total 10000, or the deploy fails with BAGS_FEE_CLAIMER_BPS_INVALID. Bags launches also require metadata.description (BAGS_DESCRIPTION_REQUIRED).

Bundled buys

buys names wallets that buy the token in the same bundle as the launch. Every one must belong to your account. Every entry needs an amount, in that host’s field — sol_amount on Solana, amount_wei on EVM. A buy carrying neither is rejected.
On EVM, buys requires bundle_mode. Sending buys without one fails with INVALID_BUNDLE_MODE. Each amount_wei must also be greater than zero.
non_packed has a maximum number of buyer wallets; exceeding it fails with NON_PACKED_TOO_MANY_BUYS. Switch to packed or send fewer buys.

Distributions

distributions sends part of the launched supply to wallets you name, straight after the deploy.
Distributions require a creator buy on both hosts. Sending any distribution without creator_buy_sol_amount (Solana) or a non-zero creator_buy_wei (EVM) fails with DISTRIBUTIONS_REQUIRE_CREATOR_BUY.
Percentages are basis points and total at most 10000 across all entries; exceeding that fails with DISTRIBUTION_PERCENTAGE_EXCEEDS_CAP. On the EVM host each entry must set exactly one of amount or percentage, and the recipient may not be the creator wallet — that fails with INVALID_DISTRIBUTION_WALLET.

Reading the response

Both hosts return the same envelope:
landed and reverted are EVM-only; Solana entries carry only kind, dex, mint and signature.
On EVM, judge success by landed, not by the presence of a hash. A hash only means a node accepted the transaction. landed: true is the only field that means it is on chain, and reverted: true means it was mined and failed — treat that as a failure even though the request returned 200.

Retrying a failed deploy

A 500 with code INTERNAL means the deploy could not be completed. It is safe to retry. Every other deploy error is a validation failure: the host stops at the first problem it finds, so fix the error in front of you and resend. See Deploy errors for the full code list and which host returns each one.

Examples

Only chain and configs change between EVM chains:

Authorizations

Authorization
string
header
required

Your Bloom API key, e.g. Authorization: Bearer blm_sol_live_…. Create one in Bloom Manager → Manage API Keys.

Body

application/json
wallet_address
string
required

Creator wallet — a base58 address on Solana, 0x followed by 40 hex characters on EVM. Must belong to your account.

metadata
object
required

Token metadata. name, symbol and image_url are required on both hosts. description is required on Solana, and enforced again there for Bags launches (BAGS_DESCRIPTION_REQUIRED); the EVM host does not validate it. It is listed as required below because this schema covers both hosts — always send one.

configs
object[]
required

One entry per launchpad, at least one and at most one per dex — a repeated dex fails with DUPLICATE_DEX. Use the Solana shape on the Solana host and the EVM shape on the EVM host.

Minimum array length: 1

Solana host. A DEX configuration; the JSON shape is { "dex": <pump_fun|bags|bonk>, "data": <variant config> }. trench is not available on the public API and is rejected with INVALID_REQUEST.

chain
enum<string>
default:rbh

EVM host only. The chain to launch on, matched case-insensitively. Defaults to rbh (Robinhood), so a deploy on any other chain must set it explicitly. An unrecognised value fails with INVALID_REQUEST, and the error lists the supported chains. Not used on the Solana host, where the host is the chain.

The chains that serve deploys are not the same as the ones that serve swaps — ink deploys but does not swap, and eth and base swap but do not deploy. See Chains and quote assets.

Available options:
rbh,
bsc,
arc,
ink
creator_buy_sol_amount
integer<int64>

Solana only. The creator's own buy, in lamports. On the EVM host use creator_buy_wei; sending this field there fails with INVALID_REQUEST.

creator_buy_wei
string

EVM host only. The creator's own buy, as an integer string in wei. Omitted or "0" means no creator buy. A non-zero value is required whenever you send distributions.

buys
object[]

Bundled buyer wallets, each of which must belong to your account. On the EVM host, buys requires bundle_mode — sending buys without one fails with INVALID_BUNDLE_MODE.

bundle_mode
enum<string>

How bundled buys are submitted. sniper is Solana only — the EVM host accepts packed and non_packed and rejects anything else with INVALID_BUNDLE_MODE. non_packed caps the number of buyer wallets (NON_PACKED_TOO_MANY_BUYS); packed does not.

Available options:
packed,
non_packed,
sniper
jito_tip
integer<int64>

Solana only. Bundle tip, in lamports. Rejected by the EVM host with INVALID_REQUEST.

slippage_bps
integer<int64>

Slippage tolerance in basis points. On the EVM host, 0-10000.

distributions
object[]

Post-deploy transfers of the launched token to wallets you name. Requires a creator buy on both hosts — creator_buy_sol_amount on Solana, a non-zero creator_buy_wei on EVM. Without one the deploy fails with DISTRIBUTIONS_REQUIRE_CREATOR_BUY.

mint_private_key
string

Solana only. A custom or vanity mint keypair. Rejected by the EVM host with INVALID_REQUEST.

creator_priority_fee_sol
number

Solana only. The creator transaction's priority fee, in SOL as a decimal (not lamports). Rejected by the EVM host with INVALID_REQUEST.

Response

Deploy accepted.

success
boolean
required
Example:

true

data
object
required