POST /launches/prepare validates and prepares one launch. The caller’s wallet remains the creator and signer.
Standard creation is available on Base and Robinhood. Stock-paired availability follows the same shared suite and quote catalog as the Launchpad app, then requires the selected quote to be registered and creation to be enabled on the live factory. The published stock catalog is currently on Robinhood. A Base stock route will appear automatically after those shared and onchain readiness conditions are met; the API has no separate release switch.
The API rejects a route or quote that is not currently available instead of falling back to another factory.
Request
What preparation verifies
The API:- resolves exactly one active suite for the requested chain and market
- confirms the quote belongs to that suite and is registered on-chain
- reads the current supply, configuration version, quote terms, fee terms, and block time at one chain block
- validates token identity, URLs, image limits, allocations, vesting, protected recipients, and pool coverage
- pins the image and ERC-7572 metadata through the same protected Convex Pinata flow and configured gateway used by the Launchpad app
- mines a token salt whose resulting address ends in
01 - confirms that the mined salt is still unused and builds a short-deadline
createLaunchcall committed to the current configuration - adds a creation-fee approval only when the live factory requires a nonzero ERC-20 fee
- includes native value only when the selected live route requires a nonzero native fee
- simulates the final launch when all prerequisites are already satisfied
- appends the same ERC-8021 builder attribution used by the Launchpad UI on Base
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.
Allocations and vesting
- at most 128 combined allocation and vesting recipients
- at most 64 vesting recipients
- at most 24 unlock steps per beneficiary
- at most 128 unlock steps per launch
- every recipient must be a distinct, nonzero, non-infrastructure address
- total allocated and vested supply must remain below total supply
- at least 10% of supply must remain for the launch pool
- the first vesting unlock is at least one day after launch
- each schedule ends at 100%
Response and execution
The response contains:prepared_at,expires_at, and the chain block used for validation- a normalized
reviewof token settings, supply, pool supply, allocations, and vesting - the predicted
01address, suite, 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
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 and 1 request per creator each minute, with daily ceilings of 100 per key and 25 per creator. Completed idempotent retries return the saved response without repeating Pinata or simulation work.