Build a token launch
Validates the launch parameters against the provider's limits and builds the unsigned transaction that creates the token. The server does not sign and does not send: `transactions` is what the caller takes to their own wallet. A launch with any entry in `problems` has no `transactions`. Every problem is a plain sentence naming what to fix, so a caller can read them back to the user one at a time. Those problems are the caller's to fix, which is why they are a 201 with an empty `transactions` array rather than a failure: the launch is recorded, and it is unfinished. A **blocked venue** is a different thing and answers 409 (`provider_blocked`) with nothing recorded. No parameter the caller sends can unblock a venue, so recording a launch for one would imply a launch that can progress when it never can. `pons-v2`, `hookr`, `orbio` and `venue-adapter` are all blocked on every chain: use `erc20-direct` today. `GET /launches/venues` lists every venue with the reason it is closed, and a stored launch carries the same reason on `venueAvailable` / `venueBlockedReason`, so a client never reads two different explanations of one venue's state. A **mainnet launch beyond the daily allowance** answers 429 (`free_launch_quota_exceeded`) with nothing recorded. §6.3 gives the free Launch Kit's mainnet step to the first launch per day; a testnet or fork launch is never counted against it. Read the allowance and the mainnet deploy fee with `GET /launches/fee` before signing — the fee is quoted, not discovered in the transaction the user is about to sign.
Validates the launch parameters against the provider's limits and builds the unsigned transaction that creates the token. The server does not sign and does not send: transactions is what the caller takes to their own wallet. A launch with any entry in problems has no transactions. Every problem is a plain sentence naming what to fix, so a caller can read them back to the user one at a time. Those problems are the caller's to fix, which is why they are a 201 with an empty transactions array rather than a failure: the launch is recorded, and it is unfinished. A blocked venue is a different thing and answers 409 (provider_blocked) with nothing recorded. No parameter the caller sends can unblock a venue, so recording a launch for one would imply a launch that can progress when it never can. pons-v2, hookr, orbio and venue-adapter are all blocked on every chain: use erc20-direct today. GET /launches/venues lists every venue with the reason it is closed, and a stored launch carries the same reason on venueAvailable / venueBlockedReason, so a client never reads two different explanations of one venue's state. A mainnet launch beyond the daily allowance answers 429 (free_launch_quota_exceeded) with nothing recorded. §6.3 gives the free Launch Kit's mainnet step to the first launch per day; a testnet or fork launch is never counted against it. Read the allowance and the mainnet deploy fee with GET /launches/fee before signing — the fee is quoted, not discovered in the transaction the user is about to sign.
Authorization
bearerAuth A bearer token. The Account routes accept a Privy access token; the MCP transport accepts an sk- API key issued by POST /account/api-keys.
In: header
Request Body
application/json
The provider and the launch parameters.
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/launches" \ -H "Content-Type: application/json" \ -d '{ "provider": "erc20-direct", "chain": "ethereum", "params": { "name": "string", "symbol": "string", "supply": "string" }, "from": "string" }'{ "launchId": "string", "provider": "erc20-direct", "chain": "ethereum", "problems": [ "string" ], "transactions": [ { "chainId": 0, "to": "string", "data": "string", "value": "string" } ], "status": "string", "trust": { "state": "pending_signature", "tokenAddress": "string", "manifestAddress": "string", "version": 1, "deployTransaction": { "chainId": 0, "to": "string", "data": "string", "value": "string" }, "note": "string" }}List your launches GET
Every launch the authenticated user owns, newest first. A launch belonging to another user is not in this list and is not distinguishable from one that does not exist.
List the launch venues and why each is open or closed GET
Every launch venue putty has a row for, and whether it can build a launch right now. A venue that is closed is still listed, with the reason: a missing venue reads as an oversight, a refused one reads as a decision, and the reason names what would open it. All five rows of the venue table in `build-plan-artsy.md` §3.2 are always returned — putty's own rail, Pons v2, Hookr, Orbio's launchpad, and the rule for any other venue. Today only `erc20-direct` can build a launch; the other four are registered so a client can name them and show the user what putty has planned and what is missing. The same reason appears as the create route's 409 `message` and as a stored launch's `venueBlockedReason`, so a client never reads two different explanations of why a venue is closed.