bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 35쪽 중 5쪽
quest, and distinguish a simulated payment from final receipt evidence.
## Dev Buy and \$O launch errors
Unsupported products, funding assets or settlement routes are rejected before signable calldata is returned. For \$O launches, omit Tax settings and trading referrals. A failed complete-transaction simulation can mean insufficient acquisition liquidity, a vault conversion failure, insufficient physical settlement inventory or output below the minimum. More wallet funds do not fix a route that cannot spend the full input.
When Dev Buy preparation returns `requires_reprepare: true`, confirm its approval steps, then send the original request with `continuation_id` and a new `Idempotency-Key`. Keep the same API key and intent. A stale continuation or changed adapter/configuration needs fresh preparation; do not edit an old transaction to bypass the check. The API does not return provisional purchase calldata while approvals are outstanding.
## Safe request retries
Mintlify labels this as **Unique retry ID**. Send it in the standard `Idempotency-Key` header. Generate a random UUID for each new launch or metadata-document update, then reuse it only when retrying that exact request.
* it can contain 1 to 255 characters and is kept for 24 hours
* the same API key, retry ID, and body replay the completed response
* using the same retry ID for different input returns `idempotency_key_reused`; the second request is not prepared
* different API keys may safely use the same retry ID
## Retry policy
* retry 429 after `Retry-After`
* retry 500 once; if it persists, contact support with the `request_id`
* retry 502, 503, and 504 with capped exponential backoff and jitter
* do not blindly retry 400, 401, 403, or 422
* prepare again after `stale_plan`
* restart pagination after a stale or filter-mismatched cursor
* never broadcast a transaction after its expiry
## Caching and data freshness
Each response includes `meta.generated_at`, which records when the gateway formed the response. Source freshness comes from resource-level `updated_at`, observed or confirmed block, and finality fields. Configuration exposes `as_of_block` whenever contract or paired-asset data requires a live one-block chain read.
Every request admitted by the weighted limiter consumes its documented route weight, including a repeated request using the same retry ID or a cached data response. Units measure access to the operation, not the gateway's internal compute cost. With a valid key, insufficient-scope and oversized-page rejections consume the route's base weight. Missing or invalid authentication, body-size enforcement, and requests rejected by an already-exhausted quota record zero units. A request that passes the limiter and later fails endpoint validation, simulation, or an upstream dependency consumes the route weight because execution capacity was reserved.
Use each resource's freshness fields to judge how current it is. Ranked and trending values update periodically; their `updated_at` field records the latest refresh.
Live configuration, swap quotes, wallet balances, allowances, claims, transaction plans, and simulations are never response-cached. External holder pages are requested from their provider without a stale fallback. If a required dependency is unavailable, the API returns a mapped error instead of silently returning an older snapshot.
Repeating a launch or metadata-document request with the same retry ID may return its original response, avoiding duplicate uploads and transaction preparation. This applies only to the same API key, retry ID, route and request body. Use a new retry ID after a returned plan expires.
# Public API
Source: https://docs.o1.exchange/launchpad/api/introduction
Read o1 Launchpad data and prepare safe wallet transactions on Base, Robinhood, Monad, Arc, BSC and X Layer.
The o1 Launchpad Public API exposes the useful actions available in the live application without exposing internal analytics, governance, or infrastructure controls.
This reference covers all six public API chains in the shared registry. Read `/config` for the selected chain and product before preparing transactions: chain support does not mean every quote is registered or launch creation is enabled.
It supports:
* Base mainnet (`8453`), Robinhood Chain (`4663`), Monad (`143`), Arc mainnet (`5042`), BSC (`56`) and X Layer (`196`)
* token browsing, search, creator launches, details, trades, announcements, holders, wallets, and fee claims
* crypto-paired token creation on Base, Robinhood, Monad, Arc, BSC and X Layer plus registered stock-paired creation on Base, Robinhood, BSC and X Layer, with editable metadata, IPFS uploads, and the required `01` token-address suffix
* optional atomic Dev Buy using native currency or an admitted paired asset, with approval and repreparation for ERC-20 funding
* Base and Robinhood \$O launches paired with wstO, with ETH or held-wstO Dev Buy and ETH, chain-specific stablecoin, \$O or wstO trading
* exact-input launch-pool quotes and unsigned transaction preparation through the configured router, including SwapX on Arc, BSC and X Layer
* fee claims, Tax dividend discovery and holder-authorized claim preparation, creator announcements, and authorized metadata updates
<Warning>
The API never signs or broadcasts an on-chain transaction. It returns explicit transaction steps for the requested wallet to review, sign, and submit.
</Warning>
## Chain and product support
| Chain | Chain ID | Standard API | Tax API deployment | \$O launches |
| - | -: | - | - | - |
| Base | `8453` | Supported | `base-mainnet-tax-token-v2` | `base-mainnet-wsto-burn-v1` |
| Robinhood | `4663` | Supported | `robinhood-mainnet-tax-token-v2` | `robinhood-mainnet-wsto-burn-v1` |
| Monad | `143` | Supported | `monad-mainnet-tax-token-v2` | Not supported |
| Arc | `5042` | Supported | `arc-mainnet-tax-token-v2` | Not supported |
| BSC | `56` | Supported | `bsc-mainnet-tax-token-v2` | Not supported |
| X Layer | `196` | Supported | `xlayer-mainnet-tax-token-v2` | Not supported |
Use `launch_product=tax` in configuration queries and `launch_product: "tax"` in launch bodies for Tax. Use `wsto` for **\$O launches on Base or Robinhood** (`base-mainnet-wsto-burn-v1` or `robinhood-mainnet-wsto-burn-v1`), with wstO as the paired asset. Omitted product selection means Standard (`non-tax`). Monad supports MON/USDC/WETH; Arc supports USDC and cirBTC. Base, Robinhood, BSC and X Layer Standard/Tax support their registered crypto and stock pairs.
Read the selected suite's `token_mode`, `tax_format`, `dividend_claims` and `creation_available` from `/config`. Standard Base tokens use B20; current Tax tokens use ERC-20. Frontend visibility flags do not control API access. Historical index-only Tax suites stay excluded from public API discovery and transaction preparation.
All six chains share read, configuration, fee-claim, creator-action and supported transaction-preparation endpoints. Dividend actions require a Tax token with dividends enabled. Atomic Dev Buy and alternative swap settlement use the routes advertised by `/config`, with live binding, balance, allowance and full-transaction simulation checks. Exact-output swaps and arbitrary caller-supplied routes are not exposed.
Funding and settlement assets are separate from the pool quote. Discover them through [configuration](/launchpad/api/read-endpoints#dev-buy-and-settlement-assets), then follow [launch preparation](/launchpad/api/launches) or [trade preparation](/launchpad/api/trading). A configured route still needs sufficient liquidity for the requested amount.
## Base URL
```text theme={null}
https://api.launch.o1.exchange/v1
```
Only `GET /health` is unauthenticated. Send `x-api-key` on every other request.
## Resource model
The API keeps related data together without mixing incompatible query modes:
* `/config` combines production chains, contract configurations, paired assets, and capabilities. Its exact response field names remain `suites` and `quotes` for API compatibility.
* `/tokens` browses and ranks launches, `/tokens/search` searches them, and `/creators/{address}/tokens` lists one creator's launches.
* one token detail endpoint can include pool, market, and recent announcements.
* trades and announcements have independent collection routes and cursors.
* fee claims expose their own state and filters; holder Dividend positions and preparation use separate routes.
* on-chain name, symbol, and key-value updates are separate from token metadata-document updates that pin IPFS content.
This keeps the API compact while ensuring every parameter displayed for an endpoint is valid for that resource.
## Non-custodial transaction flow
```mermaid theme={null}
flowchart LR
A["Your app"] -->|"prepare or quote"| B["o1 Public API"]
B -->|"validate live state"| C["Onchain and indexed data"]
B -->|"transaction steps"| A
A -->|"user signs"| D["Wallet"]
D -->|"broadcast"| E["Selected chain"]
E -->|"verified chain events"| C
```
Every prepare response identifies the expected chain, sender, destination, calldata, value, expiry, issues, and ordered prerequisites. Never replace an API-provided spender or destination with a guessed address.
The existing launchpad indexer discovers confirmed chain events normally. Public clients cannot ask the API to write product records or force an indexing job.
## Next
<CardGroup>
<Card title="Get an API key" icon="key" href="https://launch.o1.exchange/developers">
Create and manage a scoped production key with your wallet.
</Card>
<Card title="Quickstart" icon="rocket" href="/launchpad/api/quickstart">
List launches and prepare your first trade.
</Card>
<Card title="Authentication" icon="key" href="/launchpad/api/authentication">
Create keys, select scopes, and configure browser origins.
</Card>
<Card title="Read endpoints" icon="database" href="/launchpad/api/read-endpoints">
Search and paginate launchpad resources.
</Card>
<Card title="Errors and rate limits" icon="gauge" href="/launchpad/api/errors-and-limits">
Handle API errors, quotas, and safe retries.
</Card>
<Card title="OpenAPI schema" icon="brackets-curly" href="/launchpad-api-openapi.yaml">
Download the complete machine-readable schema.
</Card>
</CardGroup>
# Prepare a launch
Source: https://docs.o1.exchange/launchpad/api/launches
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, Robinhood, BSC and X Layer when enabled. Within each product, both markets use the same factory. Monad and Arc support crypto-paired launches only. Each chain's Tax product has a separate ERC-20 factory and requires explicit product selection. 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. The October 1, 2026 reference lists 51 registered Base Stock Tokens, 194 on Robinhood, 21 bStocks on BSC and 45 wrapped stocks on X Layer, for both current products. Read `/config` for current availability.
The API rejects a market or paired asset that is not currently available instead of falling back to another factory.
**\$O launches** use `launch_product: "wsto"` on Base or Robinhood with that chain's wstO quote. Standard, Tax and \$O launches support optional atomic Dev Buy through the selected adapter. Read `/config` for admitted funding assets; the API never substitutes another product or route.
## 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"
}
}
```
## Tax-token launches
Request `/config?chain_id=8453&launch_product=tax&market=all&active_only=false`, then choose a quote and suite with `creation_available: true`. Use the [Tax deployment table](/launchpad/integration/tax-tokens) for the other chain IDs and suite names. Keep the chain ID consistent between configuration queries and launch requests; never reuse another chain's quote address. Binance-Peg USDC on BSC uses 18 decimals, while Arc ERC-20 USDC uses six.
Use the same request above, adding these top-level fields. This example selects 3% buy and sell tax, with the post-protocol remainder split 60% creator and 40% dividends:
```json theme={null}
{
"launch_product": "tax",
"tax": {
"format": "inclusive",
"buy_tax_rate": "3000000",
"sell_tax_rate": "3000000",
"creator_allocation_share": "60000000",
"burn_allocation_share": "0",
"dividend_allocation_share": "40000000",
"integrator_allocation_share": "0",
"minimum_dividend_holding_raw": "10000000000000000000000",
"creator_fee_recipient": "0x1111111111111111111111111111111111111111",
"integrator_fee_recipient": "0x0000000000000000000000000000000000000000",
"anti_snipe_enabled": true
}
}
```
These percentage fields are integer strings: `1000000` means 1%, and `1` means 0.000001%. The minimum holding uses 18-decimal token units, so the example means 10,000 tokens. Do not use BPS, floating-point numbers or percent signs in this object. `market` still selects crypto (`standard`) or stocks (`rwa`).
The API checks current bounds, protocol clamps, allocation conservation, minimum holding, recipients and anti-sniping availability, then uses the Tax launch tuple and ERC-20 prediction. Ordinary totals already include protocol. No Standard base/referral fee is added. Positive integrator allocation requires its valid recipient; zero allocation pays nothing.
Omitting `launch_product` preserves Standard behavior. A Tax object on a non-tax request, missing Tax settings or an incompatible tax format rejects. Historical BPS-shaped tax inputs are not the current inclusive format. The current Tax suite does not support vesting inputs. Optional Dev Buy uses the funding rules below and retains the selected Tax economics.
For Monad Tax, use `chain_id: 143`, `market: "standard"` and `launch_product: "tax"`, and require `monad-mainnet-tax-token-v2` in the deployed configuration. Select MON, USDC or WETH from that response; no stock route is available. The native launch fee is 100 MON at the documented snapshot and remains payable in MON for every quote.
For X Layer Tax, use `chain_id: 196`, `launch_product: "tax"` and a quote returned by `/config` for `xlayer-mainnet-tax-token-v2`. The dated snapshot records 48 registered quotes. Read `/config` for current availability. The launch fee is 0.02 OKB for every pair. The updated SwapX binding admits Tax and minimal-v4 Hooks; see the [router review](/launchpad/reference/production-contracts#swapx-router-upgrade-review) for its scoped verification evidence.
### Arc Tax launches
Use `chain_id: 5042`, `market: "standard"` and `launch_product: "tax"`. Require `arc-mainnet-tax-token-v2` and an available USDC or cirBTC quote from `/config`. The launch fee is **2 native USDC**, `2000000000000000000` transaction-value units; pool USDC amounts use six decimals and cirBTC uses eight. Do not register or select the zero address as an Arc Tax quote. Arc supports native-USDC Dev Buy for both pairs and held ERC-20 USDC for a USDC pair. Held cirBTC Dev Buy is not admitted by the adapter.
<span />
## \$O launches
Request `/config?chain_id=8453&launch_product=wsto&market=standard`. Use the same token fields as the request above, with these top-level values:
```json theme={null}
{
"chain_id": 8453,
"launch_product": "wsto",
"market": "standard",
"quote_address": "0x80C6BAE89B636c6Ee96FE8F198c0D6926C2C91df",
"dev_buy": {
"funding_token": "0x0000000000000000000000000000000000000000",
"amount_in_raw": "10000000000000",
"slippage_bps": 100
}
}
```
This example adds a **0.00001 ETH Dev Buy**. The route acquires \$O through USDC, deposits into the wstO vault, then buys the newly created token. The purchase burns the pool's configured percentage of its wstO amount. There is no creation fee or `tax` object. Plain creation omits `dev_buy` and sends zero value; gas is additional in both cases. See [\$O launches](/launchpad/wsto/overview).
For Robinhood, request `/config?chain_id=4663&launch_product=wsto&market=standard` and use the same request fields with `chain_id: 4663` and `quote_address: "0xE92bD1C05E4E308792003C8205127A6FA662b4D4"`. The zero-address funding token still means native ETH. The route is ETH → USDG → \$O → vault deposit → wstO → newly launched token. A held-wstO request instead uses that Robinhood vault address as `funding_token`, with 18-decimal share units. Never reuse Base's vault or stablecoin address on Robinhood.
## Atomic Dev Buy
Add `dev_buy` to an eligible Standard, Tax or \$O launch request. It contains `funding_token`, positive integer-string `amount_in_raw`, and `slippage_bps` from `1` to `4999`. Funding must be the chain's native currency or the selected paired token, as advertised in the quote's configuration. Do not send arbitrary route data.
| Funding choice | Address | Input units | Approval and transaction value |
| - | - | - | - |
| Native currency | Zero address | 18 decimals, including native USDC on Arc | No input-token approval; buy amount plus any native creation fee |
| Held paired token | Selected `quote_address` | That token's decimals | Approve the attached launch-buy adapter; native value covers only any native creation fee |
**Defaults are backward-compatible:** omitted `funding_token` means native funding for Standard/Tax, but **held wstO** for \$O launches. Send it explicitly to avoid ambiguity. \$O Dev Buy admits ETH or held wstO; its USDC, USDG and \$O trading routes are not Dev Buy funding options. Arc admits native USDC for USDC/cirBTC pairs and held ERC-20 USDC for USDC pairs, but not held cirBTC.
If `requires_reprepare` is `true`, submit the returned approval steps in order and wait for confirmation. Then repeat the original request with its `continuation_id` and a **new `Idempotency-Key`**, using the same API key and launch intent. The continuation retains the prepared metadata, salt and deadline; it does not bypass configuration, adapter, quote or allowance checks. An expired or stale continuation requires a fresh preparation.
When prerequisites pass, the response includes the final launch transaction, expected/minimum launched-token output and `review.dev_buy` funding identity, units and spender. The API does not return a provisional minimum-one purchase for signing. Creation, acquisition, any vault conversion and the initial purchase succeed together or revert together. An approval is a separate transaction and can remain even if the launch is cancelled.
Gas is additional to the entered purchase. Native funding is not launch-pool quote volume: for an ETH-funded \$O launch, the funding amount is ETH while the pool trade and burn amounts are wstO. Runtime quote failures can reflect external liquidity, vault conversion, settlement inventory, slippage or a changed binding. Follow the returned issue rather than modifying calldata.
## What preparation verifies
The API:
1. resolves exactly one active factory for the requested chain, product 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. uploads the image and ERC-75프로젝트로 돌아가기
