Skip to main content
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:
  1. resolves exactly one active suite for the requested chain and market
  2. confirms the quote belongs to that suite and is registered on-chain
  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, allocations, vesting, protected recipients, and pool coverage
  5. pins the image and ERC-7572 metadata through the same protected Convex Pinata flow and configured gateway used by the Launchpad app
  6. mines a token salt whose resulting address ends in 01
  7. confirms that the mined salt is still unused and builds a short-deadline createLaunch call committed to the current configuration
  8. adds a creation-fee approval only when the live factory requires a nonzero ERC-20 fee
  9. includes native value only when the selected live route requires a nonzero native fee
  10. simulates the final launch when all prerequisites are already satisfied
  11. appends the same ERC-8021 builder attribution used by the Launchpad UI on Base
There is currently no assumed launch fee. Fee fields and approval steps appear only when a live contract requires them. 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.

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%
Amounts are decimal token amounts in the request. Returned calldata contains base-unit amounts.

Response and execution

The response contains:
  • prepared_at, expires_at, and the chain block used for validation
  • a normalized review of token settings, supply, pool supply, allocations, and vesting
  • the predicted 01 address, 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
A blocking issue returns no executable steps. 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 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.