> ## Documentation Index
> Fetch the complete documentation index at: https://docs.o1.exchange/llms.txt
> Use this file to discover all available pages before exploring further.

# Prepare a launch

> Prepare a crypto-paired or stock-paired launch with the same validation as the platform.

`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

```json theme={null}
{
  "chain_id": 8453,
  "creator": "0x1111111111111111111111111111111111111111",
  "market": "standard",
  "quote_address": "0x0000000000000000000000000000000000000000",
  "token": {
    "name": "Example 01",
    "symbol": "EX01",
    "description": "Example launch",
    "website": "https://example.com",
    "x": "https://x.com/example",
    "telegram": "https://t.me/example",
    "editable_metadata": false,
    "extra_metadata": [],
    "image_base64": "<base64>",
    "image_type": "image/png"
  }
}
```

## 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, Monad and Arc `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.

## Arc launch amounts

Use `chain_id: 5042`, the `standard` market and ERC-20 USDC as the paired asset. The pool quote has six decimals, while the native launch fee uses 18 decimals. For example, a 2-USDC launch fee is `2000000000000000000` in transaction `value`. The fee comes from the live factory configuration; do not hardcode it or pay it again through an ERC-20 transfer.

Ordinary creation seeds the pool with the launch token's supply and does not require a USDC liquidity deposit. Native and ERC-20 USDC share one balance, so leave enough for the launch fee and gas. The browser's optional atomic Dev Buy is a separate flow from this API endpoint.