Quote the mainnet deploy fee and the remaining free launches
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.
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.
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
Query Parameters
The chain to quote. A testnet or a local fork is free of putty's charge and reports freeOfCharge: true; the allowance is only consumed by a mainnet launch.
Value in
- "ethereum"
- "base"
- "robinhood"
- "base-sepolia"
Response Body
application/json
application/json
application/json
curl -X GET "https://example.com/launches/fee?chain=ethereum"{ "chain": "ethereum", "feePutty": 0, "feeWei": "string", "freeOfCharge": true, "freeLaunchesRemaining": 0, "dailyLaunchLimit": 1, "note": "string"}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.
Read one launch, reconciling it against the chain GET
**Reading a launch reconciles it.** A launch is recorded as `awaiting_signature` and stays there until the chain says its token exists; there is no worker, so this read is what asks. When the launch is still `awaiting_signature` and the chain reports a deployed token, this route reads the creation transaction's receipt, decodes the factory's `TokenCreated` event, and records the token address — moving the launch to `live` before answering. The response is the reconciled row, and it is the same row a later read returns. The server still never signs and never broadcasts. It reads a receipt; the transaction was signed by the caller with their own wallet and reported through `POST /tx/{id}/submitted`. A launch that cannot advance yet is still a **200**, with the row unchanged and `reconcileReason` saying why: `receipt_pending` (the node answered, the receipt is not mined), `not_submitted` (the creation transaction has no reported hash yet), `venue_blocked` (this launch names a venue that cannot build a launch), or `chain_unreadable` (the node could not be reached; `reconcileDetail` carries its sentence). A launch waiting to be mined is a normal state, not a server fault, so this route does not answer 5xx for one. Poll again. A launch belonging to another user returns the same 404 as one that does not exist.