# v4 from a program: open, open later, list, tokenomics, handover

Pangea v4: how a coin launches today. Every new launch is a v4 launch. A v4 coin lives on up to six chains: Robinhood Chain, Base, Ethereum, BNB Chain (BSC), Solana and Elysium. The four EVM chains and Solana carry LayerZero and Hyperlane; Elysium carries Hyperlane only. This tab is all of v4: creating a coin, chains and pairs, fees and holder rewards, opening a chain later, handing over, launching from your own wallet, the Bundle Kit, bridging, contracts and the API. Coins launched before v4 are in the v3 and v2 tabs.

Each is a POST with a JSON body and passes the same gate as every other Launch API route: the optional `X-Pangea-Key` and its address allowlist, the flood ceiling, the rate-limit headers and the per-key usage record. They are counted with the chain-read steps (authorization, pay, submit, kit and the v4 sponsored submit): 300 in ten minutes per address in all (unless the site sets another figure), none with a partner key; a custom key may set its own limit per route (`v4-open`, `v4-open-later`, `v4-registered`, `v4-tokenomics`, `v4-handover`). A browser page on another site is refused (403). Nothing is signed or sent: each answer is for your own wallet.

## POST /api/v1/launch/v4/open

- Body `{ launchId, chain }` (at most 4 KB): the launch id (32 bytes of hex) of a queued launch whose ticket gives the creator their own v4 leg, and that leg's chain, its pay chain: ethereum, base, bsc or robinhood.
- Answer `{ pre, tx, owed, quote, via, takeoverAt }`: the transactions the creator's own wallet (the ticket's creator) sends in order, every observation-cardinality bump of the pool still owed (`pre`, each mined before the next) and then the open itself (`tx`), priced now. Send before `takeoverAt`; after it Pangea's launcher sends that leg.
- Refused: 400 for a bad launch id or chain; 404 when no launch with that id is queued; 409 when the leg cannot be built for you, for example when the ticket does not verify or is another launch's, the launch has no v4 leg of the creator's, the chain is not its pay chain, the leg was launched already or dropped, is not ready yet, or its time is up; 424 when the queue or the chain cannot be read just now (try again).
- This is not an open-later: it only sends the creator's own leg of a launch still queued, on its pay chain, before `takeoverAt`. Opening another listed chain of a coin already launched, at any time, is `POST /api/v1/launch/v4/open-later`.
- Where v4 is switched on (`NEXT_PUBLIC_GAP_V4=on`); 404 otherwise. Once it is mined, list it with `POST /api/v1/launch/v4/registered`.

## POST /api/v1/launch/v4/open-later

- Opens another listed chain of a coin already launched, at any time, as the coin page's Open a listed chain card does. Two steps, each a POST with `{ id, chain, step }` (at most 32 KB), id being the coin's slug, launch id or token address and chain one of its listed chains not open yet. Each answer is `{ ok: true, step, txs, next }`: unsigned transactions for your own wallet, in order, each one decoded back and compared with what you asked before it is answered.
- Step `"authorize"`, by the coin's current creator (anyone once the role is renounced), on the coin's home chain. EVM home: `{ caller, opener, payout?, days? }` answers `authorizeOpen` on the home chain's shared bridge for `caller` (refused 403 for anyone but the current creator), priced with the bridge's own quote, lasting `days` (1 to 7, default 7). Opening Solana when the coin names no Solana payout wallet yet needs `payout` (a Solana wallet): the answer then starts with `transferCreator`, which sets it and keeps the EVM wallet, and that one must be mined before the authorisation is sent; `opener` defaults to `payout`.
- Solana home (opening an EVM chain): `{ pusher, opener, deadline?, payout?, payoutSet? }`, `pusher` being the coin's Solana creator wallet. A coin that names no EVM payout wallet yet first gets, with `payout` (an EVM wallet), the Solana `transfer_creator` that sets it and keeps your Solana payout wallet; once it landed, ask again with `payoutSet: true`. Then the answer is the shared bridge's open authorisation sent from Solana for the EVM `opener`, until `deadline` (`"1h"`, `"1d"` or `"7d"`, default `"1d"`), with its fee (Hyperlane: at most) in `feeText`.
- Step `"open"`, by the authorised wallet (or the original creator within the coin's first hour). An EVM chain: `{ opener, price, quote?, openingBuy?, devBuys?, buys? }`, price being your opening price in the quote per coin (native when `quote` is left out), `openingBuy` an optional own buy in the quote and `devBuys` (`[{ recipient, amount }]`) your own buys split to other wallets. Launch buys of OTHER wallets ride the same open (owner rule: launch buys and the bundle kit at every launch kind, open-later too): ask first with `askFor` (`[{ payer, quoteAmount, minOut?, recipient? }]`, same price and quote): the answer `{ step: "asks", asks, typedData, termsHash }` is what each payer signs (an EIP-712 LaunchBuy over this open's terms) after approving the launch core for its amount; then send their signatures in `buys` (`[{ payer, recipient, quoteAmount, minOut, deadline, nonce, sig }]`). Every signature is checked against this open's terms before anything is built, and every buy is decoded back from the open and compared. On a native quote each other wallet deposits its amount first, refundable any time: the asks then carry `funding: "deposit"` and `deposits` (one `depositLaunchBuy(nonce)` transaction per payer, value = its amount); at the open every native buy's deposit is read and a short one is refused 409 with the deposit still to send. The answer names the bundle kit (`bundleKitV4`). The coin is read from a landed open on another chain and checked against its id; the answer is the quote approval when one is needed, then the launch core's open, simulated when nothing has to be mined before it. Solana: `{ opener, price, uri, openingBuy?, devBuys?, buys? }`, price in USDC per coin and `uri` the metadata, fixed at the open; `openingBuy` your own buy and `devBuys` (`[{ recipient, amount }]`) and `buys` (`[{ wallet, amount, minOut? }]`) your list of buys to other wallets, in USDC, all funded by the opener in the same transaction; the answer is one Solana transaction for `opener`, which must be the authorised wallet, before the deadline. Launch buys of OTHER payers on Solana: `coBuys` (`{ payers: [{ payer }], entries: [{ payer, wallet, amount, minOut }] }`, at most 5 co-payers, never together with your own list): the answer is ONE version 1 transaction that the opener and every co-payer sign (each from its own USDC). Step `"kit"` (EVM): `{ launchRaw, buyRaws, preRaws?, targetBlock? }`: your open signed and not sent plus the buyers' own signed buys; the answer is the bundle (Ethereum, BNB Chain: one `eth_sendBundle`, the open first) or the ordered send plan (Base, Robinhood: no bundle relay, same block usual, not guaranteed).
- Launch buys and the bundle kit at open-later (both, as at every launch). Native-quote buys of other wallets are paid from each payer's own refundable deposit: the asks answer each payer's deposit transaction, step `"open"` answers 409 with every missing deposit (`deposits[]`, only the shortfall) until all are funded, and step `"deposits"` with `{ payer, nonces? }` lists a payer's deposits on that chain with their withdraw transactions, at any time. Solana: co-buys of other payers ride the open in one v1 transaction, up to the co-payers that fit its shape (5 with USDC, fewer with a Token-2022 quote). The Solana bundle kit: step `"open"` with `kit: true` answers the held open (signed, not sent; it answers `salt` and `mint`), step `"kit"` with `{ opener, salt, launchWire, buyers, tip }` answers the kit buyers' transactions to sign, and with `buyerWires` the Jito bundle, launch first, every buyer transaction checked.
- Refused: 400 for a bad field or step; 403 when the wallet may not do that step (not the current creator; not authorised for that chain yet, or the authorisation expired); 404 when the coin is not launched here; 409 when the chain is the home, open already or not listed, or the bridge or launch core refuses (said); 424 when a chain cannot be read right now (try again). Once the open is mined, list it with `POST /api/v1/launch/v4/registered`.

## POST /api/v1/launch/v4/registered

- Body (at most 1 KB): `{ chain, txHash }` for an open mined on an EVM chain, or `{ chain: "solana", coinId }` for Solana. The server reads the receipt, or the shared bridge's coin record on Solana, itself and lists the open from what it reads, never from the request.
- Answer `{ slug, coinId }`. A chain already listed is never replaced, so sending the same open again is harmless.
- Refused: 400 for a bad chain, hash or coin id; 409 when it cannot be read or recorded yet (try again in a minute) or is not a v4 open of this site; 422 with `code: "NOT_LISTABLE"` when the coin is open on chain but the site will not list its name or symbol (a retry will not help).

## POST /api/v1/launch/v4/tokenomics

- The tokenomics switch of one chain (`POST /api/tokenomics/v4/switch` behind this gate). Body (at most 1 KB) on an EVM chain: `{ id, chain, op, caller, vault?, settle? }` with op `"enable"` (with `vault`, an existing tokenomics vault), `"disable"` or `"clear"`. The answer is `{ ok: true, tx: { to, data, value } }` for `caller`'s wallet, or 409 `{ ok: false, error, why }` with the launch core's own refusal. The creator may only turn it on, while it is off and the role is not renounced; disable, clear and the admin's on or re-point are the platform admin's.
- On Solana the ops here are the platform admin's: `"enable"` (on or re-point, `vault` = the tokenomics account) and `"disable"` answer `{ ok, ixs, lines, facts }`, `"clear"` answers `{ ok, ix }`; a wallet that is not the admin is refused (403 on enable and disable, 409 on clear). The creator's own Solana enable is the coin page's, not this route.
- The role push after a handover is sent from the coin's home chain, whichever it is. EVM home: `op "push" { id, chain, caller }` builds `pushCreator` on the home chain's shared bridge that copies the creator role to `chain` (another open EVM chain or Solana), for the `caller` wallet to send and pay (anyone may push). Solana home: `op "push" { id, chain, pusher }` builds the Solana transaction(s) that copy it to that EVM chain, for the `pusher` wallet to sign and pay. For both, `op "role" { id, chain }` reads the home's copy against that chain's, `current: true` once it landed. `op "authorize"` (Solana home only) adds `opener` and `deadline` (unix seconds) and builds the open authorisation from Solana; for an EVM-home coin it answers 409 and names `POST /api/v1/launch/v4/open-later`. An enable refused because the chain's copy of the role is behind answers 409 with the push to send first.
- Refused: 400 for a bad field; 404 when the coin is not a v4 coin launched here; 409 when it is not open on that chain yet; 424 when the chain cannot be read right now.

## POST /api/v1/launch/v4/handover

- Body (at most 1 KB): `{ id, op: "transfer", newEvm, newSvm? }` or `{ id, op: "renounce" }`, id being the coin's slug, launch id or token address.
- Answer `{ ok: true, op, chain, coinId, tx: { to, data, value }, push }`: the transaction on the coin's home chain's shared bridge, for the current creator's own wallet (the bridge refuses any other). Without `newSvm` the coin's current Solana payout wallet is kept, read from the bridge. The home chain changes at once; `push` says how the other open chains follow: `POST /api/v1/launch/v4/tokenomics { id, chain, op: "push", caller }`, the push from that EVM home chain for your EVM wallet.
- Refused: 400 for a bad op, id, newEvm or newSvm; 404 when the coin is not launched here; 409 when it is not a full-scope v4 coin, when the shared bridge is not deployed on its home chain here, and for a Solana-home coin: its handover is the shared bridge's Solana instruction, signed on the coin page, which this route does not build; 424 when the current role cannot be read (try again).

> **Note:** The open-later, registered, tokenomics and handover routes answer 404 unless the full-scope switch is on too (`NEXT_PUBLIC_GAP_V4_FULL=on`).

Part of the Pangea documentation, v4 tab: https://www.pangea.trade/app/docs.md