Skip to main content
POST /launches/prepare validates and prepares one launch. The caller’s wallet remains the creator and signer. Crypto-paired and stock-paired creation are available on Base and Robinhood. On each chain, both markets use the same active factory. A stock-paired launch requires the selected Stock Token to be present in the platform catalog, registered on the live factory, and enabled for creation. Base currently has ten registered Stock Tokens; Robinhood has 194. The API rejects a market or paired asset that is not currently available instead of falling back to another factory.

​
Request

​
What preparation verifies

The API:
  1. resolves exactly one active factory for the requested chain and market
  2. confirms the paired asset is supported by that factory and registered onchain
  3. reads the current supply, configuration version, quote terms, fee terms, and block time at one chain block
  4. validates token identity, URLs, image limits, profile settings, and complete pool supply
  5. checks any current creation-fee requirement before uploading anything
  6. pins the image and ERC-7572 metadata through the same protected Convex Pinata flow and configured gateway used by the Launchpad app
  7. mines a token salt whose resulting address ends in 01
  8. confirms that the mined salt is still unused and builds a short-deadline createLaunch call committed to the current configuration
  9. adds a creation-fee approval only when the live factory requires a nonzero ERC-20 fee
  10. includes native value only when the selected market requires a nonzero native fee
  11. simulates the final launch against the same observed chain block when all prerequisites are already satisfied
  12. appends the same ERC-8021 builder attribution used by the Launchpad UI on Base
The API does not assume a fixed launch fee. Fee fields and approval steps come from the selected live contract and appear only when its current fee is nonzero. This endpoint prepares the ordinary createLaunch path. The optional atomic Base, Robinhood and Monad createLaunchAndBuy browser flows are not currently exposed by the Public API, so integrations must not add Dev Buy fields to this request or modify the returned calldata. The returned transaction value covers the exact launch value only. The wallet must still retain native currency for gas, and performs the final gas estimate before signing. A normal launch creates two IPFS objects through Pinata: the image and one ERC-7572 metadata JSON document that references that image. The individual metadata fields do not create separate uploads. extra_metadata is encoded in the launch transaction and normally remains empty unless the integration needs token-specific key-value data. Images must be valid PNG, JPEG, WebP, or GIF data, match the declared MIME type, and decode to no more than 2 MB. Token descriptions are limited to 2000 UTF-8 bytes. Extra metadata accepts at most 16 unique keys and 4096 UTF-8 bytes in total.

​
Supply and liquidity

The complete fixed supply is placed into permanent Uniswap v4 liquidity.

​
Response and execution

The response contains:
  • prepared_at, expires_at, and the chain block used for validation
  • a normalized review of token settings, total supply, and pool supply
  • the predicted 01 address, resolved contract configuration, metadata URI, and image URL
  • a creation-fee object only when the live fee is nonzero
  • ordered transaction steps, dependencies, and simulation state
  • structured issues
An insufficient creation-fee balance returns 422 insufficient_balance with asset, actual_raw, and required_raw before any image or metadata is pinned. When an ERC-20 fee approval is required, the launch step depends on that approval and is marked simulation.status=not_run. Submit the approval, wait for confirmation, then prepare again so the API can verify and simulate current state. Use a unique Idempotency-Key for each logical launch preparation. Reusing it with a different body is rejected. An exact retry may replay the completed result while it remains executable; after its plan expires, it returns 409 stale_plan and requires a new key. Launch preparation is limited to 3 requests per API key each minute and 100 per day. Within each key, one creator can prepare once per minute and 25 times per day. Another API key cannot consume that creator counter. Completed idempotent retries return the saved response without repeating Pinata or simulation work.