bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 35쪽 중 6쪽
72 metadata to IPFS
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` or `createLaunchAndBuy` call committed to the current configuration
9. adds required ERC-20 creation-fee or Dev Buy funding approvals to the exact spender
10. combines native Dev Buy input and any native creation fee in transaction value
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.
Omit `dev_buy` for plain creation. Include it for atomic creation and purchase. The API simulates the complete create-and-buy call, derives the minimum output and rechecks the final signable transaction. If approvals are still needed, it returns those steps and a continuation instead of provisional launch calldata.
The returned transaction `value` covers the exact native creation fee and any native Dev Buy input. The wallet must still retain native currency for gas, and performs the final gas estimate before signing.
A normal launch creates two IPFS objects: 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 uploads or simulation.
## Arc launch amounts
Use `chain_id: 5042`, the `standard` market and an available ERC-20 USDC or cirBTC quote from `/config`. The USDC pool quote has six decimals, cirBTC has eight, and 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. For native-USDC Dev Buy, use 18-decimal funding amounts in multiples of `1000000000000`; held ERC-20 USDC uses six decimals. Leave enough of the shared balance for funding, creation fees and gas.
# API migration
Source: https://docs.o1.exchange/launchpad/api/migration
Move from combined query modes to focused collection routes.
The focused routes make every displayed parameter valid for its endpoint. Earlier combined read and token-metadata forms remain available during migration and return `Deprecation` and `Link` response headers. The earlier combined claim-write route is retired; use the fee-claim route below.
<span />
## Product and funding compatibility
Existing requests keep the non-tax default. For Base, Robinhood, BSC, Monad, X Layer or Arc Tax configuration or creation, explicitly send `launch_product=tax` (query) or `launch_product: "tax"` (JSON). `market=standard` still means crypto-paired, not non-tax. Use the returned suite's token mode and `tax_format`; all six Tax deployments are ERC-20 and use `inclusive`, while Base Standard remains B20.
Do not reinterpret old BPS fields as the new six-decimal percentage units. Use [the current Tax launch object](/launchpad/api/launches#tax-token-launches), keep historical ABI decoding, and resolve existing tokens by their recorded factory. Select the matching chain and suite from the [Tax deployment table](/launchpad/integration/tax-tokens), as exposed by the deployed API, with `dividend_accounting: "fee-accrual"`. Use Claim for already-assigned rewards. Earlier Tax identities remain for indexing and direct recovery, not public transaction preparation. Fee-claim requests retain their original meaning.
\$O launches use `launch_product: "wsto"` on Base or Robinhood. This does not change omitted product selection, which remains Standard. Optional `dev_buy` supports native or admitted paired-token funding. For compatibility, omitted `dev_buy.funding_token` means native currency on Standard/Tax and held wstO on \$O launches. Specify the address explicitly for new clients and use its decimals for `amount_in_raw`.
Optional `settlement_token` on swap quotes selects the payment/receipt asset. Omitting it still means the launch pool's paired asset. Read the per-quote configuration for supported alternatives; do not reinterpret old input amounts in a newly selected currency. Approval continuations and final simulation are described in [launch preparation](/launchpad/api/launches#atomic-dev-buy).
## Route replacements
| Existing request | Focused route |
| - | - |
| `GET /tokens?q=...` | `GET /tokens/search?q=...` |
| `GET /tokens?creator=...` | `GET /creators/{address}/tokens` |
| `GET /tokens/{chain}/{token}/activity?kind=trades` | `GET /tokens/{chain}/{token}/trades` |
| `GET /tokens/{chain}/{token}/activity?kind=announcements` | `GET /tokens/{chain}/{token}/announcements` |
| `GET /wallets/{address}/claims?kind=fee` | `GET /wallets/{address}/fee-claims` |
| Retired `POST /claims/prepare` with `kind=fee` | `POST /claims/fees/prepare` |
| `POST /tokens/{chain}/{token}/metadata/prepare` with `update_name`, `update_symbol`, or `update_extra_metadata` | `POST /tokens/{chain}/{token}/metadata/onchain/prepare` |
| `POST /tokens/{chain}/{token}/metadata/prepare` with `update_profile` | `POST /tokens/{chain}/{token}/metadata/document/prepare` |
| `POST /tokens/{chain}/{token}/metadata/profile/prepare` | `POST /tokens/{chain}/{token}/metadata/document/prepare` |
Token browsing now uses self-contained sort values: `newest`, `oldest`, `trending`, `liquidity`, `market_cap`, or `volume_24h`. Do not send a separate `order` parameter.
Metadata-document preparation removes the `operation` field. Send `actor` and `document` directly and continue supplying `Idempotency-Key`.
No sunset date is currently announced. Integrations should migrate to the focused routes so unsupported parameter combinations cannot be constructed.
# API quickstart
Source: https://docs.o1.exchange/launchpad/api/quickstart
Authenticate, list launches, quote a swap, and submit wallet calldata.
## 1. Create a key
Open [Developers](https://launch.o1.exchange/developers), connect the wallet that will own the key, choose scopes, and sign the off-chain management message.
The plaintext key is displayed once:
```text theme={null}
o1_launch_a1b2c3d4_<secret>
```
Store backend keys in a secret manager. For a browser integration, use a dedicated key with only the scopes it needs and add a website restriction when appropriate.
For **\$O launches on Base or Robinhood**, request configuration with `launch_product=wsto`. Use the [launch example](/launchpad/api/launches#o-launches) for ETH or held-wstO Dev Buy and [trading assets](/launchpad/api/trading#o-launch-trades) for ETH, USDC on Base or USDG on Robinhood, \$O and wstO settlement. Omitted product selection still means Standard.
## 2. List Base launches
```bash theme={null}
curl "https://api.launch.o1.exchange/v1/tokens?chain_id=8453&market=all&sort=trending&limit=25" \
-H "x-api-key: $O1_API_KEY"
```
Use `pagination.next_cursor` as the next request's `cursor`. Cursors are opaque, short-lived, and bound to the original filters. Ranked results remain live, so a token can move between pages; de-duplicate by `(chain_id, token.address)` and restart if the API returns `409 cursor_stale`.
Use `4663` for Robinhood, `143` for Monad, `5042` for Arc, `56` for BSC or `196` for X Layer in requests for those chains.
For Tax creation or policy reads, first request `/config?chain_id=8453&launch_product=tax&market=all&active_only=false`. Token trading resolves the recorded product automatically. See [Tax launches](/launchpad/api/launches#tax-token-launches) and [Dividend actions](/launchpad/api/claims-and-creator-actions#dividend-actions) for the Tax-specific request formats.
## 3. Quote an exact-input buy
```bash theme={null}
curl "https://api.launch.o1.exchange/v1/swaps/quote" \
-X POST \
-H "content-type: application/json" \
-H "x-api-key: $O1_API_KEY" \
-d '{
"chain_id": 8453,
"wallet": "0x1111111111111111111111111111111111111111",
"token_address": "0x2222222222222222222222222222222222222201",
"side": "buy",
"amount_in_raw": "10000000000000000",
"slippage_bps": 50
}'
```
`slippage_bps` is the maximum output tolerance in basis points. `50` means 0.5%, and `100` means 1%.
The response contains:
* `quote_id`, signed and short-lived
* expected and minimum output in base units
* an `issues` array for balance or approval prerequisites
* ERC-20 approval transaction steps when required
* Permit2 typed data when an off-chain Permit2 signature is required
## 4. Prepare the swap
After completing any ERC-20 approval and signing any returned Permit2 typed data:
```bash theme={null}
curl "https://api.launch.o1.exchange/v1/swaps/prepare" \
-X POST \
-H "content-type: application/json" \
-H "x-api-key: $O1_API_KEY" \
-d '{
"quote_id": "<quote_id>",
"wallet": "0x1111111111111111111111111111111111111111"
}'
```
Include `permit2_signature` only when the quote returned a Permit2 typed-data step. The API requotes, preserves the reviewed slippage floor, builds calldata for the configured router, and simulates it. Submit the returned transaction unchanged from the specified wallet.
For an Arc USDC-paired token, a buy spends six-decimal ERC-20 USDC: `amount_in_raw: "1000000"` means 1 USDC. Complete the returned SwapX approval steps, omit `permit2_signature`, and submit the prepared swap with its returned `value` of `0`. Keep native USDC available for gas; both USDC interfaces share the same balance.
## 5. Check indexing status
After confirmation:
```bash theme={null}
curl "https://api.launch.o1.exchange/v1/transactions/8453/0x<transaction-hash>" \
-H "x-api-key: $O1_API_KEY"
```
This is the indexed public view, not a live RPC receipt endpoint. Normal chain workers discover wallet-broadcast transactions without a notification call. Use your chain provider for immediate receipt status; this endpoint may return `data: null` until the transaction is observed, then reports indexed chain and launchpad operation state.
# Read endpoints
Source: https://docs.o1.exchange/launchpad/api/read-endpoints
Search tokens and read launch, pool, wallet, claim, holder, and transaction state.
All read endpoints except `/health` require an API key. Product queries require an explicit `chain_id`; the API never combines chains implicitly.
## Endpoint summary
| Method and path | Returns |
| - | - |
| `GET /health` | Process health and build version |
| `GET /config` | Production contract configurations, paired assets, and capabilities |
| `GET /tokens` | Browsable and ranked token summaries |
| `GET /tokens/search` | Token search results |
| `GET /creators/{address}/tokens` | Launches created by one wallet |
| `GET /tokens/{chain_id}/{token_address}` | Token, launch, pool, market, and announcement detail |
| `GET /tokens/{chain_id}/{token_address}/trades` | Canonical trades |
| `GET /tokens/{chain_id}/{token_address}/announcements` | Creator announcements |
| `GET /tokens/{chain_id}/{token_address}/holders` | Provider-backed holder snapshot |
| `GET /wallets/{address}` | Compact launchpad wallet overview |
| `GET /wallets/{address}/activity` | Structured wallet activity |
| `GET /wallets/{address}/fee-claims` | Fee positions |
| `GET /wallets/{address}/dividends` | Indexed holder Dividend positions |
| `GET /transactions/{chain_id}/{tx_hash}` | Indexed transaction and launchpad operation state |
`GET /health` is public liveness only: it returns service status, API version, build ID, and time. It requires no API key, consumes no API-key units, and can be called from browser or server integrations. It does not guarantee that every data source or transaction preparation service is available.
Ordinary token, wallet, activity, claim, and transaction-status reads use the existing indexed or materialized launchpad data and do not add a chain RPC per request. Holder snapshots use their documented holder provider. Live contract and paired-asset sections in `/config`, swap operations, claim preparation, creator actions, and launch preparation verify the chain state they need.
## Live configuration
`GET /config` accepts `include=chains,suites,quotes`. The field names `suites` and `quotes` are retained for API compatibility; they represent launch contract configurations and paired assets. The default returns all three sections.
* `include=chains` uses the static production chain registry and does not call an RPC. Its chain capabilities report the launch token mode; Base activation is `not_checked`, while Robinhood, Monad, Arc, BSC and X Layer are `not_applicable`.
* Contract or paired-asset sections are read at one chain block and include `as_of_block`. For Base Standard, the same block also verifies B20 activation. Base Tax and \$O launches are ERC-20 and do not require that activation.
* `active_only=true` omits earlier contract configurations and paired assets that cannot create new launches.
* Stock-paired markets follow the shared public chain allowlist, platform catalog, and live factory state. An active response includes stock-paired support only when catalogued assets are registered on the live factory and creation is enabled.
* Each `suites` item exposes supported route codes, integration capabilities, contract addresses, current supply, `config_version`, and creation state. Capabilities identify creator rights, atomic launch-buy support, generic fee components, paired-asset revisions, and the creation switch without requiring clients to infer behavior from an identifier.
* The Standard/Tax configurations on Base, Robinhood, BSC and X Layer each report both `standard` (crypto-paired) and `rwa` (stock-paired) in `supported_routes` and expose their `launch_buy_adapter_address`.
* `contracts.swapx_router` identifies SwapX where configured. `universal_router` and `permit2` are optional; use the returned transaction steps rather than assuming every chain uses the same router.
* A creation fee appears only when its live amount is nonzero.
Base Standard B20 creation is available only when `chain.capabilities.b20_asset_status` is `active`. If ActivationRegistry cannot be verified, the API returns `503 temporarily_unavailable` instead of reporting a potentially executable route.
Earlier publicly supported contract configurations remain available with `active_only=false`. This does not expose index-only historical Tax suites or override public admission rules. See the [chain and product matrix](/launchpad/api/introduction#chain-and-product-support).
## Tax configuration and dividend discovery
Request Tax configuration explicitly:
```http theme={null}
GET /v1/config?chain_id=8453&market=all&launch_product=tax&include=chains,suites,quotes&active_only=false
```
Omitting `launch_product` selects `non-tax`. `market=standard` means a crypto pair; it does not select the Standard token product. `market=rwa` means a stock pair.
For public Tax v2 support, match the chain and suite using the [Tax deployment table](/launchpad/integration/tax-tokens). `active_only=false` does not opt into index-only historical deployments. Use the explicit `dividend_accounting: "fee-accrual"` capability, rather than inferring behavior from the shared version-family name.
Use each suite row's `token_mode` (`erc20` for Base, Robinhood, BSC, Monad, X Layer and Arc Tax), `launch_product`, `tax_format` (`inclusive`), `dividend_claims` capability and helper address. Chain-level token-mode metadata describes the default product and must not override the selected suite. `tax_policy` carries exact string rates, bounds, protocol clamps, anti-sniping settings and the raw holding floor. Its `percentage_scale` is `100000000`; derived `rate_scale` is `1000000000000000000000000`.
`active_for_creation` identifies the platform's selected suite for new launches. `creation_available` also requires live enabled creation and a usable quote. `active_only=false` keeps the suite visible for inspection while creation is disabled. It does not enable launches.
```http theme={null}
GET /v1/wallets/0x1111111111111111111111111111111111111111/dividends?chain_id=8453&limit=25
```
For Robinhood, use `chain_id=4663`; for BSC, use `chain_id=56`; for Monad, use `chain_id=143` in both examples above. Always require the deployed API to expose the requested suite; a contract address in these docs does not enable API support.
Dividend discovery uses indexed positions, with a default page size of 25 and maximum 50, an opaque cursor and optional `status=observed|confirmed`. These rows are candidates for live verification, not proof of a currently payable amount or a complete scan of all ERC-20 holdings. Claim preparation checks the factory-bound clone, current reward state, holder and receiver. Keep positions with previously earned rewards even after the holder sells. See [Dividend actions](/launchpad/api/claims-and-creator-actions#dividend-actions).
## \$O launch configuration
Use `GET /v1/config?chain_id=8453&launch_product=wsto&market=standard&include=chains,suites,quotes`. The product selects `base-mainnet-wsto-burn-v1` and its wstO quote. Launched tokens use ERC-20. It has no creation fee, FeeEscrow, dividend claims or Tax allocation graph. Review its returned burn rates and percentage scale separately from Standard BPS fees or Tax settings.
## Dev Buy and settlement assets
Configuration distinguishes contract support from API preparation and live adapter bindings:
| Field | Meaning |
| - | - |
| `capabilities.atomic_launch_buy` | The contract supports atomic creation and purchase |
| `capabilities.api_atomic_launch_buy` | The selected suite is supported for API Dev Buy |
| `dev_buy.api_supported` | API preparation support for the selected creation suite |
| `dev_buy.adapter_attached` / `adapter_binding_status` | Attached-adapter presence and binding checks |
| `dev_buy.quote_routes` | Per-quote route configurat프로젝트로 돌아가기
