List the launch venues and why each is open or closed
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.
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.
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
Response Body
application/json
application/json
curl -X GET "https://example.com/launches/venues"{ "venues": [ { "provider": "erc20-direct", "chains": [ "ethereum" ], "available": true, "reason": "string" } ]}Build a token launch POST
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.
Quote the mainnet deploy fee and the remaining free launches GET
Quotes what a mainnet launch costs the caller **before** they sign, and how many free mainnet launches they have left today. Two different facts, one read, because a user deciding whether to launch needs both and neither changes between them: the fee for this specific chain, and the account's remaining daily allowance. `feePutty` is `0` while the amount is unset. That is not a price — §6.3 requires a small deploy fee in $PUTTY and §11 decision 5 chose the mechanism, but the plan fixes no amount, so putty quotes zero and says so in `note` rather than inventing a financial constant. The operator sets the amount with `MAINNET_FEE_PUTTY`. §6.3's rebate half — the fee returned once the token passes a volume or holder threshold — has no stated threshold and is not applied. This is a read: it does not consume the allowance. Only a recorded launch does, so calling it to display a price is free.