Docs: Pangea v2: factory v2 launches, the full reference, and v1

Factory v2. Factory v2 made every launch from 2026-10-27 until 2026-11-02, and this tab describes it; every launch since is made by factory v3: Pangea v3 → A coin launched before factory v2 keeps the rules it launched under: V1 (earlier launches) →

By default a launch deploys the same token on all five chains at once. Each chain gets 1B tokens in its liquidity pool with degen mode off, or its equal share of 1B in all (200M on five chains) in degen mode, which is on by default on the launch form; all five pools open at the same US dollar price.

Launch on selected chains. A creator can instead pick the chains: any two to five of the five, at least one of them an EVM chain. With degen mode off, each chosen chain still gets its own 1B, so a launch on three chains is 3B in all. The token never exists on the chains left out.

Opening market cap. The creator picks the market cap the whole coin opens at, all of its chains together: $3,000 to $500,000 a chain times the chains (in degen mode $3,000 to $500,000 in all). Every chain opens at the same price, with its share. On factory v3 there is no locked supply: degen mode is normal mode, every chain minting its own 1B and pooling all of it, opening at $600 a chain ($3,000 for a coin on five chains). The least a v3 launch may open at is $600 a chain, which the platform may set between $600 and $3,000 a chain; standard mode still opens at $3,000 a chain unless the creator picks another cap. Opening market cap →

Degen mode. One switch on the launch form, on by default, makes the coin 1B in all: each chain mints and pairs an equal share, 200M (20%) on each of five chains. Turned off, each chain gets its own 1B. Degen mode →

Every token a chain mints goes into its liquidity pool from the start. There is no team allocation, treasury or vesting. Each pool starts with tokens only and collects the quote asset as people buy.

Each chain operates independently, and one thing keeps the prices together: arbitrage, which is open to anyone. Buy on a cheaper chain and sell on a more expensive one.

A launch can also set a different trading fee on each chain, send its fees to a fee receiver and spend the creator’s share through coin tokenomics. From a program, the same launch goes through the Launch API.

Each chain gets 1 billion tokens in its liquidity pool (in degen mode, its equal share of the 1B), held in a concentrated liquidity position. As the price rises, the pool sells tokens and collects the quote asset.

Each pool pays sellers from its own reserves. A chain with fewer buyers may have less quote asset available, regardless of how much liquidity exists elsewhere.

Opening market cap

The creator picks the market cap the whole coin opens at, all of its chains together: $3,000 to $500,000 a chain times the chains, in whole dollars (a total that does not divide by the chains is rounded down to a whole dollar a chain), and $3,000 a chain when left alone. The price per token is that market cap over the whole supply on every chain, and every chain opens at that one price with its share of the supply, so a $100,000 launch on four chains opens at $25,000 on each. It is signed into the launch and the contracts refuse any other, so nobody can open below $3,000 a chain.

In degen mode the market cap is likewise the whole coin's, from $3,000 to $500,000 in all: every chain reports the whole 1B, so terminals show that market cap on each chain, and each chain's pool holds its share of it. A higher opening market cap is a deeper pool: the same buy moves the price less. On factory v3 there is no locked supply: degen mode is normal mode, every chain minting its own 1B and pooling all of it, opening at $600 a chain ($3,000 for a coin on five chains). The least a v3 launch may open at is $600 a chain, which the platform may set between $600 and $3,000 a chain; standard mode still opens at $3,000 a chain unless the creator picks another cap.

Each chain has its own token contract and address, so buyers choose which chain to trade on.

A token’s address is different on every chain (unless its creator chose “Same contract address on all EVM chains”, which puts it at one address on the four EVM chains), and every one of them ends in 6ea: the last three hex digits on the four EVM chains, the last three characters of the mint on Solana. The token’s page lists every one.

Each chain has 1 billion tokens in its own liquidity pool, so 5 billion across the five chains.

Each contract reports its own chain’s 1B supply.

A launch on selected chains has a contract on each of its chains only. In degen mode every contract reports the coin’s whole 1B instead. Degen mode →

Degen mode is one switch on the launch form, on by default. The coin is 1B in all, not 1B a chain. Each of the launch’s chains mints the same share of it and puts all of that share in its pool: 200M, 20% of the supply, on each of five chains. On fewer chains each share is larger: 500M each on two.

Every chain’s contract reports a total supply of 1B, so a terminal on any chain shows the market cap of the whole coin. Circulating is that same 1B, everything minted and paired across the chains less anything burned: the bridge reserve below backs the other chains and is not extra supply, so it is never taken off circulating, and the market cap is the price times 1B.

The bridge reserve on Solana

On a launch with Solana, Solana’s mint holds the full 1B: Solana’s own share in its pool, and everything else in a bridge reserve owned by Pangea’s launch program. It can only be burned: nobody can take tokens out of it or spend them. It moves only with bridging. When tokens are bridged to Solana, the same number is burned from the bridge reserve, and when tokens leave Solana, the same number is added back to it, so Solana’s supply stays 1B.

A degen mode launch without Solana has no bridge reserve: its chains mint their shares, and every one of them reports 1B.

The opening market cap is chosen the same way as for any launch and is the whole coin's, every chain together; every chain opens at the same price, with its share. Opening market cap →

Terminals and apps calculate market cap in different ways. A token’s full market cap is the sum of its market caps on all five chains.

The price is the same on every terminal and app. You can bridge your tokens, or buy on any of the five contracts, at the same dollar price for the same number of tokens.

To see a token’s complete market cap, use its page on this site: it is the most accurate source.

A coin launched in degen mode is the exception: every chain reports the whole 1B, so each chain’s market cap is already the whole coin’s.

The differences between platforms come from how Pangea manages supply on each chain to keep prices in line. That is what keeps the price gap between chains small, and what makes a single token across many chains possible. Every platform is consistent with itself, and many of them show the same figures.

The key point: the same token, at the same price, on every chain.

You choose one of the launch’s chains to pay on and pay once, from your own wallet, in that chain’s native asset. That one payment covers the launch on all of its chains, so you need no funds on the others.

What it pays for

• Gas on the four EVM chains. The launch transaction on each of the launch’s EVM chains (Ethereum, BSC, Base, Robinhood Chain), priced at 8,250,000 gas each, 5,000 more on the chain you pay on, at that chain’s gas price when you ask for the quote (on Ethereum, plus the 0.05 gwei extra tip its launch may bid to land in the next block), plus the 1,000,000 wei opening buy (0.000000000001 ETH or BNB) each launch makes in its own pool.
• Rent and fees on Solana. 0.0288 SOL, on a launch with Solana: the rent for the accounts the token needs there (its mint, its pool and position, its LayerZero store and escrow, its record in Pangea’s program) and the fees of the transactions that create them. In degen mode, 0.00394208 SOL more for the bridge reserve’s accounts.
• Tokenomics, when you turn it on. 450,000 gas on each EVM chain to set up the coin’s vault there, and on a launch with Solana a “Solana tokenomics setup” line on the form: 0.01512 SOL, or 0.027 SOL when Solana’s split has a liquidity share.
• A platform margin. 20% on top of that cost, for gas moving between the quote and the launch and for a chain that has to be retried.

So the amount is not fixed. It moves with gas prices on the four EVM chains and with the prices of ETH, BNB and SOL. It is quoted when you prepare the launch, and the launch page shows it in the asset you pay in, with its approximate US dollar value, before you sign. A quote is good for 10 minutes; once it runs out, you prepare again for a fresh one.

At today’s prices a launch typically costs about $8 to $10. For example, TEST4’s quote was $8.16: $6.80 of cost plus the 20% margin, paid as 0.0112 BNB. TEST3’s was $9.20, from $7.66 of cost.

Dev buys are off for now: the launch form does not offer one and the Launch API refuses one. Launch buys are the way to buy at launch (the V3 tab). When a dev buy is offered, it is optional. If you set one, it is your own money: it is paid on top of the fee in the same transaction, on the same chain, and shown separately. The fee then includes what the buy adds to the launch’s own cost, 150,000 gas on an EVM chain or one token account’s rent on Solana, so the platform pays no part of it.

Each launch sets a trading fee between 0.3% and 5%, once, at launch. No contract function or program instruction changes it afterwards.

By default every chain charges the same fee. A creator can instead pick a different fee on each chain, each between 0.3% and 5%: each chain's fee is signed into that chain's part of the launch and is just as fixed.

The platform takes 20% of the trading fee, with a floor of 0.2% of volume. The creator receives the rest.

80% of platform fees go to PANGEA buybacks.

Who receives the creator’s share. The creator wallets, unless the launch names a fee receiver or turns on tokenomics. Creator wallets and fee receiver → On Solana, the fee split is enforced by Pangea's splitter program.

Where the fee goes can change. Only the platform can move the creator’s share to another address. A coin launched before factory v2 works differently: V1 trading fee →

From 2026-10-27 until 2026-11-02, every launch on Ethereum, Base, BSC and Robinhood Chain came from factory v2. Solana was unchanged: its launches kept going through the same splitter program. Factory addresses →

What is new for a launch

• The coin’s own tokenomics v2 vault can be named as its fee receiver. The factory checks it, and refuses a vault made for any other launch or creator.
• A tokenomics v1 vault is accepted as the fee receiver only when every EVM chain of the launch is paired with its native coin.

The new fee splitter

Each EVM chain of a new launch has a FeeSplitterV2. The trading fee and the split between the creator and the platform are fixed for good. The fee receiver can be moved, in two steps: the platform proposes a new address, and the move takes effect only when that address accepts. The creator cannot move it alone.

Coins launched earlier keep the fee splitter they launched with. Their rules do not change, and they keep trading and bridging as before.

Creator wallets. Every launch names two: one EVM address and one Solana address, because an EVM key cannot receive on Solana and a Solana key cannot receive on the EVM chains. They are the coin’s creator: they own its page, its socials and its dev buy, and they receive its share of the trading fees unless a fee receiver is set.

Fee receiver. Optional. It sends the trading fees to another address, such as a Safe or a partner, on the EVM chains, on Solana, or both. You stay the creator: the page, the socials and the dev buy are still yours, and only the fees go to the receiver. Left empty, the fees go to your creator wallet. Only the platform can change it later.

• An address that is a contract on one of the launch’s chains is asked about first: tick that it is your own Safe or smart wallet and that it can send on what it is paid.
• “Burn my creator fees” makes the fee receiver the burn address on every chain, for good. You stay the creator.
• With tokenomics on, the fee receiver is not used: the fees go to the coin’s vault, which pays your creator share to your creator wallet. Coin tokenomics →

The connected wallet

The creator wallets start as the wallet you have connected. Switch wallets in your wallet app and a creator wallet field that came from the old wallet follows the new one; an address you typed yourself stays as it is. A quote prepared for the old wallet is dropped, since the new wallet cannot sign for it: prepare again. Nothing changes while a payment is under way.

Creator fees on your profile

• A new launch’s creator fees show on its creator’s profile within a minute or two of launch, on every chain of the launch, Solana included, and the coin shows in the Created tab.
• Anything not read yet is said on the page, such as fees pending on a chain, instead of being shown as zero.
• When fees are paid out, the payout moves from unclaimed to claimed within about a minute.
• “Claim now” pays a launch’s fees out at once, split exactly as the automatic payout does: you send the transaction and pay its gas.

With “Spend my fee share automatically” on, the creator’s share of the trading fees goes to a vault made for that launch, not to the creator wallet. The vault spends it in the shares you set at launch. The split is fixed at launch.

• The shares add up to 100%. The form offers presets (Balanced, All burn, Liquidity, Community) or your own split.
• “A different split on each chain” sets each chain’s shares on their own. Otherwise every chain uses the same split.
• It works on every chain of the launch, Solana included. Solana takes its own treasury and community wallets.
• With tokenomics on, the fee receiver is not used, the fees cannot also be burned, and you cannot send your own chain’s launch yourself: the vault is the coin’s fee receiver.

When the vault runs

• At most once every 15 minutes on each chain, at the market price. There is no reference price, and each buy’s price impact is capped at the pool’s own fee, so a large balance is spent over several runs.
• A bucket waits until it holds enough to be worth a run: 0.15 ETH on Ethereum, 0.0015 ETH on Base and Robinhood Chain, 0.008 BNB on BSC and 0.025 SOL on Solana.
• A run pays its own gas from what it spends, at most 10% of it on the EVM chains and 2% on Solana. On Ethereum, where gas is dear, buys wait until the pool is deep enough for that.
• On Solana the liquidity bucket also repays the rent of the coin’s liquidity position there, at most 0.015 SOL.

Tokenomics v2 is set on the launch form and works on all five chains. The creator’s share of the trading fees goes to the coin’s vault, which spends it as set at launch.

• On each chain, the creator sets shares for burn, buy and hold, liquidity, holders, and up to 10 payout wallets, adding up to 100%.
• Holders are paid in the chain’s coin, in one token, or in a basket of up to 5 tokens.
• The shares and the reward tokens are fixed at launch. Each payout wallet can hand its slot to a new address in two steps. The vault’s owner or the platform can later change who is paid: the minimum holding (never below 0.01% of supply for a coin launched on v4, on its EVM chains and on Solana (0.01%); a coin whose EVM vault was made by an earlier tokenomics factory keeps 0.1%, as its vault's code is fixed; one setting covers a launch's chains, so a new launch starts at its chains' highest floor) and whether every eligible holder, the top holders or holders picked at random are paid.

When it runs

• Holder payouts run every 5 minutes. A holder is sent rewards once what it is due covers the payout’s cost; until then it stays owed and can claim.
• There is no fixed minimum: Pangea's runner spends a bucket, or pays the wallets, once what it would move is worth 20 times the run's gas, so the run's gas repayment (at most 10% of what it moves) always covers it. Pangea may also set a minimum per chain, 0 unless set; a vault made before this change keeps the minimum it was made with (0.15 ETH on Ethereum, 0.0015 ETH on Base and Robinhood Chain, 0.008 BNB on BSC; 0.025 SOL on Solana for now). Its buys are at least 15 minutes apart on EVM for a vault made before v4; a v4 coin's EVM vault needs no gap (Pangea's setting, 0 seconds unless set, at most a day); on Solana the gap is Pangea's setting, 3 seconds unless set (3 seconds to a day), and one buy may move the price only a bounded amount.

What a payout costs a holder

A holder sent rewards in the chain’s coin pays for its own payout: at most 10% of what it is due, and at most the figure below for its chain. A holder who claims for itself pays no fee, only its own transaction (on Solana, plus a one-time rent for its payout record).

Fees are paid in the quote asset: ETH, BNB or SOL. Never in the token that was launched.

Meteora supports collecting fees directly in the quote asset. Uniswap v4 collects fees in whichever token enters a swap, so fees from sells accrue in the launched token.

To convert them, the platform swaps those tokens for the quote asset when fees are claimed. This keeps extra code off the trading path, reducing the risk of a bug disrupting swaps. The trade-off is a small price impact from selling the collected tokens into the pool.

Every launch uses the same structure on each of its chains, single-sided liquidity and locked positions. The launch type determines the trading pair and any additional features.

$PANGEA is live. It launched through Pangea on all five chains, with the same five-chain structure as every other token. Trade $PANGEA →

The team holds about 19% of the total supply of $PANGEA, which is 5B summed across the five chains. Most of it is locked: about 14.4% sits in vesting contracts and is released in equal monthly steps over two years. The remaining 4.18% is a marketing treasury. Nothing is held in an anonymous wallet: every address below can be checked on chain.

Locked allocation

The locked tokens are not in a team wallet. They sit in Team Finance lock contracts on Ethereum, Robinhood and BSC, and in a Streamflow vesting stream on Solana. Each releases in equal monthly steps over 24 months, about 0.6% of the total supply a month across the four. No one can withdraw ahead of that schedule: the three Team Finance locks have no owner (it was handed to 0x…dEaD on 2026-10-24, which ends their emergency withdrawal and revocation), and the Streamflow stream cannot be cancelled by its sender or its recipient.

Marketing treasury

The treasury funds marketing and growth. It is one address on every EVM chain, 0x402908cd6eB5176A1B9FdE3690CCccF41d7D54D0, named pangeatreasury.eth, pangeatreasury.base.eth and pangeatreasury.bnb.

The token uses LayerZero OFT. Transfers burn tokens on the source chain and mint them on the destination, keeping the total across the five chains unchanged. There are no wrapped tokens.

A token with the price-gap fee is the exception. When a transfer arrives on a chain where the token’s price is higher than on the chain it left, the destination may hold back part of it as the gap fee. The part held back is never minted, so it is burned: the total supply goes down by exactly that amount.

Each chain’s pool receives its tokens at launch (1 billion, or its share of the 1B in degen mode), so all of a launch’s pools open at once.

In degen mode Solana’s supply stays at 1B: when tokens are bridged to Solana, the same number is burned from its bridge reserve, and when tokens leave Solana, the same number is added back to it. Degen mode →

Standard or fast

A standard transfer takes LayerZero’s own path. On every route the verifiers attest once the source transaction has 1 confirmation, and a transfer typically arrives in 4 to 16 seconds. From Ethereum, whose blocks are slower, it takes longer. How to bridge, step by step →

A fast transfer arrives in seconds: a relayer pays the recipient at once from its own tokens and is repaid when the standard transfer lands. It costs the fast lane’s own 0.2% on top of the standard 0.2%, plus the relayer’s price, which is capped at 10%. The bridge screen offers it only when a relayer is quoting your transfer. Relayers →

What a transfer costs

• The token’s fee. The token keeps 0.2% of every transfer between chains. It goes to the platform. On a token from before factory v3 it is fixed in the token contract on the four EVM chains and nobody can change it; on Solana, the fee split is enforced by Pangea's splitter program. A factory v3 token's fee is its chain's registry figure instead, and a transfer to a dearer chain also pays the price-gap fee (below).
• The message fee. LayerZero’s price for carrying the transfer, paid in the source chain’s native asset. It is quoted for the exact transfer before you sign.
• A Solana route’s setup. The first transfer on a Solana route nobody has used yet also pays a one-time setup fee for that route. Every later transfer on it does not.

Factory v3 tokens: the price-gap fee

• The bridge fee is set per chain. On a factory v3 token the fee is not fixed in the token: each chain's gap registry sets it, from 0 to 0.5% (0.2% unless changed), and the token reads it at every send. Always take what arrives from the token's own quoteOFT (or the quote), never from a fixed 0.2%.
• The gap burn. When the token is dearer on the destination than where it left, the destination withholds part of what arrives: the price gap above the fees and a small allowance. The part withheld is never minted, so it is burned (the supply figures take it off). A transfer from a dearer chain to a cheaper one pays no gap fee.
• The least credited (minCredited). Every v3 send names the least the destination may credit after the gap fee. If it would credit less, the arrival waits at the destination and lands once the price allows it. Nothing is burned while it waits, but it cannot be cancelled: it lands only once the gap narrows enough, or when Pangea turns on the token's escape, which may take as long as the gap lasts. The bridge sets it from the estimate less your tolerance (1% by default, at most 20%).
• Held arrivals. An arrival the destination cannot price yet (its pool unreadable, or no price on record) is held, not charged and not refused, and lands when it can. The quote says so (gap state held).
• Large transfers and the price log's capacity. Each chain's price log can take only so much in one short window. A large send out of Solana may be refused until more prices are on record (GapNeedRecords: record the price, then send again), and a large arrival into Solana may wait at the destination until the window holds enough records.
• Out of an EVM chain: the price record first. A v3 send prices on the source token's price log: one entry per second, written by poke() (anyone, from a plain wallet, not a contract; network fee only, with a gas limit of at least 650,000) or by an earlier send. With too few recent entries (fewer than 2 in the last 30 seconds, 384 on Ethereum) or too little capacity left, quoteSend and send revert GapNeedRecords() (0x9a883013). Call the token's poke() in two different seconds, then send within the window. gapMaxSend() returns (maxAmountLD, perEntryLD, windowSec, minBlocks): the most one send carries now and what each new entry adds. A larger send goes in parts.
• Out of Solana: the price record first. A v3 token's Solana send prices on the store's shared price log. When it holds no recent price, the wallet first signs a small record_price transaction (its signature fee only, no rent), then the send a moment later.
• A v3 store's first opening. The first opening of a v3 token's Solana routes also creates its price log, about 0.071688 SOL of rent, paid by whoever opens it (in the setup fee shown before signing). Anyone may create it; a launch that bought "Open all bridge routes at launch" was charged for it, and if someone else creates it before the launch opens the routes, that part is not spent and is not refunded.

Routes opened at launch

A launcher can tick “Open all bridge routes at launch” on the launch page’s review step. The launch fee then also covers the setup of all four Solana routes, to Ethereum, BNB Chain, Base and Robinhood Chain, at cost plus the launch fee’s usual margin, in the same one payment. Pangea opens the four right after the Solana launch lands, so nobody pays a setup fee on that token’s routes. The box is offered only while all four routes are configured on Solana. The launch screen shows each route as it opens; a route that cannot be opened automatically is opened by hand.

A transfer of 1,000 tokens: 2 go to the platform and 998 arrive.

Bridging moves your tokens from one chain to another. It is the same token on both sides: the tokens are burned where you send them from and minted where they arrive, so nothing is wrapped and the total across the five chains does not change.

On the Bridge page

• Pick the token. Open Bridge in the menu and choose the token, or open a token’s page and use its bridge tab. A link with the token in it, such as /app/bridge?token=ptest4, opens it ready.
• Pick From and To. The chain your tokens are on now, and the chain you want them on. The swap button between them turns the route around.
• Connect a wallet. An EVM wallet for Ethereum, Base, Robinhood Chain and BSC, a Solana wallet for Solana. A route between an EVM chain and Solana needs both: one sends, the other receives.
• Enter the amount. Your balance on the From chain is read from the chain. The page shows what you send, the token’s fee, what arrives, and the message fee, before you sign anything.
• Choose Standard or Fast. Standard is the token’s own path. Fast appears only when a relayer is quoting your transfer.
• Sign. One transaction on the From chain for a standard transfer. A fast transfer may ask for an approval first. The first transfer on a Solana route that nobody has used yet may ask for a setup step first; see below.
• Wait for it to arrive. The page follows the transfer and says when it has landed. Recent transfers are listed under the card.

What it costs

• The token’s fee, 0.2%. Kept by the token for the platform, out of the amount you send. 1,000 tokens sent, 998 arrive. (A token from before factory v3. A factory v3 token's fee is its chain's registry figure, 0.2% unless changed, at most 0.5%.)
• A factory v3 token: the price-gap fee. A transfer from the chain where the token is cheaper to the chain where it is dearer also pays the price gap, burned at the destination. The quote shows the estimate before you sign; the other way is free.
• LayerZero’s message fee. Paid in the From chain’s native asset: ETH on Ethereum, Base and Robinhood Chain, BNB on BSC, SOL on Solana. It pays the verifiers and the delivery on the other side, and it is quoted for your exact transfer before you sign.
• A factory v3 token into Ethereum: Pangea's delivery. LayerZero's executor does not deliver there, so Pangea's delivery keys land the transfer; their cost is part of the network fee, in the From chain's coin (out of Solana, in SOL), and the quote shows it as its own line (Pangea delivery).
• A factory v3 token into Solana: the Solana delivery. Pangea's delivery key lands the transfer on Solana; its cost is withheld from what arrives, in the token, and shown as its own line (Solana delivery). A new wallet's first arrival also pays its token account's rent from it.
• A transfer too large for one send: every part pays. Sent in parts, each part is its own transfer and pays the full network fee (LayerZero, and any delivery above); the quote shows the fee per part and the total for all parts before the first signature. A co-signed transfer (one send) shows its fee and its guaranteed minimum before you sign it.
• Gas. The transaction itself, on the From chain, as for any transaction there.

Those are live quotes from 19 October 2026, to show the size of the fee; it moves with gas prices. A transfer into Solana costs more because it also pays for the token account the tokens arrive in.

How long it takes

A standard transfer waits for its transaction to have 1 confirmation on the From chain, then for two verifiers to attest it, and is then delivered. Measured on mainnet, transfers between Base, BSC, Robinhood Chain and Solana took 4 to 16 seconds:

From Ethereum it takes longer. Ethereum makes a block only every 12 seconds, and the verifiers wait for the transfer’s block to be confirmed before they attest, so expect about half a minute or more. No transfer out of Ethereum has been measured on mainnet yet, and the Bridge page currently shows the same estimate for every route.

The fast lane

Fast is an option on top of the standard transfer. When you choose it, the transfer carries a public order on Pangea’s fast bridge, PangeaFastBridge, one shared contract per chain. A relayer sees the order and pays you on the To chain within seconds from its own tokens, and is repaid when your standard transfer lands. It costs the fast lane’s 0.2% and the relayer’s price on top of the standard 0.2%, and the price is fixed in the order before you sign. If nobody fills the order, your tokens still arrive the standard way and you get the relayer’s fee too. How relayers work →

• Fast appears only when a relayer is quoting your route and amount. Otherwise only Standard is offered.
• Into Solana it needs the token to allow a 232-byte message. Tokens launched from the current factories allow 256; some earlier launches allow 200, and for those the page offers Standard only into Solana.
• A fast transfer may need an approval first: the fast bridge moves the tokens for you, once.

Solana

• Into Solana, the recipient is a wallet. Name the Solana wallet that will own the tokens, not a token account. The tokens arrive in that wallet’s token account for the token, which is created on delivery if it does not exist.
• That account’s rent is in the message fee. Every transfer into Solana carries 2,074,080 lamports (about 0.002 SOL), the rent of a new Token-2022 account, paid in the From chain’s asset as part of LayerZero’s fee. You need no SOL to receive. For a factory v3 coin today, the first arrival to a new wallet instead has that rent withheld from the tokens that arrive (the quote’s gap.delivery.ata), and an arrival too small to pay it waits on Solana until the account exists (gap.warning).
• The first transfer on a route pays its setup. A token’s route between Solana and a chain is opened the first time anyone uses it. That first transfer also pays a one-time setup fee: the rent of the accounts LayerZero keeps for the route. The page shows it as a separate line and may ask for two steps. Every later transfer on that route, by anyone, does not pay it.
• Out of Solana, you pay in SOL. The message fee and the transaction fee are paid from your Solana wallet, so keep a little SOL there.
• Amounts cross at six decimals. The odd base units below 0.000001 token stay in your wallet.

If a transfer seems stuck

• Look it up on LayerZero Scan. Paste the transaction hash or signature of your send at layerzeroscan.com. It shows each verifier’s attestation and the delivery, with links to both transactions.
• Inflight or confirming. The verifiers are waiting for the confirmation or attesting. Wait: this is the ordinary state for the first seconds, and longer from Ethereum.
• Verified but not delivered. Delivery is open to anyone once a message is verified. LayerZero’s executor delivers it, and Pangea runs its own delivery service that delivers every Pangea token’s messages as soon as they are verified. If one sits verified and undelivered for more than a few minutes, anyone can deliver it by calling the destination endpoint’s lzReceive with the message, at their own gas cost. The exception: a factory v3 token's charged arrival into Solana, which only Pangea's appointed deliverers may land.
• Into Solana, on a route that is not open. A transfer sent into Solana before its route is opened waits, and is delivered once the route is opened; LayerZero Scan may show it as blocked until then. Nothing is lost in between. The Bridge page opens the route as part of the first transfer on it.
• A held fast order. When a fast order cannot be paid on the To chain, the fast bridge holds it for the sender. The Bridge page shows a button that sends it back; anyone may do it, paying LayerZero’s fee for the trip back.
• Nothing on LayerZero Scan. The send did not go through on the From chain. Check it on that chain’s explorer: if it failed, the tokens never left your wallet.

One token, five contracts

• An address per chain. A token is a LayerZero OFT contract on each of Ethereum, Base, Robinhood Chain and BSC, and a mint on Solana, held by LayerZero’s OFT program. The five addresses are all different (or, with “Same contract address on all EVM chains”, one on the four EVM chains and the mint on Solana) and all end in 6ea. They are on the token’s page and in /api/pools.
• 1B per chain. Each chain mints its own 1 billion at launch, all of it into that chain’s pool, 5 billion across the five. On an EVM chain launchSlice() is that 1B and launchTotal() the 5B (on a launch on fewer chains, 1B for each of them). Nothing can mint more: there is no mint function and no minter. In degen mode each chain mints its equal share of 1B instead, and launchTotal() is the 1B.
• Burn and mint. A transfer burns the tokens on the chain it leaves and LayerZero’s message mints the same number on the chain it reaches. On an EVM chain the token’s fee is moved to bridgeFeeTo() and only the rest is burned, so what is burned on one side is exactly what is minted on the other. A factory v3 token's price-gap fee is the exception: the destination withholds it and never mints it.
• What is on a chain, and what is reported. On each EVM chain localSupply() is what is on that chain now; it moves as tokens cross. totalSupply() is a reported figure: it starts at the chain’s 1B, and for tokens with a SupplyReporter the platform’s reporter on that chain mirrors the token’s supply on Solana into it. A report moves no balance and mints nothing, and a factory v1 token refuses one below its own localSupply() or above launchTotal(). Earlier launches have no reporter and always report their slice. A degen mode token reports the 1B total and takes no reports.
• Peers are sealed at launch. A peer is the token’s counterpart on another chain, the only address it accepts a mint from. The factory registers the four peers in the transaction that creates the token and hands ownership to a LaunchOwner contract that is sealed from the start: sealed_() is true and it has no way to add, change or remove a peer.

How every route is set up

A route is one direction between two chains, for one token. When the factory creates a token it is, for that one transaction, the token’s LayerZero delegate, and it writes every route from a table fixed in its own constructor. Nothing is left on LayerZero’s defaults, because a default can be changed by whoever administers the endpoint.

• Libraries. The send and the receive message library are named explicitly: LayerZero’s Ultra Light Node on every chain, the same contracts the endpoint’s defaults point at today, pinned so they stay.
• Executor. LayerZero’s executor on each chain is named explicitly, with a cap on the message size.
• Verifiers. No required verifiers. An optional set of Pangea’s own verifier plus the external ones, and 2 of the set must attest before a message counts. So no single party can deliver a message: not Pangea’s verifier, and not any one external one.
• Confirmations. 1 on every source chain, Solana included: the verifiers attest once the send has 1 confirmation. Both ends of a route hold the same number.
• A gas floor. Every transfer must give the delivery at least 100,000 gas on an EVM chain, and 200,000 compute units plus 2,074,080 lamports on Solana, for the recipient’s token account. It is an enforced option, added to every send, so a sender cannot under-pay delivery.
• A message size. Up to 10,000 bytes between EVM chains and from Solana. Toward Solana 256 bytes for launches from the current factories; the factory admin can move that between 200 and 800 for launches after, never for a token that exists. A Solana transaction is small, and a cap above what Solana can deliver would let a message be sent that can never land.

That is the set on each chain, for its routes to Ethereum, Base, BSC and Solana. Robinhood Chain has two of the external verifiers, so a route with Robinhood Chain at either end uses the verifiers both chains have: Pangea, LayerZero Labs and Nethermind, 2 of 3. Every other route has 5, 2 of 5.

On Solana the same is done by Pangea’s splitter program. The program holds one route setting per destination chain, and the first transfer on a token’s route applies it to that token, once: the libraries, the executor, the verifiers in both directions, the confirmations and the gas floor. The token’s LayerZero admin and delegate on Solana is an address only that program can sign for, and the program has no instruction that changes a peer, a library or a verifier afterwards.

Why nobody can change a route later

• On an EVM chain the factory writes the routes while it is the token’s delegate, then never calls the endpoint for that token again and has no function that could. The token’s owner, the sealed LaunchOwner, has no way to name another delegate. So no key, including Pangea’s, can change a token’s libraries, executor or verifiers.
• This matters because a delegate who could name the verifiers could name itself, attest a message nobody sent, and mint. Sealing the peers alone would not close that.
• One thing stays adjustable on purpose: the gas floor. The LaunchOwner’s admin can raise or lower it, so that a chain changing its gas costs does not break bridging for good. It accepts exactly one lzReceive option and nothing else, under hard caps of 1,000,000 gas and 10,000,000 in value, so it cannot add a payment to anyone or set a floor nobody can pay. On Solana the gas floor is fixed when the route is opened.
• The other side of this: if LayerZero retires a verifier a route depends on, that route keeps working only while two of its verifiers still attest, and nobody can swap one in. A paused bridge can be lived with; a token anyone could mint could not.
• On Solana the admin can change the route setting for launches still to come. A token’s route is applied with the setting in force when it launched, and the program refuses a setting edited after that, unless the admin signs the opening; once a route is open nothing changes it.

Check it yourself

Everything above can be read from the chains, with no help from Pangea. The worked example is PTEST4, a live test launch, on Base. Its address there is 0x2dEC1F0FBe66ef78a7cec00cD1FD9c58345ED6Ea; the other addresses are in the table at the end. These are read-only calls, with Foundry’s cast and any RPC endpoint for the chain.

TOKEN=0x2dEC1F0FBe66ef78a7cec00cD1FD9c58345ED6Ea
ENDPOINT=0x1a44076050125825900e736c501f859c50fE728c
RPC=your-base-rpc-endpoint

# its counterpart on Ethereum, BSC, Robinhood Chain and Solana
for EID in 30101 30102 30416 30168; do
  cast call $TOKEN "peers(uint32)(bytes32)" $EID --rpc-url $RPC
done

# the owner is a LaunchOwner, sealed: true
OWNER=$(cast call $TOKEN "owner()(address)" --rpc-url $RPC)
cast call $OWNER "sealed_()(bool)" --rpc-url $RPC

# the delegate, the only key that can set verifiers, is the factory that launched it
cast call $ENDPOINT "delegates(address)(address)" $TOKEN --rpc-url $RPC

EID=30416
SEND_LIB=$(cast call $ENDPOINT "getSendLibrary(address,uint32)(address)" $TOKEN $EID --rpc-url $RPC)
cast call $ENDPOINT "isDefaultSendLibrary(address,uint32)(bool)" $TOKEN $EID --rpc-url $RPC
cast call $ENDPOINT "getReceiveLibrary(address,uint32)(address,bool)" $TOKEN $EID --rpc-url $RPC

# verifiers: (confirmations, required count, optional count, threshold, required, optional)
ULN=$(cast call $ENDPOINT "getConfig(address,address,uint32,uint32)(bytes)" $TOKEN $SEND_LIB $EID 2 --rpc-url $RPC)
cast decode-abi "f()((uint64,uint8,uint8,uint8,address[],address[]))" $ULN

# executor: (max message size, executor)
EXE=$(cast call $ENDPOINT "getConfig(address,address,uint32,uint32)(bytes)" $TOKEN $SEND_LIB $EID 1 --rpc-url $RPC)
cast decode-abi "f()((uint32,address))" $EXE

# the gas floor every send carries
cast call $TOKEN "enforcedOptions(uint32,uint16)(bytes)" $EID 1 --rpc-url $RPC

What those return for this token, read on 19 October 2026:

The three optional verifiers it returns are Pangea’s on Base, 0x6dbFda44baB6bf0DDF3E9F88d7823eDdB48f4b25, and LayerZero Labs’ and Nethermind’s there. Toward Solana the same read returns 5 verifiers and an executor cap of 200 bytes: this token was launched before the factories raised it to 256. The gas floor toward Solana reads 0x00030100210100000000000000000000000000030d40000000000000000000000000001fa5e0: 0x30d40 is 200,000 compute units and 0x1fa5e0 is 2,074,080 lamports.

On LayerZero Scan, look up the token’s address, or any transfer. Its transfer from Base to Robinhood Chain on 16 October 2026, 0x5860a6920fd6fe6d97f7d88104d6ce105bb43fd4a9654d7d84cdd9229e961f65, shows all three of the route’s verifiers attesting, and the delivery five seconds after the send. Each message lists the verifiers that attested and the lzReceive gas it carried.

On Solana, a token’s route to a chain is open when LayerZero’s receive config account for it exists: the ULN program’s address for the seeds "ReceiveConfig", the chain’s endpoint id as four big-endian bytes, and the OFT store. Its contents are the confirmations and the verifiers, in the same order as above. For PTEST4, read on 19 October 2026, the routes from Base and Robinhood Chain are open, each with 1 confirmation and 2 of its verifiers, and the routes from Ethereum and BSC are not open yet: nobody has bridged on them. Bridging from code → has a script that checks it.

A relayer pays the recipient on the destination chain within seconds, out of its own stock of the token, and is paid back, plus its fee, when the bridged tokens arrive over the standard path a few seconds later. Nobody has to trust it: the recipient, the amount and the fee are fixed by the order, and a relayer that pays anything else is simply never repaid. If no relayer fills an order, the transfer arrives the standard way, and the fee no relayer earned goes to the recipient.

There is one fast bridge per chain, shared by every token launched on Pangea. A new token can use it the moment its launch lands: nothing is deployed for it. An order names its launch, never a token address, and the bridge reads the token itself from Pangea’s own factories, so a relayer is only ever repaid in, and a recipient only ever paid in, that launch’s own token on that chain.

What a transfer costs, and who is paid

• The token’s fee. The token keeps 0.2% of every transfer between chains, on either lane. It goes to the platform.
• The fast lane’s fee. On the fast lane the fast bridge keeps 0.2% first, also for the platform, and the token’s fee is then taken from what is left. The bridge’s admin can change it, per launch or for all, but never above 1%.
• The relayer’s fee. This is a price, not a platform fee. Relayers publish what they charge and the app takes the lowest. The bridge refuses any order that would pay a relayer more than 10% of what arrives, or the lower cap its admin sets.
• Your limit. You set a slippage, 0.5% unless you change it and 10% at most. If the best relayer price is above it, no fast transfer is offered, and the bridge refuses an order that would pay the recipient less.

One transfer of 1,000 tokens, three ways, with a relayer charging 0.1% as the example price:

On the fast lane the fast bridge keeps 2 tokens and the token keeps 1.996, so 996.004 are on their way. The relayer pays the recipient 995.007996 at once and receives the 996.004 when they arrive, keeping 0.996004. Both platform fees are taken on the chain the transfer leaves, when it is sent, so a fast transfer that nobody fills has still paid them.

Becoming a relayer

Anyone can be a relayer. There is nothing to apply for and nothing to stake: you publish a price, watch for orders and fill the ones you want. Filling is never an obligation, and leaving an order unfilled takes nothing from anyone. It does count against you if the order was posted at your published price, as described under benching below.

What follows is the whole protocol, two HTTP calls and a handful of contract calls, and any program that follows it is a relayer. The HTTP calls are for the price board only: watching and filling work entirely on chain.

1. What you need

• The token, on every chain you deliver to. Fills are paid from your own wallet. The fast bridge holds no stock of its own.
• An approval. On each of those chains, approve that chain’s fast bridge to move your tokens: approve(fastBridge, amount) on the token. Without it your prices are not taken and a fill reverts.
• Gas. A fill is a transaction on the destination chain, paid in its native asset: ETH on Ethereum, Base and Robinhood Chain, BNB on BSC.
• An RPC endpoint for each chain. You read OrderPosted logs on the chains orders leave and send fills on the chains they go to, so the endpoint must serve eth_getLogs. A WebSocket endpoint makes you faster: subscribed to the fast bridge’s logs it tells you about an order the moment it is posted.
• One key. The address that signs your prices is the address the app checks for tokens and approval, so sign with the wallet you fill from.

Check a bridge before you approve it. tokenOf(launchId) returns the token it moves for a launch, read from Pangea’s factories (isFactory(factory) says which it accepts), and remoteBridge(eid) its counterpart on another chain.

2. Publish your price

You send a signed price sheet to the price board. The board is public: read it to see the prices you are competing with, the ceiling, and who is benched. A route is a pair of chains on one shared bridge, so one price covers every token on that route; the app only takes it for a transfer when you hold that token on the destination.

{
  "sheet": {
    "v": 1,
    "relayer": "0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
    "issuedAt": 1760000000,
    "expiresAt": 1760000120,
    "routes": [
      {
        "fromEid": 30184,
        "toEid": 30102,
        "bridge": "0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
        "feeBps": 10,
        "minFee": "1000000",
        "maxAmount": "50000000000000"
      },
      {
        "fromEid": 30101,
        "toEid": 30102,
        "bridge": "0xcccccccccccccccccccccccccccccccccccccccc",
        "feeBps": 10,
        "minFee": "1000000",
        "maxAmount": "50000000000000"
      }
    ]
  },
  "signature": "0x<65-byte signature, 130 hex characters>"
}

The signature is over the text below, signed as an Ethereum personal message: EIP-191, which wallets offer as personal_sign. The lines are joined by a single newline with none at the end, addresses are in lower case, and the routes are sorted by fromEid, then toEid, then bridge, whatever order the JSON lists them in. This is the text for the body above:

Pangea relayer quotes v1
relayer: 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
issued: 1760000000
expires: 1760000120
30101>30102 0xcccccccccccccccccccccccccccccccccccccccc 10bps min 1000000 max 50000000000000
30184>30102 0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 10bps min 1000000 max 50000000000000

Your fee for a transfer is feeBps of what arrives, rounded up, and never less than minFee. If that comes to more than the ceiling allows on that transfer, or the transfer is larger than maxAmount, you have no price for it.

A sheet stops counting at its expiry, so publish again before then. Every 30 seconds is plenty, and the board accepts 120 publishes per caller in ten minutes. Each new sheet replaces your last one and must carry a later issuedAt. Stop publishing and you are off the board when your last sheet expires.

{
  "now": 1760000030,
  "maxFeeBps": 1000,
  "sheets": [
    {
      "sheet": "<a sheet, as published>",
      "signature": "0x<its signature>"
    }
  ],
  "benched": [
    {
      "relayer": "0x<address>",
      "until": 1760003600
    }
  ],
  "neverBenched": [
    {
      "relayer": "0x<address>",
      "strikes": 1
    }
  ]
}

Reading is limited to 300 requests per caller in ten minutes. maxFeeBps is the ceiling in force, sheets every live sheet with its signature, and benched the relayers whose prices are not being taken, with the unix second each bench ends. neverBenched lists the relayers this deployment never benches that have strikes within the hour, with how many.

How the app chooses. For each transfer it works out every live sheet’s price and looks at the 4 lowest, lowest first. Between equal prices the sheet with the earlier issuedAt comes first. It takes the first whose relayer holds what the fill pays, in that launch’s token on the destination chain, and has approved the fast bridge there for it. Benched relayers are left out. If that price would leave the recipient less than the sender’s slippage allows, no fast transfer is offered. When no relayer quotes a transfer at all, the fast lane is simply not shown.

3. Watch for orders

Every fast transfer is an order, posted on the fast bridge of the chain it leaves. That bridge emits one event for it:

event OrderPosted(
    bytes32 indexed orderId,
    bytes32 indexed launchId,
    uint32 dstEid,
    bytes32 indexed sender,
    uint64 senderNonce,
    bytes32 to,
    uint256 amount,
    uint256 relayerFee,
    uint64 lzNonce
);

Orders from Solana

An order from Solana is posted by Pangea’s fast-bridge program (post_order) and carried by the sender’s own OFT send, in the same Solana transaction. On an EVM destination, for source endpoint 30168, the order’s srcBridge is the sender’s own key (the OFT’s composeFrom), and the sender in the order is always taken to be that key: nobody can post in another’s name.

Verify before you fill. Skipping post_order only skips the fast lane’s fee, so an EVM-side check cannot tell you the order was paid for. Before filling an order from Solana, read the Solana transaction yourself and fill only when it holds both the post_order instruction and the OFT send it checks, with the same launch, recipient, amount and fee, and the transaction is finalized. A fill on anything less is a bet nobody else is making for you.

4. Fill

A fill is one call, made on the chain the order is going to:

function fillOrder(
    uint32 srcEid,
    bytes32 srcBridge,
    bytes32 launchId,
    bytes32 sender,
    uint64 senderNonce_,
    address to,
    uint256 amount,
    uint256 relayerFee,
    uint64 lzNonce
) external returns (bytes32 id);

srcEid is the endpoint id of the chain you saw the event on, and srcBridge the bridge that emitted it, as 32 bytes (the address left-padded with zeros): the destination accepts only a bridge it has named for that chain, else NotARemoteBridge. From Solana, srcBridge is the sender’s own key instead (see below). The other arguments are the event’s own fields, with to as the 20-byte address it pads: senderNonce_ is its senderNonce. In the same transaction the bridge moves amount - relayerFee of tokenOf(launchId) from your wallet to the recipient and records you as owed amount.

Every one of those fields is hashed into the order’s id. Change the source bridge, the launch, the amount, the recipient or the fee and you have filled an order nobody posted: you have paid someone, and nothing will ever repay you.

Check before you send, on the destination bridge. Each check is a read and saves the gas of a fill that would revert:

• filledBy(orderId) is the zero address: nobody has filled it yet.
• notYetArrived(token, srcEid, lzNonce), with token the launch’s token on this chain, is true: the order’s own message has not reached this chain. Once it has, there is nothing left to deliver early and a fill is refused.
• You hold amount - relayerFee of the token there and your approval covers it.
• relayerFee is at least your own price for that amount. You are never obliged to fill.

A fill that goes through emits OrderFilled(orderId, relayer, to, paid).

5. Get repaid

You are repaid on the chain you filled on, in the token, when the order’s own message arrives and the bridge settles it: seconds after the order was posted. The bridge checks that the message came from the launch’s own token and the source chain’s own fast bridge before it pays anyone. settlement(orderId) on the destination bridge says how the order settled:

The same order can only arrive twice from Solana, when a sender reuses a nonce. The second arrival is paid to the recipient (ArrivedAgain and SettledSlow) and the first settlement stands: each arrival brought its own tokens, so none is refused.

Sending a held order back

Anyone may send a held amount back to its sender on the chain it came from: quoteRefund(guid) gives LayerZero’s fee for the message back, and refund(guid), paying that fee, sends it (Refunded). refunds(guid) shows what is held. The bridge screen offers this button itself when a transfer it sent is held.

What earns the fee. The fee pays for delivering early with your own tokens, so a fill earns it only when both of these are true:

• The lzNonce your fill named is the nonce of the message that settles the order.
• The settlement lands in a later block than your fill. A fill settled in its own block is repaid what it paid out and earns nothing.

filledBy(orderId) and filledLzNonce(orderId) return the filler and the nonce it named. So fill as soon as you are willing to.

Ceilings

What gets you benched

When the app sends an order at your published price, it remembers that the price was yours. Each order is judged once: reporting the same transaction again records nothing. It looks at the order again from 2 minutes after it was posted and judges it once it has settled, or after 30 minutes if it still has not. An order nobody filled, or one you filled without earning the fee, is a strike against you.

After 3 strikes within 60 minutes your prices are not taken for 60 minutes, however low they are. Those are the defaults, and a deployment can set its own. Your sheets stay on the board, and benched in the board’s answer says until when.

A deployment can name relayers it never benches, in BRIDGE_RELAYERS_NEVER_BENCH: EVM addresses, or Solana accounts a sheet names and has signed with. These are its own relayers, so nobody can switch its fast lane off by posting orders at its price while its stock is busy. Their unfilled orders are still struck and shown under neverBenched, but the strikes never add up to a bench. When the setting is empty, every relayer can be benched.

• It is not a strike if any relayer’s fill earned the fee: the sender was served.
• It is not a strike if another address filled the order without earning the fee within 90 seconds of it being posted and before the block that settled it, because that fill paid the recipient early and shut you out. A fill made later, or in the settling block itself, delivered nothing early, so it does not excuse you.
• It is not a strike if you could not have filled it. When the app gives your price it reads, at one block of the destination chain, your balance of that launch’s token and your approval of the fast bridge, and it only gives your price if they cover the fill. What you could pay out is the lower of the two. An order is matched to the last quote given before it was posted, if that was no more than a few minutes earlier (an order posted long after its quote counts against nobody), so asking for the quote again later changes nothing. Only when a strike is about to be given, the app subtracts what you have paid out since in other fills of that same launch that served somebody, until the order settled (or until it is judged, if it never did), or 90 seconds after it was posted if that is later. If what is left is less than the order pays, there is no strike. So somebody draining your stock with many small orders first does not turn the larger ones after them into strikes. A fill that would excuse you but has not settled yet is waited for, up to 30 minutes after the order was posted.
• A fill counts only if it was your own direct call of the bridge’s fillOrder for that launch (not through a contract or a batch, which cannot be read), came from an EVM chain, paid someone other than you, and earned the fee: it named the order’s own message and came before the block that settled it. A fill of an order nobody posted never settles, and one that names the wrong message or lands in the settling block is repaid at once, so neither excuses anything. Fills of orders from Solana do not count, because a plain token send from Solana can make one without paying the fast lane’s fee. Moving your stock away or revoking the approval excuses nothing either, nor does running out of native gas: both are yours to top up. Repayments that arrive in the meantime are not added back.
• Into Solana only the balance read when the price was given is used, because there is no cheap list of your fills there. Orders into Solana are not judged yet.
• If a read fails, there is no strike then. The order is checked again later, a few times, and if it still cannot be checked it is dropped without a strike, and the server logs it. A rate limit or a slow node is such a failure. Having more fills in the window than are read, or more in one block than the chain will list, is not: it is no excuse, and neither is a drain made of more than that many fills. The app makes at most a few of these checks a minute, and fewer for any one relayer, so a strike can come a little later than the order was due.
• A fill does not clear earlier strikes. Each one stops counting 60 minutes after it was given.

The risks you take

Relaying is a business you run with your own money. Nothing here promises that it pays.

• A reorg on the source chain. Between your fill and your repayment, the fill is unsecured. If the source chain reorganises and the order’s transaction is gone, the message never arrives and nothing repays you. How many blocks you wait before filling is your own trade between speed and that risk. If a reorg keeps the order but moves its message to a different LayerZero nonce, you are repaid what you paid out and earn nothing.
• Filling before the order is in a block. Acting on pending transactions is the fastest way to fill and the riskiest: a transaction that has not been mined is likelier to vanish than a confirmed one.
• Inventory. You hold the token on every chain you serve, and its price moves while you hold it. Your fee is paid in the token too.
• Gas. A fill that reverts still costs gas, and gas is paid in the chain’s native asset while your fee is paid in the token. A price that does not cover gas loses money slowly.
• Time. Your tokens are out until the order settles. Settlement is run by LayerZero’s executor; if it stalls, anyone may run it, and until someone does you wait.
• Being shut out. Only one fill per order is accepted. Another address can fill ahead of you, even with a nonce that earns it nothing, and that order is then closed to you.

Contract addresses

One fast bridge per chain, shared by every launch: Ethereum, Base, Robinhood Chain and BSC (deployed 16 October 2026), then Solana. The full interface is the bridge’s ABI and INTERFACE.md. These are the addresses, and the endpoint ids a price sheet and a fill use:

Pangea is a token launchpad. Each launch deploys its token as five contracts, a LayerZero OFT on Ethereum, Base, Robinhood Chain and BSC and a mint on Solana, and opens one liquidity pool per chain at the same US dollar price. This section is the reference for reading and using it from code.

These docs are also published as Markdown, generated from the same source as this page:

Each section is also on its own, at /app/docs/<section id>.md. This section is /app/docs/integrators.md.

The five chains

The endpoint id is LayerZero’s, and it is how the token names a chain. Solana has no EVM chain id.

Units

• Every token has 9 decimals, on all five chains. An amount in base units is a whole number at 9 decimals: one token is 1,000,000,000 base units.
• A transfer between chains crosses at 6 decimals. It is rounded down to a multiple of 1,000 base units, and the odd base units stay in the sender’s wallet.
• Fees are in basis points. One basis point is 0.01%.
• The standard supply is 5 billion tokens, 1 billion in each chain’s liquidity pool at launch. On an EVM chain totalSupply() starts at that chain’s 1 billion and is a reported figure that moves no balance, so every chain shows a market cap on the same basis (LayerZero routes says how it is reported); launchTotal() is the sum across the launch’s chains, and localSupply() what is on that chain now. On Solana the mint’s supply is what is on Solana now: tokens bridged in are minted there and tokens bridged out are burned. The market cap situation explains why terminals show different market caps.
• A launch on selected chains is 1B on each of its chains only. A degen mode launch is 1B in all: each chain mints an equal share, every chain’s totalSupply() and launchTotal() report the 1B, and on Solana the mint holds the full 1B with the rest in its bridge reserve. Degen mode has the figures.
• Times in the API are unix seconds unless a field says otherwise.

Rules that surprise people

• Every launch is paid for by the person launching it, once, on the chain they pick, in that chain’s native asset. There are no free launches.
• Every launch opens at the same price on every chain, at the market cap its creator chose for the whole coin, every chain together: $3,000 to $500,000 a chain times the chains (in all, for a degen mode coin), signed into the launch. The price per token is that market cap over the whole supply. Launches before factory v2 all opened at $3,000 a chain, $0.000003 a token. Read a token’s price from the API; do not assume its opening one. On factory v3 there is no locked supply: degen mode is normal mode, every chain minting its own 1B and pooling all of it, opening at $600 a chain ($3,000 for a coin on five chains). The least a v3 launch may open at is $600 a chain, which the platform may set between $600 and $3,000 a chain; standard mode still opens at $3,000 a chain unless the creator picks another cap.
• A token has one address per chain it is on, all different (or one address on the EVM chains, for a token launched with “Same contract address on all EVM chains”), and every one of them ends in 6ea: the last three hex digits on the EVM chains, the last three characters of the mint on Solana. Read the addresses from the API. Do not assume two chains share one.
• A transfer between chains of a token from before factory v3 costs 0.2% of the amount, kept by the token for the platform, plus LayerZero’s message fee in the source chain’s native asset. A factory v3 token's bridge fee is its chain's registry figure (0 to 0.5%), and a transfer from the chain where it is cheaper to the chain where it is dearer also pays the price-gap fee, burned at the destination: the quote's gap.burned, an estimate. It is attested after 1 confirmation on its source chain and typically arrives in 4 to 16 seconds.
• Each launch sets its trading fee once, between 0.3% and 5%. No contract function or program instruction changes it afterwards.
• The first transfer on a Solana route nobody has used yet also pays a one-time setup fee for that route. Every later transfer on that route does not. Any wallet can pay it, a smart-contract wallet too, except a Safe: its transactions wait for its owners, so a Safe bridges once the route is set up. Pay it from your own wallet, as the bridge page does: a payment sent through another contract (a multicall or a router) is refunded to that contract, not to you, and one made by delegatecall is not seen at all.
• On the four EVM chains nothing can mint more of a token. On Solana the mint authority is the token's store in Pangea's deployment of LayerZero's OFT program, which mints exactly what was burned on another chain. Bridging burns on one chain exactly what it mints on another, with one exception: a factory v3 token's price-gap fee is withheld at the destination and never minted, so it is burned.
• Prices on the five chains are separate markets. They are held together by arbitrage, not by a mechanism, and can differ.

What you can and cannot do from code

• You can read every launch’s pools, prices, reserves and addresses, its trades and volume, recent bridge transfers and its metadata, over the HTTP endpoints below.
• You can trade directly against the pools: Uniswap v4 on the EVM chains, Meteora DAMM v2 on Solana. The API gives each pool’s id and venue.
• You can bridge by calling the token itself, or price a transfer over HTTP and sign the transaction it returns.
• You can launch over the Launch API: quote a launch, pay for it from your own wallet, hand it over and follow it. The price snapshot every chain launches with is still signed by the platform, after your payment is checked. Launch API →
• No API key is needed and there are no accounts. Every endpoint here is public. Where one is limited, the limit is per caller, by IP address. The Launch API has no rate limit for normal use, and takes an optional partner key: API keys and limits →.
• Do not crawl the API. Each read costs reads on five chains. Call an endpoint when you need its answer; robots.txt asks crawlers to stay out of /api/.

HTTP endpoints

All are under https://www.pangea.trade/api. They take and return JSON and need no key. Over a limit the answer is 429 with a message saying how many seconds to wait. An error is { "error": "..." }. A value the chains could not give is null rather than a guess, so check for it.

No parameters. The answer is { live, readAt, rates, blockers, launches }. When nothing has launched, live is false and launches is empty. Each launch carries:

Query: launch, a slug, or leave it out for every launch; hours, a whole number from 1 to 168, 24 unless given. The answer is { readAt, hours, cursor, rates, totals, launches }. An unknown slug is a 404. Each launch carries volumeUsd, trades, coverage, chains, candles and recent.

• coverage runs from 0 to 1. Below 1 the figures describe part of the window you asked for, not all of it. Show it, or check it.
• candles are { t, o, h, l, c, v, vu }, one per bucket that traded, where t is the bucket's start. A bucket with no trade is left out, not filled with the last price. The prices are in US dollars. v is the quote volume in each chain's own asset, so across chains it adds ether, BNB and SOL together; vu is the bucket's volume in US dollars at the same rates as volumeUsd, and null when a trade in it had no rate.
• recent is the last trades, newest first: { id, chain, timestamp, txHash, side, tokenAmount, quoteAmount, quoteSymbol, priceUsd, valueUsd }, where side is buy or sell.
• A coin's whole history, a page at a time: add trades=latest (the newest page) or trades=before:<next> (the page after the one that gave next) with launch, and limit of 50, 100 or 200. The answer is { slug, readAt, trades, next }, every chain newest first, the rows as in recent; next is null on the page that reached the first trade. The first page also carries total, every trade since the launch, and complete, whether every chain is recorded back to it.

Query: token, a slug, optional; hours, 1 to 168, 24 unless given; limit, 1 to 100, 25 unless given. The answer is { recording, hours, since, uncovered, totals, cursor, transfers }. A transfer is { id, guid, slug, from, to, at, amount, party, complete, tookSeconds }.

• recording false means this deployment keeps no record, and the list is empty for that reason, not because nobody bridged. reason says why.
• uncovered lists the chains whose sends are not recorded. A transfer out of such a chain appears as an arrival with no send.
• complete false means one side is recorded: a transfer in flight, or one that failed. The feed does not guess which.

Query: launch, a slug, required. The answer is { uri, resolvable, name, symbol, description, image, website, twitter, telegram }, or { uri, resolvable: false, reason } when the document cannot be opened. Every field is the token author’s own claim. The name and symbol that cannot be edited are the contract’s, in the pools endpoint.

{
  "slug": "<launch slug>",
  "from": "base",
  "to": "bsc",
  "amount": "1000000000000",
  "user": "0x<sender, and the recipient unless one is given>"
}

The answer is { symbol, from, to, amount, routes }, where routes holds two routes: canonical, the token’s own LayerZero transfer, and fast, the same transfer with a fast order. A route that cannot be used says why in unavailable. It carries:

Bridging from code

On an EVM chain the token is a LayerZero OFT and you call it directly. Ask quoteOFT what a transfer debits and delivers, name the delivered amount as the minimum, ask quoteSend for the message fee, and send that fee as the transaction’s value. Leave extraOptions empty: the gas the destination needs is already enforced by the token.

struct SendParam {
    uint32 dstEid;       // the destination's endpoint id
    bytes32 to;          // the recipient, left-padded to 32 bytes
    uint256 amountLD;    // base units
    uint256 minAmountLD; // the least that may arrive
    bytes extraOptions;
    bytes composeMsg;
    bytes oftCmd;
}
struct MessagingFee { uint256 nativeFee; uint256 lzTokenFee; }
struct OFTReceipt { uint256 amountSentLD; uint256 amountReceivedLD; }

function quoteOFT(SendParam calldata _sendParam)
    external view returns (OFTLimit memory, OFTFeeDetail[] memory oftFeeDetails, OFTReceipt memory);
function quoteSend(SendParam calldata _sendParam, bool _payInLzToken)
    external view returns (MessagingFee memory);
function send(SendParam calldata _sendParam, MessagingFee calldata _fee, address _refundAddress)
    external payable returns (MessagingReceipt memory, OFTReceipt memory);

event OFTSent(bytes32 indexed guid, uint32 dstEid, address indexed fromAddress, uint256 amountSentLD, uint256 amountReceivedLD);
event OFTReceived(bytes32 indexed guid, uint32 srcEid, address indexed toAddress, uint256 amountReceivedLD);

error AmountTooSmallToBridge(uint256 amount);
error SlippageExceeded(uint256 amountLD, uint256 minAmountLD);

On Solana the token is an account of LayerZero’s OFT program, SNyKyiZYU4R54SF9sYLmjCaCUsa1sC6QouNAj3x3Zzf, and a transfer out of Solana is an instruction to that program, not a contract call. Into Solana the recipient is the wallet that will own the tokens.

Launches on chain

On each EVM chain the launch factory emits one event per launch. The current factories’ addresses are in LayerZero routes.

event Launched(
    bytes32 indexed launchId,
    address indexed token,
    address splitter,
    address launchOwner,
    address locker,
    uint128 liquidity,
    uint256 dust
);

Addresses

• A token’s five addresses are in the pools endpoint, at launches[].pools[].token, and on the token’s page.
• The current launch factories, and each chain’s LayerZero endpoint, libraries, executor and verifiers, are in LayerZero routes.

On the four EVM chains you call the token itself: it is a LayerZero OFT. Out of Solana the send is an instruction to LayerZero’s OFT program, and the simplest way to build it is to ask Pangea’s API for the unsigned transaction. The signatures and events are in For integrators; the routes they travel are in LayerZero routes.

• amountLD is in base units, nine decimals. The token keeps 0.2% of it (a factory v3 token: its chain's registry figure, at most 0.5%), rounded down, and what crosses is rounded down to six decimals. quoteOFT returns both figures, exactly.
• minAmountLD is the least that may arrive, or the send reverts with SlippageExceeded. On a token from before factory v3 the fee is fixed, so the received amount from quoteOFT can be used as it is; on a factory v3 token the fee is read at every send, so ask quoteOFT right before you send.
• extraOptions stays empty. The token adds its own gas floor to every send; anything you add is added on top and paid for by you.
• A factory v3 token: send the minimum. Its oftCmd must carry your least credited after the price-gap fee: abi.encode(uint256 minCreditedLD) in the source's base units (the low 248 bits; the top byte is flags, 0). With an empty oftCmd the destination credits whatever the gap leaves. Take it from the quote's gap object (gap.minCredited, destination units; gap.minCreditedSource out of Solana), set by gapToleranceBps (default 100, at most 2000). Its bridge fee is its chain's registry figure, 0 to 0.5%: read what arrives from quoteOFT.
• to is 32 bytes: an EVM address left-padded with zeros, or a Solana wallet’s public key. Never a Solana token account.
• quoteSend gives LayerZero’s fee for that exact SendParam. Send it as the transaction’s value, with payInLzToken false. Any excess goes back to the refund address.
• No approval is needed for a standard send: the token burns from your own balance.

EVM to EVM, with viem

import { createPublicClient, http, parseAbi, pad } from "viem";
import { base } from "viem/chains";

const OFT = parseAbi([
  "struct SendParam { uint32 dstEid; bytes32 to; uint256 amountLD; uint256 minAmountLD; bytes extraOptions; bytes composeMsg; bytes oftCmd; }",
  "struct MessagingFee { uint256 nativeFee; uint256 lzTokenFee; }",
  "struct OFTLimit { uint256 minAmountLD; uint256 maxAmountLD; }",
  "struct OFTFeeDetail { int256 feeAmountLD; string description; }",
  "struct OFTReceipt { uint256 amountSentLD; uint256 amountReceivedLD; }",
  "struct MessagingReceipt { bytes32 guid; uint64 nonce; MessagingFee fee; }",
  "function quoteOFT(SendParam _sendParam) view returns (OFTLimit, OFTFeeDetail[], OFTReceipt)",
  "function quoteSend(SendParam _sendParam, bool _payInLzToken) view returns (MessagingFee)",
  "function send(SendParam _sendParam, MessagingFee _fee, address _refundAddress) payable returns (MessagingReceipt, OFTReceipt)",
]);

const TOKEN = "0x2dEC1F0FBe66ef78a7cec00cD1FD9c58345ED6Ea"; // PTEST4 on Base
const BSC = 30102;
const recipient = "0x000000000000000000000000000000000000bEEF"; // who receives on BSC
const amount = 1_000n * 10n ** 9n; // 1,000 tokens: nine decimals

const client = createPublicClient({ chain: base, transport: http(process.env.BASE_RPC) });

// What the transfer debits and what arrives: 0.2% stays with the token, the rest crosses.
const sendParam = {
  dstEid: BSC,
  to: pad(recipient), // an EVM address, left-padded to 32 bytes
  amountLD: amount,
  minAmountLD: 0n,
  extraOptions: "0x", // empty: the token already enforces the gas the destination needs
  composeMsg: "0x",
  oftCmd: "0x",
};
const [, , receipt] = await client.readContract({ address: TOKEN, abi: OFT, functionName: "quoteOFT", args: [sendParam] });
sendParam.minAmountLD = receipt.amountReceivedLD; // the least that may arrive

// LayerZero's fee for this exact transfer, in ETH.
const fee = await client.readContract({ address: TOKEN, abi: OFT, functionName: "quoteSend", args: [sendParam, false] });
console.log({ sent: receipt.amountSentLD, arrives: receipt.amountReceivedLD, nativeFee: fee.nativeFee });

// The send, from the holder's wallet, paying the fee as the value:
// await wallet.writeContract({ address: TOKEN, abi: OFT, functionName: "send",
//   args: [sendParam, fee, account.address], value: fee.nativeFee });

Run against Base on 19 October 2026, it printed sent: 1000000000000n, arrives: 998000000000n, nativeFee: 109546395808232n: 1,000 tokens sent, 998 arrive, and about 0.00011 ETH for LayerZero.

The same, with cast

TOKEN=0x2dEC1F0FBe66ef78a7cec00cD1FD9c58345ED6Ea
RPC=your-base-rpc-endpoint
TO=$(cast pad --len 32 0x000000000000000000000000000000000000bEEF)

# what is sent and what arrives: (limit), (fee details), (sent, received)
cast call $TOKEN "quoteOFT((uint32,bytes32,uint256,uint256,bytes,bytes,bytes))((uint256,uint256),(int256,string)[],(uint256,uint256))" \
  "(30102,$TO,1000000000000,0,0x,0x,0x)" --rpc-url $RPC

# LayerZero's fee in wei: (nativeFee, lzTokenFee)
cast call $TOKEN "quoteSend((uint32,bytes32,uint256,uint256,bytes,bytes,bytes),bool)((uint256,uint256))" \
  "(30102,$TO,1000000000000,998000000000,0x,0x,0x)" false --rpc-url $RPC

EVM to Solana

The same send, with dstEid 30168 and the recipient’s Solana wallet as the 32 bytes. The tokens arrive in that wallet’s token account, created on delivery; its rent, 2,074,080 lamports, is in every transfer’s gas floor and so in quoteSend’s fee.

import { createPublicClient, http, parseAbi, toHex } from "viem";
import { base } from "viem/chains";
import { Connection, PublicKey } from "@solana/web3.js";

const OFT = parseAbi([
  "struct SendParam { uint32 dstEid; bytes32 to; uint256 amountLD; uint256 minAmountLD; bytes extraOptions; bytes composeMsg; bytes oftCmd; }",
  "struct MessagingFee { uint256 nativeFee; uint256 lzTokenFee; }",
  "struct OFTLimit { uint256 minAmountLD; uint256 maxAmountLD; }",
  "struct OFTFeeDetail { int256 feeAmountLD; string description; }",
  "struct OFTReceipt { uint256 amountSentLD; uint256 amountReceivedLD; }",
  "function quoteOFT(SendParam _sendParam) view returns (OFTLimit, OFTFeeDetail[], OFTReceipt)",
  "function quoteSend(SendParam _sendParam, bool _payInLzToken) view returns (MessagingFee)",
  "function peers(uint32 eid) view returns (bytes32)",
]);

const TOKEN = "0x2dEC1F0FBe66ef78a7cec00cD1FD9c58345ED6Ea"; // PTEST4 on Base
const BASE_EID = 30184;
const SOLANA = 30168;
const owner = new PublicKey("<the Solana wallet that will own the tokens>");
const amount = 1_000n * 10n ** 9n;

const evm = createPublicClient({ chain: base, transport: http(process.env.BASE_RPC) });
const solana = new Connection(process.env.SOLANA_RPC, "confirmed");

// Is this token's route from Base open on Solana? It is once LayerZero's receive config exists.
const peer = await evm.readContract({ address: TOKEN, abi: OFT, functionName: "peers", args: [SOLANA] });
const store = new PublicKey(Buffer.from(peer.slice(2), "hex")); // the OFT store
const eid = Buffer.alloc(4);
eid.writeUInt32BE(BASE_EID);
const ULN = new PublicKey("7a4WjyR8VZ7yZz5XJAKm39BUGn5iT9CKcv2pmG9tdXVH");
const [receiveConfig] = PublicKey.findProgramAddressSync([Buffer.from("ReceiveConfig"), eid, store.toBuffer()], ULN);
const open = (await solana.getAccountInfo(receiveConfig)) !== null;

const sendParam = {
  dstEid: SOLANA,
  to: toHex(owner.toBytes()), // the owner's public key as 32 bytes, not a token account
  amountLD: amount,
  minAmountLD: 0n,
  extraOptions: "0x", // the token adds the gas floor and the rent of the token account
  composeMsg: "0x",
  oftCmd: "0x",
};
const [, , receipt] = await evm.readContract({ address: TOKEN, abi: OFT, functionName: "quoteOFT", args: [sendParam] });
sendParam.minAmountLD = receipt.amountReceivedLD;
const fee = await evm.readContract({ address: TOKEN, abi: OFT, functionName: "quoteSend", args: [sendParam, false] });
console.log({ store: store.toBase58(), routeOpen: open, arrives: receipt.amountReceivedLD, nativeFee: fee.nativeFee });
// Then send exactly as from EVM to EVM. With routeOpen false, the transfer waits on Solana
// until the route is opened: see the route setup below.

If the token’s route from that chain is not open on Solana yet, a transfer sent now waits there until it is. To open it as part of your transfer, as the Bridge page does, POST /api/bridge/quote returns the setup payment in routePayment: send it first, then report it to POST /api/bridge/route-open, which opens the route or refunds the payment, and then send the transfer. API reference →

Solana to EVM, with @solana/web3.js

Out of Solana the send is LayerZero’s OFT program’s own instruction, with about thirty accounts and a lookup table. POST /api/bridge/solana-tx builds it, unsigned, for your wallet to sign: it names the accounts, sets the minimum to what arrives, and adds the route’s opening when a route is used for the first time. You pay LayerZero’s fee and the transaction fee in SOL; the token’s 0.2% is kept in the OFT store’s escrow for the platform.

import { Connection, VersionedTransaction } from "@solana/web3.js";

const API = "https://www.pangea.trade/api";
const sender = "<the Solana wallet holding the tokens>";
const recipient = "0x000000000000000000000000000000000000bEEF"; // who receives on Base
const amount = (1_000n * 10n ** 9n).toString(); // 1,000 tokens, in base units

const post = (path, body) =>
  fetch(API + path, { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify(body) })
    .then(async (r) => ({ status: r.status, body: await r.json() }));

// The price: what arrives on Base, and LayerZero's fee in lamports.
const quote = await post("/bridge/quote", { slug: "ptest4", from: "solana", to: "base", amount, user: recipient, recipient, solanaUser: sender });
const standard = quote.body.routes?.find((r) => r.id === "canonical");
if (!standard || standard.unavailable) throw new Error(standard?.unavailable ?? quote.body.error);
// A factory v3 token: what arrives is amountOut less the gap estimate, never less than gap.minCredited.
const gap = standard.gap ?? null;
console.log({ credited: standard.amountOut, gapBurned: gap?.burned, nativeFee: standard.nativeFee, setupFee: standard.setupFee ?? null });

// The unsigned transaction: the OFT send, and the route's opening if it is not open yet.
// A factory v3 token's send must name its minimum (minCredited, Solana base units): without one it is refused (400).
const ask = { slug: "ptest4", to: "base", amount, sender, recipient, ...(gap ? { minCredited: gap.minCreditedSource } : {}) };
let built = await post("/bridge/solana-tx", ask);
// 202 { pending: true }: a price record or a route opening is still landing -- ask again in a moment.
while (built.status === 202) {
  await new Promise((r) => setTimeout(r, 2_000));
  built = await post("/bridge/solana-tx", ask);
}
// stage "record" (a v3 token with no recent price on record): sign and send it, then ask again with
// { ...ask, recorded: <its signature> }; the answer is then the send.
if (built.status !== 200) throw new Error(built.body.error ?? `stage ${built.body.stage}`);
const tx = VersionedTransaction.deserialize(Buffer.from(built.body.transaction, "base64"));

// Check it before signing: a simulation sends nothing.
const connection = new Connection(process.env.SOLANA_RPC, "confirmed");
const sim = await connection.simulateTransaction(tx, { sigVerify: false });
console.log({ stage: built.body.stage, received: built.body.received, totalFee: built.body.totalFee, error: sim.value.err });

// Sign with the sender's wallet and send:
// const signed = await wallet.signTransaction(tx);
// await connection.sendRawTransaction(signed.serialize());

Run read-only on 19 October 2026 from a Solana holder, it built a transaction at stage send with received: 998000000000 and a fee of at most 636,478 lamports, and the simulation passed. The stages are send, the transfer alone; together, the route’s opening and the transfer in one transaction; and setup, the opening alone, after which you ask again with after set to its signature. A factory v3 token adds record: the price record its send needs first (its signature fee only), after which you ask again with recorded set to its signature. A 202 with pending: true means the step before is still landing: ask again in a moment. A v3 token's send also needs minCredited (the quote's gap.minCreditedSource), or it is refused with a 400.

After the send

• The send emits OFTSent(guid, ...) on the source chain and the delivery OFTReceived(guid, ...) on the destination. The guid is the transfer’s id on LayerZero Scan.
• Look the guid or the transaction up on LayerZero Scan to follow it, or poll the destination for OFTReceived with that guid.
• Delivery needs nothing from you. If a message sits verified and undelivered, anyone may deliver it, except a factory v3 token's charged arrival into Solana, which only Pangea's appointed deliverers may land.

All endpoints are under https://www.pangea.trade/api, take and return JSON, and need no key or account. The general rules are in For integrators, which also describes five of them in full: pools, history, bridge activity, token metadata and the bridge quote. The relayers’ price board is in Relayers. This section lists all of them and describes the rest.

• An error is { "error": "..." } with a 4xx status (a 5xx is a fault, and its body may be a proxy's own). A value the chains could not give is null, not a guess.
• Limits are per caller, by IP address, counted on each server. Over a limit the answer is 429 and the message says how many seconds to wait; some also send Retry-After.
• A JSON body that is too large is 413, one that is compressed is 415, one that does not arrive within 10 seconds is 408, and one that is not a JSON object of the expected fields is 400.
• Call them from a server or a script. Only the supply endpoints (/supply/[token] and its two plain-number forms), /gap-price/[id] and /gap-price/quote-usd send Access-Control-Allow-Origin: *; the rest send no CORS header, so a web page on another site cannot read them from the visitor’s browser.
• Answers are cached briefly in front of the app (most for 5 to 60 seconds, as each endpoint says), so polling faster than that returns the same answer.
• Amounts are base units as decimal strings. Chains are named ethereum, base, robinhood, bsc and solana. A launch is named by its slug.
• Three endpoints answer as a stream of server-sent events: data: <json> lines, with content-type: text/event-stream. Read them with a streaming fetch; they are POST, so an EventSource cannot open them. The Launch API’s event stream and the launches stream are GETs, in the same format with named events.
• A coin is named by its slug, its launch id or any chain’s token address wherever the path says [id]. The coin, its supply, the pools, the holders and the launches feed carry degen and the coin’s supply: circulating, the bridge reserve and where it is held, the total, and what each chain mints and each token reports.

Every public endpoint

GET /coin/{id}

One coin as the site knows it, with no chain read: { slug, name, symbol, launchId, listedAt, launchChains, chains, degen, factoryGen, supplyMode, factoryV3, supply, tokenomics, tokenomicsKnown }. chains is each chain’s { token, pool, quote }; quote is the asset its pool pairs with: "native", or { address, ticker, symbol, issuer, known } for a coin paired with a tokenized stock on that chain, found by the stock token's address (known: false for an asset the stocks table does not list). A stock-paired EVM chain can show pool: null until its pool is listed. factoryGen is 1 or 2; factoryV3: true marks a factory v3 coin (absent before v3); supplyMode is factory v2’s, 0 (1B on each chain) or 1 (degen mode), and null on a factory v1 coin. tokenomics is the config the launch’s quote signed, or null for none; tokenomicsKnown: false means it could not be read, so null is then not “none”. Errors: 400 for an id that cannot be a coin’s, 404 for one not launched here.

GET /coin/{id}/supply

The answer is { slug, name, symbol, launchId, launchChains, degen, supply, live, liveError? }. supply is the same as on the coin. For a degen mode coin, live is read from the chains and kept a minute: { mode, total, reserve, circulating, burned, burnedUnread, perChain, burnedPerChain, reserveAddress, decimals, onSolana, chains }, in base units as strings, where total is what the tokens report, reserve what Solana’s bridge reserve at reserveAddress holds now, and circulating the total less what was burned (never less the bridge reserve, which backs the other chains and is not extra supply); perChain is what is on each chain, Solana’s its own float with the bridge reserve apart. A figure the chains did not give is null. live is null for any other coin and with ?live=0; liveError: "busy" means the shared budget of chain reads is spent for the minute.

GET /coin/{id}/tokenomics

The answer is { slug, name, symbol, launchId, launchChains, tokenomics, tokenomicsKnown, chains }. tokenomics is the coin’s config, as on the coin. chains is each chain’s vault read from the chain, { tokenomics }, or null with an error when that chain could not be read. A vault has its split, buckets (what waits in each, in the chain’s native unit), spent, and totals: receivedWei, coinBurned, coinToTreasury (bought and held), liquidityAdded, gasRepaidWei. A coin its launch’s config says has no tokenomics is read on no chain. ?live=0 answers the config alone. Each chain’s reading is shared with the coin page and kept a while: a vault five minutes, no vault 24 hours, a chain that could not be read half a minute. 404 while tokenomics is switched off on this deployment.

GET /v1/launches

Every coin launched here, newest first: { launches, next, latest, readAt }. Each launch is { id, slug, name, symbol, launchId, listedAt, launchedAt, launchChains, chains, coinId, v4, degen, factoryGen, supplyMode, factoryV3, supply, tokenomics, image, platform }: chains each chain’s { token, pool, quote } (quote as in GET /coin/{id}), factoryV3 true for a factory v3 coin, supply is { total, circulating, reserve, reserveChain }, tokenomics is { on: false }, or { on: true, version, vault, buckets, chains } naming the buckets any chain uses, or null while it is not known; image the coin’s logo on this site, or null until it is stored. For a v4 coin, coinId is its coin id and v4 is { coinId, home, listed, open, notOpen, transports, role: { creatorEvm, creatorSvm, renounced } }: its home chain, the chains it lists, which of them are open now, its transports and its creator role; each open chain carries openedAt, unix seconds. Both are null for any other coin. A coin is listed once it has landed and its pools are open. id is its cursor, <listedAt>:<slug>.

• limit: 1 to 100, 25 by default.
• before: the previous page’s next, for the page after it. next is null on the last page. To catch up, send the same since with each page.
• since: a cursor, for the coins listed after it, or unix seconds, for the coins listed in that second or later. A coin can be listed a little after one with a later time, so to catch up, ask from a minute or two before the newest you have and drop the ids you already hold.
• latest: the newest coin’s cursor. Open the stream with it as since and nothing is missed between the two.

curl -s "https://www.pangea.trade/api/v1/launches?limit=10"
curl -s "https://www.pangea.trade/api/v1/launches?limit=10&before=<next>"

GET /v1/launches/stream

Every new launch as server-sent events, the moment it is live. Each is an event: launch with the launch, as /v1/launches lists it, as its data, and, for a launch newer than any sent before, its cursor as the event id. After the first catch-up comes one event: ready with { latest }. To miss nothing across a reconnect, send the last id you saw as Last-Event-ID (an EventSource does this by itself) or as ?since=: the launches listed after it come first, oldest first, up to 100 at a time. Without either, only launches from now on. The ready event carries the stream’s place as its id too, so a reconnect before any launch still resumes. A coin can become visible a little after one listed later, so the stream also looks two minutes back and sends such a coin with no event id, keeping your place. A resume sends those two minutes again, so a launch can come twice: drop the ones whose data’s id you have. When a v4 coin already sent opens another of its listed chains later, the stream sends an event: chain_opened for that same launch, never a new launch: its data is { key, coinId, chain, openTime, slug, id, launch }, keyed by coin id, chain and open time, with no event id. Clients dedupe by coinId: a key you already hold is a repeat. A resume sends again each chain opened after your cursor’s time. A comment line comes every 15 seconds; the stream closes after 30 minutes, so reconnect with the last id. Send Accept: text/event-stream. At most 3 open per caller; it takes requests from programs and from the Pangea site, like the Launch API.

curl -N -H "Accept: text/event-stream" "https://www.pangea.trade/api/v1/launches/stream"

import { EventSource } from "eventsource";

const stream = new EventSource("https://www.pangea.trade/api/v1/launches/stream");
stream.addEventListener("launch", (e) => {
  const coin = JSON.parse(e.data);
  console.log(coin.symbol, coin.degen ? "degen" : "", coin.chains);
});
// It reconnects by itself and sends the last id as Last-Event-ID, so nothing is missed.

WebSocket /live

The socket the site’s own pages use, open to everyone and read-only: wss://www.pangea.trade/live. No key, any origin or none. You subscribe to topics and are pushed what changes: pool readings, trades, bridges and new coins. Everyone subscribed to a topic is sent the very same message, made once, so hold as many sockets as you need, up to 50 from one IP address.

It is a wake-up channel, not a second source of truth: every value on it is also the answer of a REST endpoint here. A client that misses something on the socket is right again after its next REST read, and the rules below say when one is needed.

A launch, step by step

• Subscribe to job:<launchId> (the launch id in lowercase) from the moment the fee is paid. Each message is the whole status, so replace what you hold.
• Per chain, d.result.sponsoredLegs while the launch runs (d.result.legs once it is finished) holds { state, step, at, ms?, tx?, why?, listed? }.
• step is one of paid (the fee is confirmed and the chain is queued), sending, sent (tx is the open’s hash, or its signature on Solana), confirmed, open (the pool is live), failed (why says why) or handover (the creator opens that chain from their own wallet). Steps only move forward.
• at is when the step happened, in milliseconds since the epoch. ms is how long the chain took. listed: true means that chain is in the coin list.
• d.result.coinId and d.result.coinListedAt appear the moment the coin is listed, before the job is done. From then on GET /coin/[id] answers.
• The chain the fee was paid on opens first. Every other chain then opens at the same time.

Messages

• You send JSON text of at most 1024 bytes: {"op":"sub","topics":["trades","poolsdiff"],"cursor":"s:1200,p:1762150000000123"}, {"op":"unsub","topics":["trades"]} or {"op":"ping"}. At most 12 topics on one socket. Anything else closes the socket with 1008.
• The server first sends {"t":"hello","v":1,"now":ms,"hbMs":15000,"maxTopics":12,"sources":{...}}.
• A state topic sends {"t":"pools","topic":"pools:abc","d":{...}} (and likewise launches, health, job): replace what you hold. On subscribing you are sent the current value at once.
• A log topic sends {"t":"trade","topic":"trades","seq":1201,"slug":"abc","d":{...}} (and likewise bridge, poolsdiff): apply it only if its seq is above your cursor for that stream, then move the cursor to it.
• {"t":"ready","topics":[...],"cursor":"s:1250"}: the replay of those log topics is done and they are live; the cursor is where each stream now stands.
• {"t":"reset","topics":[...],"why":"replay"}: you are not subscribed to those topics. Read them over REST, then subscribe again with the cursor that read gives. why is replay (more than 1000 rows behind), size, ahead, unavailable or busy (wait a few seconds first).
• {"t":"hb","now":ms} comes every 15 seconds. If nothing at all arrives for 40 seconds, reconnect.
• {"t":"bye","reason":"rotate","retryMs":2100} comes before the server closes the socket: rotate (every socket is closed after about 30 minutes), slow, shutdown or rate. Reconnect after retryMs.

Reconnecting without missing anything

• Keep one cursor per stream: the seq of the last trade (s), bridge (b) and pool patch (p) you applied, and subscribe with them, as "cursor":"s:1200,b:77". You are sent every row after them, then ready, then live: no gap and no repeat. Without a cursor a log topic starts from now, and ready gives you the cursor to keep.
• When the socket closes without a bye, wait a random time between zero and a ceiling that starts at half a second and doubles up to 30 seconds, reconnect, and subscribe again with your cursors.
• Slow readers are cut off, not waited for. A socket holding 256 KiB unread is not written to; meanwhile states keep only their newest value, and past 500 queued events the socket is told bye with slow. Reconnect with your cursors and nothing is lost.
• Messages you send are counted per socket, a burst of 60 and then 10 a second, pings included. Past that the socket is told bye with rate.
• Compression (permessage-deflate) is offered, and most clients take it on their own. The messages are the same either way.

The pool reading, as patches

• Read https://www.pangea.trade/live/pools: { gen, body }, where body is a pool reading in the shape of GET /pools. Then subscribe to poolsdiff with "cursor":"p:<gen>". It answers 60 reads a minute from one address: read it at the start and after a reset, not on a timer.
• Each poolsdiff event’s d.base is the gen it applies to, and its seq is the gen it makes. Apply it only on top of exactly the gen you hold. When d.body is present it is a whole new reading.
• Otherwise d is { base, top, set, order }. top holds the reading’s top-level fields. Each entry of set is a launch by slug: whole as v, or its changed fields as f and its changed pools as pools, matched by chain (each whole as v or as changed fields f). order, when present, is the new order of the slugs.
• A patch on a gen you do not hold, a reset of poolsdiff, or a patch naming a launch or pool you do not have: read https://www.pangea.trade/live/pools again and subscribe with its gen.

const LIVE = "wss://www.pangea.trade/live";
const BASE = "https://www.pangea.trade/live/pools";

let pools = null; // { gen, body }
let tradeCursor = null;
let attempt = 0; // reconnects since the last ready
const waits = {}; // topic -> how long to wait before asking for it again

function applyPatch(body, d) {
  const bySlug = new Map(body.launches.map((l) => [l.slug, l]));
  for (const e of d.set) {
    if (e.v) {
      bySlug.set(e.slug, e.v);
      continue;
    }
    const old = bySlug.get(e.slug);
    if (!old) return null;
    const l = { ...old, ...(e.f ?? {}) };
    if (e.pools) {
      l.pools = old.pools.slice();
      for (const pe of e.pools) {
        const i = l.pools.findIndex((p) => p.chain === pe.chain);
        if (i === -1) return null;
        l.pools[i] = pe.v ?? { ...l.pools[i], ...(pe.f ?? {}) };
      }
    }
    bySlug.set(e.slug, l);
  }
  const order = d.order ?? body.launches.map((l) => l.slug);
  return { ...d.top, launches: order.map((slug) => bySlug.get(slug)) };
}

async function readBase() {
  const res = await fetch(BASE);
  if (!res.ok) throw new Error(`GET /live/pools answered ${res.status}`); // 429 or 503: try again later
  pools = await res.json();
}

// Ask for one topic again later, waiting longer each time (2 s, doubling to 60 s).
function later(ws, topic) {
  waits[topic] = Math.min(60_000, (waits[topic] ?? 1_000) * 2);
  setTimeout(async () => {
    if (ws.readyState !== WebSocket.OPEN) return;
    try {
      if (topic === "poolsdiff" && !pools) await readBase();
      subscribe(ws, [topic]);
    } catch {
      later(ws, topic);
    }
  }, waits[topic]);
}

function subscribe(ws, topics) {
  const cursor = [];
  if (topics.includes("trades") && tradeCursor !== null) cursor.push(`s:${tradeCursor}`);
  if (topics.includes("poolsdiff")) cursor.push(`p:${pools.gen}`);
  ws.send(JSON.stringify({ op: "sub", topics, cursor: cursor.join(",") }));
}

async function connect() {
  try {
    if (!pools) await readBase();
  } catch {
    setTimeout(connect, Math.random() * Math.min(30_000, 500 * 2 ** attempt++));
    return;
  }
  const ws = new WebSocket(LIVE);
  let heard = Date.now();
  let retryMs = null; // from bye
  const watch = setInterval(() => Date.now() - heard > 40_000 && ws.close(), 5_000);
  ws.onopen = () => subscribe(ws, ["trades", "poolsdiff", "launches"]);
  ws.onmessage = (e) => {
    heard = Date.now();
    const m = JSON.parse(e.data);
    if (m.t === "trade" && (tradeCursor === null || m.seq > tradeCursor)) {
      tradeCursor = m.seq;
      console.log("trade", m.slug, m.d.side, m.d.valueUsd);
    } else if (m.t === "poolsdiff" && pools && m.seq > pools.gen) {
      const body = m.d.body ?? (m.d.base === pools.gen ? applyPatch(pools.body, m.d) : null);
      if (body) pools = { gen: m.seq, body };
      else {
        pools = null; // behind: start again from the base, on the same socket
        later(ws, "poolsdiff");
      }
    } else if (m.t === "ready") {
      attempt = 0;
      for (const t of m.topics) delete waits[t];
      const s = /s:([0-9]+)/.exec(m.cursor ?? "");
      if (s && tradeCursor === null) tradeCursor = Number(s[1]);
    } else if (m.t === "reset") {
      // Not subscribed to these any more. Keep the socket; ask again later, waiting longer each time.
      for (const topic of m.topics) {
        if (m.why === "replay" || m.why === "ahead") {
          if (topic === "trades") tradeCursor = null; // too far behind: fill the gap from GET /history
          if (topic === "poolsdiff") pools = null;
        }
        later(ws, topic);
      }
    } else if (m.t === "bye") {
      retryMs = m.retryMs;
    }
  };
  ws.onclose = () => {
    clearInterval(watch);
    setTimeout(connect, retryMs ?? Math.random() * Math.min(30_000, 500 * 2 ** attempt++));
  };
}

connect();

GET /holders

Query: token, a slug, required; chain, optional, to answer for one chain. The answer is { slug, readAt, launchTotal, degen, supply, chains, all }, where degen and supply are as on /coin/[id], and each of chains is { chain, count, top10Pct, rows, complete, note?, error? } and each row { chain, address, balance, pct, label }, balances in whole tokens, at most 100 rows a chain. all combines the chains, { rows, count, partial, top10Pct }, and is left out when chain is given. label names a known holder such as the pool or the bridge escrow. An answer is reused for a minute. Errors: 400 without a token, 404 for an unknown launch or a chain it is not on.

GET /bridge/balance

Query: token (slug), chain and address, all required, and asset=native to read the chain’s native asset instead of the token. The answer is { slug, chain, address, balance, decimals, reason?, reserve? }: balance in base units as a string, or null with a reason when the chain could not be read, never a false zero. On Solana the token balance is the sum of the owner’s token accounts for the mint. For the native asset, reserve is the gas the app keeps back for a trade. Errors: 400 for a missing field or an address of the wrong kind, 404 for an unknown launch or chain.

POST /bridge/quote, in full

Beyond the fields in For integrators, the body may carry slippageBps for the fast lane, 50 unless given and 1000 at most, and smartWallet, true when the sender is a contract wallet, and gapToleranceBps, a factory v3 token's tolerance under the gap estimate for the minimum credited (100 unless given, 2000 at most). The answer’s routes holds two routes, canonical and fast, and a route that cannot be used says why in unavailable. Besides the fields listed there, a route may carry:

Further errors: 409 when the token has not launched on the destination, 424 when a Solana recipient could not be checked, and 424 with retry: true when pricing took longer than 45 seconds.

POST /bridge/solana-tx

{
  "slug": "<launch slug>",
  "to": "base",
  "amount": "1000000000000",
  "sender": "<Solana wallet>",
  "recipient": "0x<EVM address>"
}

Builds the unsigned transaction that sends the token from Solana to an EVM chain, for the sender to sign. For a token with the price-gap fee, minCredited is required: the least the destination may credit after it, in Solana base units (the bridge quote’s gap.minCreditedSource); without it the request is refused (400). after and afterValidUntil are given only on a second call after a setup step. The answer carries the request’s from, to, amount and symbol and one of three stages:

On Solana a factory v3 arrival is delivered with 650,000 compute units. A charged v3 receive there runs only through LayerZero's executor (its own execute flow) or Pangea's delivery keys (R1′), so nobody can land it at a price of their choosing; an escaped, refunded or unpooled arrival stays open to anyone.

Every stage carries blockhash and lastValidBlockHeight: sign within about a minute. While a setup step is still settling the answer is 202 with { pending: true, stage: "waiting" }; ask again. Errors: 400 for a bad field or a signature that is not this transfer’s setup, 404 for an unknown launch, 409 when the setup ran out or failed, the route is unusable or the wallet is short of SOL, 424 when the build takes longer than usual, with retry: true, and 424 after 50 seconds.

POST /bridge/solana-fast-tx

The fast lane out of Solana: one unsigned transaction holding Pangea’s fast-bridge order and the OFT send that carries it. Body: { slug, to, recipient, amount, relayerFee, minReceived, sender }, with relayerFee and minReceived from the quote’s solanaFast. The answer is { stage: "send", transaction, orderId, amount, arriving, fastFee, relayerFee, nativeFee, nativeFeeCap, blockhash, lastValidBlockHeight }. Errors: 409 when the fast lane is off for this launch or route, 422 when the order could not be built, nothing having been sent.

POST /bridge/route-open

The second step of the first transfer from an EVM chain into a Solana route: once the quote’s routePayment has been sent, this hands its transaction to Pangea’s delivery service, which checks the payment on chain and opens the route, or refunds it. Body: { slug, from, txHash, sender }, from being the EVM chain the payment was made on. With Accept: text/event-stream it streams { state, reason?, refundTx? } as the route is opened; otherwise it answers once. state is one of verifying, paid, opening, open, refunded, refund-owed, review and refused. Send the transfer once it is open. Errors: 404 for a launch not on Solana, 424 when routes cannot be opened from this deployment.

POST /bridge/arrival

Body: { txHash }, the send’s transaction hash or Solana signature. A stream of { state, route, guid, dstTx?, by? }, state being in-flight and then delivered, with the delivery’s transaction in dstTx. It is fed by Pangea’s delivery service, which remembers a transfer for 30 minutes. Errors: 400 for a malformed hash, 424 when the deployment does not serve arrivals; LayerZero Scan answers the same question.

POST /bridge/refund

Body: { chain, orderId }, the destination chain and the fast order’s id. The answer is { held: false } or { held: true, guid, amount, srcEid, call }, where call is the refund(guid) transaction, { to, data, value, chainId }, with LayerZero’s fee for the trip back as its value. It looks back 5,000 blocks. Errors: 400 for a malformed id or a chain without a fast bridge.

POST /bridge/orders

Body: { from, hash }, the chain a fast order was posted on and its transaction. The board reads the order from the receipt and remembers whose price it was sent at, which is how a relayer that does not fill is benched. The answer is 202 with { recorded: false, pending: true } before the receipt exists, then { recorded, relayer, why?, orderId, to, srcBridge }. Only orders priced from this deployment’s board are recorded; why says why not.

POST /chain/tx

Body: { chain, hash }. One event when the transaction is in a block: { state: "mined", success, block } on an EVM chain, { state: "mined", success } on Solana, or { state: "unseen" } if it never appears, after up to 10 minutes on an EVM chain and 5 on Solana.

Trading: POST /trade/quote and POST /trade/solana-tx

These are the trade card’s own and may change; read a quote for a price, and build trades from the pools directly where you can. /trade/quote takes { slug, side, chain, amount, user?, solanaUser?, slippageBps?, mode?, intent?, quoteAsset? }: side is buy or sell; chain is the chain the wallet trades on, always a chain name (auto is refused, and a fromChain other than chain is refused too); amount is the pay asset’s base units for a buy, the token’s for a sell. slippageBps is the slippage, how far below the quote the trade may fill: a whole number of basis points from 1 to 9900 (0.01% to 99%), 100 unless given. mode is "direct" (the default: the coin’s own pool on that chain) or "cheapest" (also price the other chains’ pools and offer the route when it is better after every fee); intent is "preview" (a price, nothing to sign) or "execute"; quoteAsset: "stock" pays or receives the stock token itself on a stock-paired EVM chain. A direct trade goes through the coin’s own pool (details.router: "pool"), with Jupiter as a fallback on Solana. The answer is { mode, preview?, chain, fromChain, crossChain, cheapestNote, unroutable, details, steps, cheapest? }; with mode: "cheapest", cheapest is { offered, reason, plan, steps, comparison: { directOut, routeOut, gainBps, cost }, tried } and, when it is offered, directDetails is the direct trade beside it. Cheapest mode has its own brakes (20 a minute per wallet, 2 at once per caller); past them it answers as a direct quote with the reason in cheapestNote. Errors: 400, 404, 422 with the reason when no route was found, and 424 when a chain or the router could not be reached or took too long (with retry: true where trying again can help). Never a 5xx: a proxy in front may replace a 5xx body.

/trade/solana-tx takes { instructions, addressLookupTableAddresses?, payer }, a swap step’s Solana instructions as the quote gives them, at most 24 instructions and 8 lookup tables, and answers { transaction, blockhash, lastValidBlockHeight }: an unsigned versioned transaction. It does not inspect what the instructions do, so read them, or let your wallet simulate them, before you sign.

A program can launch a token the way the launch page does: quote it, get the transaction that pays for it, hand the paid launch over, and follow it until every chain of the launch is live. The endpoints are under https://www.pangea.trade/api/v1/launch. Prepare, submit, status and the SOL payment are the launch page’s own steps, handed to the same code, with the same checks.

• No API key needed, and no rate limit for normal use. Only a flood ceiling far above any real integration applies, per IP address. A partner key takes you out of it: see API keys and limits below.
• Programs, and the Pangea site. A program sends no Origin header and is served. A browser on another website always sends one, and is refused with 403, so another site cannot spend the reads a quote makes on five chains through its visitors. The status read is a read and takes any origin. The event stream holds a connection open, so it takes the same rule as the rest and needs Accept: text/event-stream (406 without it); a page's no-cors or cross-site request is refused with 403, and each caller may hold one stream per launch.
• The platform signs the snapshot, never the API. Every chain launches with one price snapshot, signed by Pangea’s worker after it has found your payment on chain. No endpoint here signs one or sends anything for you.
• Amounts are base units as decimal strings: wei on an EVM chain, lamports on Solana, and nine decimals for the token.

The flow

• POST /v1/launch/prepare quotes the launch and returns a ticket: the launch’s every parameter and its fee, signed by Pangea. Every later step takes it.
• POST /v1/launch/authorization only when another wallet sends your own chain’s launch: the permission your creator wallet signs for it. Launch with your own wallet →
• POST /v1/launch/pay returns the one transaction that pays the fee. You send it from the payer’s wallet; Pangea sends nothing for you. Pay within the quote’s 10 minutes.
• POST /v1/launch/submit hands the launch over once the payment is mined, within 24 hours of the quote, with the payer’s signature (payerAuth) and any creator signatures the quote asked for. Pangea checks the payment on chain and queues the launch.
• GET /v1/launch/status and GET /v1/launch/events follow it: the price snapshot signed, then each chain as it goes live. Paid on an EVM chain, that chain goes first, then Solana, then the other EVM chains; paid in SOL, Solana goes first.

Every endpoint above also counts toward the flood ceiling: 1200 requests a minute from one IP address, all /v1 endpoints together.

API keys and limits

There is no rate limit for normal use and no key is needed. Three ceilings stop floods, per IP address and counted together on every server: 1200 requests a minute across every /v1 endpoint, and 120 quotes in ten minutes from POST /v1/launch/prepare, which reads five chains every time, and 300 in ten minutes of authorization, pay, submit and kit together, which read the chains on every call. Each event stream holds a connection open, so at most 3 are open at once per address.

An integration that needs more, or wants a guarantee it will never meet a ceiling, can ask for a partner key: write to us through the support chat on the site with your project’s name and the IP addresses you call from (optional). Send it as the X-Pangea-Key header on every request. With a key there is no ceiling, at least 100 event streams may be open at once, and it can be limited to your addresses. Keep it on your server: never put it in a page or an app.

Every answer carries the three X-RateLimit headers. A key that is not valid or has been revoked is refused with 401 (never served as if it were absent), and a key used from an address it is not allowed from with 403.

const API = "https://www.pangea.trade/api/v1/launch";

const post = (path, body) =>
  fetch(API + path, { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify(body) })
    .then(async (r) => ({ status: r.status, body: await r.json() }));
const get = (path) => fetch(API + path).then(async (r) => ({ status: r.status, body: await r.json() }));

// 1. The quote, and the ticket: pay, submit and the launch kit all take it.
const prepared = await post("/prepare", {
  name: "Example",
  symbol: "EXMPL",
  metadataURI: "ipfs://<the CID of your metadata document>",
  feeBps: 100,
  creatorEvm: "0x<your EVM creator wallet>",
  creatorSol: "<your Solana creator wallet>",
  payChain: "base",
});
if (prepared.status !== 200) throw new Error(prepared.body.error);
const { ticket, launchId, payerProof } = prepared.body;
console.log(`fee: ${prepared.body.fee.payment.send} wei, about $${prepared.body.fee.feeUsd}`);

// 2. The transaction that pays it: send it from pay.body.from, the payer, and wait for it to be mined.
const pay = await post("/pay", { ticket });
if (pay.status !== 200) throw new Error(pay.body.error);
const { chainId, to, data, value } = pay.body.tx;
console.log({ chainId, to, data, value, sendFrom: pay.body.from, before: pay.body.validUntil });
const payer = pay.body.from;

// The payer signs that it pays for this ticket: personal_sign of payerProof.message by payerProof.signer.
const payerAuth = "0x<that signature>";

// 3. Once it is mined, hand the launch over. A 402 means the payment is not found yet: ask again.
// If prepared.body.creatorProofs lists a creator wallet, add its signature as creatorEvmAuth / creatorSolAuth.
const submitted = await post("/submit", { ticket, payer, payerAuth });
if (submitted.status !== 200) throw new Error(submitted.body.error);

// 4. Where it stands: pending, running, done or failed, and each chain as it goes live.
const status = await get(`/status?launchId=${launchId}`);
console.log(status.body.state, Object.keys(status.body.result?.live ?? {}));

Errors

An error is { "error": "..." } with a status, and the message says what to do. A status read or an event stream for an id the queue does not have is 404 with { "launchId": "0x...", "state": "unknown" } instead.

A body that is too large is 413, one sent compressed 415, and one that does not arrive in time 408.

POST /v1/launch/prepare

{
  "name": "Example",
  "symbol": "EXMPL",
  "metadataURI": "ipfs://<the CID of your metadata document>",
  "feeBps": 100,
  "creatorEvm": "0x<your EVM creator wallet>",
  "creatorSol": "<your Solana creator wallet>",
  "payChain": "base"
}

The answer carries launchId, ticket, creator, fee (feeUsd, costUsd, ttlSeconds and payment: chain, asset, wei, devBuy, send, what the wallet sends in all, collector and, on an EVM chain, tx), prediction.perChain, each EVM chain’s token address, every one ending in 6ea, selfLaunch when asked for, and remaining, the steps left in plain sentences.

It also carries factoryGen, 2 for a factory v2 launch, degen, and with it v2: v2.degen, the supply (circulating, bridge reserve and total), what each pool holds at the open, the fee receivers, and legOrder, the order the chains are sent in and by whom. payer is the wallet whose payment counts. payerProof is { kind, signer, message }: the text the payer signs, personal_sign on an EVM chain or signMessage on Solana, posted to submit as payerAuth. creatorProofs lists the same for each creator wallet that is not the payer’s signing wallet, each { side, kind, signer, message }, posted as creatorEvmAuth and creatorSolAuth; it is empty when the payer is your creator wallet on every side that needs one.

POST /v1/launch/authorization

Body: { ticket }, for a launch quoted with selfLaunch and a selfLaunchFrom other than the creator wallet. The answer is { launchId, chain, signer, launcher, typedData, digest, next }: typedData is what signer, your creator wallet, signs with eth_signTypedData_v4, and digest the hash the factory recovers it from, for a signer that signs hashes. It is the same typed data prepare returned as selfLaunch.authorization. Post the signature to submit as creatorAuth. 409 for a launch that needs no permission.

POST /v1/launch/pay

Body: { ticket, payer }. Every amount comes from the ticket, never from the request. On an EVM chain, payer is not needed and the answer is { launchId, chain, tx, fee, devBuy, from, validUntil, next }: tx is { chainId, to, data, value }, a call of pay(launchId), or payWithDevBuy(launchId, devBuy), on that chain’s LaunchFeeCollector, with the fee and the dev buy as its value. Send it from from, the quote’s payer: only that wallet’s own payment counts toward the launch. validUntil is the end of the quote, in unix seconds. A dev buy on a chain paired with an asset is refused with 409: send the quote’s own fee.payment.tx instead.

Paid in SOL, payer is the paying wallet in base58, and the answer is an unsigned versioned transaction naming it as the only signer: { launchId, programId, lamports, feeLamports, devBuyLamports, payer, transaction, feeAccount, blockhash, lastValidBlockHeight, rentLamports, quoteAccountRentLamports }, transaction in base64. The payment’s own account needs rentLamports on top. Sign and send it within about a minute: it is good for as long as its blockhash. The paying wallet must be the quote’s payer.

import { Connection, Keypair, VersionedTransaction } from "@solana/web3.js";

const API = "https://www.pangea.trade/api/v1/launch";
const ticket = process.env.LAUNCH_TICKET; // from prepare, with payChain solana
const payer = Keypair.fromSecretKey(Uint8Array.from(JSON.parse(process.env.SOLANA_KEYPAIR)));
const connection = new Connection(process.env.SOLANA_RPC, "confirmed");
const post = (path, body) =>
  fetch(API + path, { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify(body) })
    .then(async (r) => ({ status: r.status, body: await r.json() }));

// The unsigned payment, naming your wallet as its only signer.
const pay = await post("/pay", { ticket, payer: payer.publicKey.toBase58() });
if (pay.status !== 200) throw new Error(pay.body.error);
const tx = VersionedTransaction.deserialize(Buffer.from(pay.body.transaction, "base64"));
console.log(`paying ${pay.body.lamports} lamports, and ${pay.body.rentLamports} of rent`);

tx.sign([payer]);
const signature = await connection.sendRawTransaction(tx.serialize());
const confirmed = await connection.confirmTransaction(
  { signature, blockhash: pay.body.blockhash, lastValidBlockHeight: pay.body.lastValidBlockHeight },
  "confirmed",
);
if (confirmed.value.err) throw new Error("the payment failed");

// The payer signs prepare's payerProof.message (signMessage, ed25519): base58 or 0x-hex.
const payerAuth = process.env.PAYER_AUTH;

// A fee paid in SOL is found by who paid it: name the payer.
const submitted = await post("/submit", { ticket, payer: payer.publicKey.toBase58(), payerAuth });
if (submitted.status !== 200) throw new Error(submitted.body.error);
console.log(submitted.body.state);

POST /v1/launch/submit

Body: { ticket, payer, payerAuth, creatorEvmAuth, creatorSolAuth, creatorAuth }, once the payment is mined. payer is required for a fee paid in SOL, because that payment is found by who paid it; on an EVM chain it is optional and only recorded. payerAuth is required: the payer’s signature over prepare’s payerProof.message. creatorEvmAuth and creatorSolAuth are each listed creator wallet’s signature over its message in prepare’s creatorProofs. Without them nothing is queued, and submit answers with the messages to sign. creatorAuth is needed when another wallet sends your own chain’s launch. Submit never refuses a paid launch over it: without one that recovers to your creator wallet for that wallet, the launch is queued all the same, the answer carries selfLaunch: "dropped" and a warning, and Pangea sends that chain like the others. So check it first: POST /v1/launch/authorization with { ticket, creatorAuth } answers check: { ok }. The fee is read on chain, never taken from the request. The answer is { launchId, state, queued: true, enqueuedAt, creator, paid, next, selfLaunch?, warning? } with state: "pending". Submitting again queues nothing and answers { launchId, state, queued: false, message, result }.

GET /v1/launch/status

The answer is { launchId, state, message, lastError, attempts, enqueuedAt, result, selfChain, degen, tokenomics }, each field only when it is set. degen is whether the launch is in degen mode, and tokenomics whether it has tokenomics; the coin’s config is on /coin/[id] once it is live. state is pending, running, done or failed. In result: signed.at when the price snapshot is signed, live, each chain as it goes live, { token, at, tx }, and selfLaunch, your own launch call, for a launch that has one. selfChain names the chain you send yourself. signed.at and each chain’s at are ISO 8601 times; the call’s takeoverAt is in unix seconds.

GET /v1/launch/events

The status as it changes, as server-sent events: each an event: <name> line and a data: <json> line. Everything so far is sent the moment the stream opens, so a late listener misses nothing. A comment line, starting with a colon, comes every 15 seconds to keep the connection open. The stream closes after end, after 30 minutes, or when you disconnect; open it again to keep following. An id the queue does not have is 404: open the stream after submit has queued the launch.

At most 3 open streams per caller, and a few hundred in all on each server; past that it is 429 with Retry-After, and polling the status read does the same job. A page on the Pangea site can open it with an EventSource; a program reads it with a streaming fetch.

const API = "https://www.pangea.trade/api/v1/launch";

// One frame: its event name and its JSON. Comment lines, such as the keep-alive, are skipped.
function parseFrame(frame) {
  let event = "message";
  const data = [];
  for (const line of frame.split("\n")) {
    if (line.startsWith(":")) continue;
    if (line.startsWith("event: ")) event = line.slice(7);
    else if (line.startsWith("data: ")) data.push(line.slice(6));
  }
  return data.length ? { event, data: JSON.parse(data.join("\n")) } : null;
}

async function* launchEvents(launchId) {
  const res = await fetch(`${API}/events?launchId=${launchId}`, { headers: { Accept: "text/event-stream" } });
  if (!res.ok) throw new Error(`the stream answered ${res.status}`);
  const reader = res.body.getReader();
  const decoder = new TextDecoder();
  let buffer = "";
  for (;;) {
    const { value, done } = await reader.read();
    if (done) return;
    buffer += decoder.decode(value, { stream: true });
    let end;
    while ((end = buffer.indexOf("\n\n")) >= 0) {
      const frame = parseFrame(buffer.slice(0, end));
      buffer = buffer.slice(end + 2);
      if (frame) yield frame;
    }
  }
}

for await (const { event, data } of launchEvents("0x<your launch id>")) {
  if (event === "pool-live") console.log(`${data.chain} is open: token ${data.token}`);
  if (event === "self-launch") console.log(`your launch call for ${data.chain} is out`, data.call);
  if (event === "self-launched") console.log(`${data.chain} was sent by the ${data.by}`);
  if (event === "end") break;
}

POST /v1/launch/kit

Body: { ticket, buys, deadline }, once the launch is submitted; before, it is 409. Each EVM chain’s token address and pool, ready calldata for your own buys, your launch call if you send one, and Solana’s pool once Solana has launched. The fields are under Launch-time buys →

POST /v1/launch/solana-self-call

For a launch prepared with selfSolana. Body: { launchId, ticket }, the ticket the launch is queued under. Answers { launchId, call, nonce, blockhash, lastValidBlockHeight }: call is the template of your launch_self transaction (format pangea-solana-self-call/1), every byte that does not depend on your seed; nonce is the nonce your Solana wallet signs the seed message for again. 409 until it is out (once the price snapshot is signed and, paid on an EVM chain, that chain has launched), and once Solana has landed; 202 with retryAfterS while a fresh call is signed. With { launchId, signature } instead, you tell it the transaction your launch went out under: { kept }, or 202 while it has not landed.

POST /v1/launch/solana-cosigned

Not available. It always answers 409, with enabled: false and the reason: a Solana launch transaction signed by Pangea’s launcher, that you could submit yourself through Jito with your own buys after it, needs a change to the splitter program that is still in progress.

A launch is on its chains: all five, Solana, Ethereum, Base, BSC and Robinhood Chain, unless it was launched on selected chains. Paid on an EVM chain, that chain launches first, where the fee is checked; then Solana, from Pangea’s launcher, whose addresses derive from a secret seed that stays unpublished until it lands, or from your own Solana wallet if you choose that (below); then the other EVM chains. Paid in SOL, Solana launches first and the EVM chains follow, the EVM chains always sent by Pangea.

With selfLaunch: true, you send one EVM chain’s launch yourself: the chain you pay on, and only that one. Pangea’s launchers send the others, as for every launch.

Why nobody can launch your chain before you

Each EVM factory has two ways in. launch(LaunchParams p, LaunchTerms terms, Snapshot snap, bytes signature) takes three senders only: your creator wallet (msg.sender == p.creator), the factory’s admin, and a launcher the admin has listed. Anyone else reverts with NotLauncher. A creator may send only the pay chain’s launch; any other chain reverts with NotThePayChain.

launchAuthorized(LaunchParams p, LaunchTerms terms, Snapshot snap, bytes signature, bytes creatorAuth) takes any sender that holds your creator wallet’s permission naming that sender. The permission is EIP-712 typed data, LaunchAuth(bytes32 launchId, address launcher), in the domain { name: "PangeaLaunchAuth", version: "2" }, with no chain id and no contract. The factory recovers it against the sender, so a permission for one wallet is useless to anyone else who sees it; a signature that recovers to anyone but your creator wallet reverts with BadCreatorAuth.

So nobody else can send your chain’s launch, and it cannot be front-run. The price snapshot it carries exists only after your fee is paid: Pangea’s worker signs it after checking your payment on chain, and the API never signs one.

The fee

The same as for any launch, quoted by prepare and paid once. With selfLaunch, the pay chain must be an EVM chain, and it is the chain you launch. That chain’s launch reverts with LaunchUnpaid unless the quote’s payer has paid the fee for it, and your launch transaction releases the fee to the platform in the same transaction (LaunchFeeCollector.onLaunch). Sending your chain yourself does not change the fee.

Your time to send it

• Your call is handed out once the price snapshot is signed. Your chain goes first: Pangea sends Solana and the other EVM chains only once it has landed.
• The option is on only where the deployment turns it on; elsewhere prepare refuses selfLaunch. Your time is counted from when your call is handed out: 90 seconds unless the deployment sets SELF_LAUNCH_GRACE_S to another, held between 90 and 120. It always ends at least 300 seconds before the snapshot’s deadline, and if the launch is retried it never ends later than the first time it was given. Its end is takeoverAt in your call, in unix seconds.
• If your launch is not there by then, Pangea’s launcher sends it, with the same snapshot and the same parameters. Whichever of the two lands second reverts with AlreadyLaunched, and its sender loses only that transaction’s gas.
• If your chain’s launch cannot land, nothing else is sent: no other chain launches before the pay chain.
• The launch page stops offering the send 30 seconds before the takeover, since a transaction sent later may land after Pangea’s.

Step by step

• POST /v1/launch/prepare with selfLaunch: true, payChain set to your chain, creatorEvm set to your creator wallet and, if another wallet will send the launch, selfLaunchFrom set to it. The answer’s selfLaunch is { chain, chainId, from, creator, factory, token, gasLimit, value, graceSeconds, authorization }.
• If authorization is set, sign it with the creator wallet (eth_signTypedData_v4). You can also get it from POST /v1/launch/authorization with { ticket }, which answers { launchId, chain, signer, launcher, typedData, digest }. Sign before you pay. The typed data names its own domain type (EIP712Domain: [{ name: "name", type: "string" }, { name: "version", type: "string" }] in its types), so pass it whole: through eth_signTypedData_v4 or viem’s signTypedData, a wallet hashes the domain the contract checks.
• POST /v1/launch/pay with { ticket } answers { tx: { chainId, to, data, value }, from, validUntil }. Send tx on your chain; with a dev buy, from from.
• POST /v1/launch/submit with { ticket, payer, payerAuth, creatorAuth } once it is mined, with the payer’s signature as for any launch. creatorAuth is the permission, required when the launching wallet is not the creator wallet.
• Watch GET /v1/launch/events?launchId= or poll GET /v1/launch/status?launchId=. Once the price snapshot is signed, the status’s result.selfLaunch and the self-launch event carry your call: { chain, chainId, launchId, from, to, data, value, gas, token, deadline, takeoverAt }, where to is the factory and data the encoded launch, or launchAuthorized with your permission, carrying the signed snapshot.
• Send exactly that transaction, from from, before takeoverAt. Then result.selfLaunch.by says creator or platform; the status’s top-level selfChain names your chain throughout.

import { privateKeyToAccount } from "viem/accounts";

const API = "https://www.pangea.trade/api/v1/launch";
const ticket = process.env.LAUNCH_TICKET; // from prepare, with selfLaunch and selfLaunchFrom
// The CREATOR WALLET signs: the creatorEvm you named. It lets the launching wallet send this launch.
const creatorWallet = privateKeyToAccount(process.env.CREATOR_WALLET_KEY);
const post = (path, body) =>
  fetch(API + path, { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify(body) })
    .then(async (r) => ({ status: r.status, body: await r.json() }));

const auth = await post("/authorization", { ticket });
if (auth.status !== 200) throw new Error(auth.body.error);
const { signer, launcher, typedData } = auth.body;
if (signer.toLowerCase() !== creatorWallet.address.toLowerCase()) throw new Error(`sign with ${signer}`);

// One signature for every EVM chain: the domain has no chain id and no contract.
const creatorAuth = await creatorWallet.signTypedData(typedData);

// Through eth_signTypedData_v4 yourself, pass it whole: it already names its domain's type (EIP712Domain).
const forWallet = typedData;
console.log("eth_signTypedData_v4 params:", [signer, JSON.stringify(forWallet)]);
console.log(`${launcher} may now launch ${auth.body.launchId}, and nobody else may use this`);

// Pay as usual, then hand it over with the payer's signature and the permission.
const submitted = await post("/submit", { ticket, payer: "0x<the wallet that paid>", payerAuth: "0x<its signature>", creatorAuth });
if (submitted.status !== 200) throw new Error(submitted.body.error);

import { createPublicClient, createWalletClient, http } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { base, bsc, mainnet, robinhood } from "viem/chains";

const API = "https://www.pangea.trade/api/v1/launch";
const CHAINS = { 1: mainnet, 8453: base, 56: bsc, 4663: robinhood };
const launchId = "0x<your launch id>";

// The wallet that launches: your creator wallet, or the selfLaunchFrom you named.
const account = privateKeyToAccount(process.env.LAUNCHER_KEY);

const status = await fetch(`${API}/status?launchId=${launchId}`).then((r) => r.json());
const call = status.result?.selfLaunch;
if (!call?.data) throw new Error("not out yet: it is handed out once the price snapshot is signed");
if (call.by) throw new Error(`already sent, by the ${call.by}`);
if (Date.now() / 1000 >= call.takeoverAt) throw new Error("too late: Pangea is sending it, with the same snapshot");
if (call.from.toLowerCase() !== account.address.toLowerCase()) throw new Error(`send it from ${call.from}`);

const chain = CHAINS[call.chainId];
const transport = http(process.env.RPC_URL);
const { maxFeePerGas, maxPriorityFeePerGas } = await createPublicClient({ chain, transport }).estimateFeesPerGas();
// What the wallet must hold: the whole gas limit at the max fee, and the value. Unused gas is refunded.
const mustHold = BigInt(call.gas) * maxFeePerGas + BigInt(call.value);
console.log(`hold at least ${mustHold} wei on ${chain.name}`);

const wallet = createWalletClient({ account, chain, transport });
const hash = await wallet.sendTransaction({
  to: call.to, // the factory
  data: call.data, // launch, or launchAuthorized with the permission, and the signed snapshot
  value: BigInt(call.value), // 1,000,000 wei: the opening buy
  gas: BigInt(call.gas),
  maxFeePerGas,
  maxPriorityFeePerGas,
});
console.log(`sent ${hash}; the event stream says self-launched when it lands`);

The examples sign with a private key to stay short. Any wallet that can sign typed data, and send a transaction with this data, value and gas limit, will do.

Gas

Your call comes with a gas limit of 11,797,500: a launch’s measured 8,250,000 gas, with 10% and then 30% of room. A launch uses up to about 8.25 million gas and the rest is refunded, but to send it your wallet has to hold the whole gas limit at its max fee per gas, plus the value.

The value is 1,000,000 wei: the opening buy, the pool’s first trade, made in the launch only when the launch has no dev buy. Send it as given: zero would skip the opening buy (and the token page could not tell the launch transaction's buys apart), and any other value reverts.

• What your wallet must hold. At least 11,797,500 × max fee per gas + 1,000,000 wei, in ETH on Ethereum, Base and Robinhood Chain, in BNB on BSC. On Base, add its L1 data fee, which is charged on top of gas × price: a few cents is ample. The figure above is a floor: the call's gas is the node's estimate from your wallet with a 30% margin, never less than it, so fund from call.gas once the call is out.
• What it costs you. About 8,250,000 × the gas price paid, plus the value. At 1 gwei that is 0.00825 of the chain’s coin. Read the chain’s gas price before you send.

Solana: launch it from your own Solana wallet

You can also send Solana’s launch yourself, from your Solana creator wallet, on any pay chain. Its Solana addresses then come from a seed only your wallet can make, so Pangea never holds it and nobody else can send Solana’s launch. It is a separate choice from selfLaunch: you can tick either, or both when you pay on an EVM chain.

• Choosing it. On the launch page, with Solana among the launch’s chains, turn on Launch Solana from my own wallet. Your Solana wallet signs one message, the seed message; nothing is sent. Your browser makes the seed from that signature, finds a mint address ending in 6ea, and sends prepare only what the quote needs (selfSolana); the seed never leaves your browser.
• The order. The pay chain goes first, because your fee is checked there. Paid on an EVM chain, that chain launches (from your own EVM wallet too, with selfLaunch); then Solana, from your Solana wallet; then Pangea’s launchers send the other EVM chains. Paid in SOL, Solana goes first from your wallet, and Pangea sends every EVM chain once it has landed.
• Sending it. Once the price snapshot is signed, the launch page shows Your launch on Solana with a Send your Solana launch button. Connect the Solana creator wallet the quote named; no other wallet can send it. The wallet signs twice: the seed message again, so the page can rebuild the seed, and then one transaction, launch_self, which it sends. It is a v0 transaction through a shared lookup table, so your wallet must support those.
• Your time. The price the launch carries is good only for a while, counted down on the panel. With less than 60 seconds left the button stops offering the send and a fresh price is signed for you, so keep the page open and send it when the button is back. You have 24 hours from when your first call is handed out.
• If you don’t send it. Unlike your EVM chain, there is no takeover: Pangea’s launcher cannot send Solana’s launch for you, because it does not have the seed. Until you send it, nothing after Solana launches. After 24 hours no fresh price is signed and the launch stops there: paid in SOL, nothing has launched; paid on an EVM chain, that chain is already live and its fee settled, and the other chains wait for Pangea to look at it. Contact support.
• What it costs you. Your Solana wallet pays the launch’s rent, about 0.028 SOL (Pangea’s fee no longer includes it), and the transaction’s fee, priority fee included. Hold a little more SOL than that before you send.
• Its fees. A Solana launch you send yourself pays its trading fees to your Solana creator wallet, or burns them: another Solana fee receiver is refused. Its four Solana bridge routes are opened by their first bridgers, so it cannot be combined with paying for them to be opened at launch.

From a script: prepare with selfSolana, pay and submit as usual, then ask POST /v1/launch/solana-self-call with { launchId, ticket } until it hands over your call, build launch_self from it with your seed, and sign and send it from your Solana creator wallet. The helper the example imports, pangea-solana-self-launch.mjs, is the launch page’s own code for it in one file, safe in a browser and in Node. Download it beside your script and install what it imports: npm i @solana/web3.js viem tweetnacl.

import { Connection, Keypair } from "@solana/web3.js";
import nacl from "tweetnacl";
// Pangea's script helper, one file: download https://www.pangea.trade/sdk/pangea-solana-self-launch.mjs beside this script.
// It imports these, so install them: npm i @solana/web3.js viem tweetnacl
import { selfSolanaPrepareFields, seedMessageBytes, selfSolanaLaunchTx } from "./pangea-solana-self-launch.mjs";

const SITE = "https://www.pangea.trade";
const API = SITE + "/api/v1/launch";
// Your Solana creator wallet: it signs the seed message, and it sends and pays for Solana's launch.
const creator = Keypair.fromSecretKey(Uint8Array.from(JSON.parse(process.env.SOLANA_KEYPAIR)));
const sign = (message) => nacl.sign.detached(message, creator.secretKey);
const connection = new Connection(process.env.SOLANA_RPC, "confirmed");
const post = (path, body) =>
  fetch(API + path, { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify(body) })
    .then(async (r) => ({ status: r.status, body: await r.json() }));
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

// 0. Offered here? And the program ids your launch's Solana addresses derive under.
const gen = await fetch(SITE + "/api/launch/factory-gen").then((r) => r.json());
if (!gen.selfSolana) throw new Error("this deployment does not offer the Solana self-launch");

// 1. selfSolana: sign the seed message for a fresh nonce and grind a mint ending in 6ea (a few seconds).
// Only the launch id, the OFT store and the mint go to prepare: the seed never leaves this script.
const selfSolana = await selfSolanaPrepareFields({ sign, programs: gen.solanaPrograms });
const prepared = await post("/prepare", {
  name: "Example",
  symbol: "EXMPL",
  metadataURI: "ipfs://<the CID of your metadata document>",
  feeBps: 100,
  creatorEvm: "0x<your EVM creator wallet>",
  creatorSol: creator.publicKey.toBase58(),
  payChain: "base",
  selfSolana,
});
if (prepared.status !== 200) throw new Error(prepared.body.error);
const { ticket, launchId } = prepared.body;

// 2. Pay and submit, as in the whole flow above (or in SOL, with payChain solana).

// 3. Wait for Solana's turn: the call is out once the price snapshot is signed (the signed event) and,
// paid on an EVM chain, that chain has launched. 409 "not ready to send yet" means wait; 202 means a fresh
// call is being signed. Ask at most every 15 seconds: the call has its own limit per address.
let answer;
for (;;) {
  const r = await post("/solana-self-call", { launchId, ticket });
  if (r.status === 200) { answer = r.body; break; }
  if (r.status === 202) { await sleep((r.body.retryAfterS ?? 5) * 1000); continue; }
  if (r.status === 409 && /not ready/.test(r.body.error)) { await sleep(15_000); continue; }
  throw new Error(r.body.error);
}

// 4. Sign the seed message again (for answer.nonce, the same nonce), build launch_self, sign it and send it.
// Send it well before answer.call.deadline: with less than a minute left, ask again for a fresh call.
const { transaction, size } = await selfSolanaLaunchTx({ signature: sign(seedMessageBytes(answer.nonce)), answer, mint: selfSolana.mint });
transaction.sign([creator]);
const signature = await connection.sendRawTransaction(transaction.serialize());
console.log(`sent ${signature}, ${size} bytes`);
const confirmed = await connection.confirmTransaction(
  { signature, blockhash: answer.blockhash, lastValidBlockHeight: answer.lastValidBlockHeight },
  "confirmed",
);
if (confirmed.value.err) throw new Error("the launch failed: ask for a fresh call and send again");

// 5. Optional: tell Pangea which transaction it was, so the launch moves on sooner.
await post("/solana-self-call", { launchId, signature });

// 6. Follow the event stream: pool-live for solana, then the other chains as Pangea sends them.

Launch-time buys

Pangea sends nobody’s buys. The launch kit gives you what you need to make your own, from your own wallets, and leaves the sending to you.

POST /v1/launch/kit with { ticket, buys, deadline } answers once the launch is paid and submitted; before, it is 409. buys is optional: at most 20 of { chain, amountIn, minOut }, EVM chains only, amountIn in the native coin’s wei and minOut in the token’s base units, both positive whole numbers as strings. deadline is optional too: unix seconds between 60 seconds and 1 hour from now, 1 hour when left out.

Buy calldata is built for pools paired with the native coin only; a pool paired with an asset is refused with 409. minOut is required: the pool does not exist before the launch, so there is no quote to take it from, and a buy that would get less reverts. Work it out from the opening price the quote gives, less the trading fee, your own buy’s price impact and the slippage you accept.

import { createPublicClient, createWalletClient, http } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { base, bsc, mainnet, robinhood } from "viem/chains";

const API = "https://www.pangea.trade/api/v1/launch";
const CHAINS = { 1: mainnet, 8453: base, 56: bsc, 4663: robinhood };

// The ticket prepare gave you, and a wallet to buy from: any wallet, and it receives the tokens.
const ticket = process.env.LAUNCH_TICKET;
const buyer = privateKeyToAccount(process.env.BUYER_KEY);

const res = await fetch(`${API}/kit`, {
  method: "POST",
  headers: { "content-type": "application/json" },
  // 0.01 ETH on Base. At the opening price ($3,000 for a chain's 1B tokens) and ETH at $3,000 that is
  // about 10,000,000 tokens before the pool's fee and the price moving; ask for at least 9,000,000 (9 decimals).
  // Work minOut out from your own prices: it is the floor below which the buy reverts.
  body: JSON.stringify({ ticket, buys: [{ chain: "base", amountIn: "10000000000000000", minOut: "9000000000000000" }] }),
});
const kit = await res.json();
if (!res.ok) throw new Error(kit.error);

const [buy] = kit.buys;
const pool = kit.evm.find((c) => c.chain === buy.chain);
console.log(`pool ${pool.poolId}, token ${pool.token}, buy valid until ${kit.validUntil}`);
// A buy works only once its pool is open: wait for pool-live on the event stream, or ask again.
if (!pool.live) throw new Error(`the ${buy.chain} pool is not open yet`);

const wallet = createWalletClient({ account: buyer, chain: CHAINS[buy.chainId], transport: http(process.env.RPC_URL) });
const hash = await wallet.sendTransaction({ to: buy.to, data: buy.data, value: BigInt(buy.value) });
console.log("sent", hash);

Making your buys land with your launch

• Ethereum. Sign your launch transaction and each buy, each buy from its own wallet with its own nonce and an explicit gas limit, since an estimate fails while the pool does not exist. Send them to a private relay such as Flashbots in one submission for one target block, your launch first. Nobody sees them before that block.
• BSC. The same, through a private submission to 48 Club or bloXroute: all of them for one block, your launch first.
• Base and Robinhood Chain. There is no public private relay. Send your launch, watch the event stream for pool-live on that chain, then send your buys. Others can buy in the same block.
• Solana. Pangea’s launcher sends Solana’s launch. Once it has landed, the kit gives its pool and mint, and you swap on Meteora like anyone. A launcher-signed Solana launch that you could submit through Jito with your buys after it is not available: POST /v1/launch/solana-cosigned answers 409.

Risks

• Without a private relay, a buy can be front-run in the same block. minOut is what protects you: below it, the buy reverts.
• A signed snapshot expires: its deadline is never more than 1 hour away, and normally 15 minutes. After it your launch call stops working, whoever sends it.
• If your launch transaction lands after Pangea’s takeover, it reverts and you lose only its gas. The launch is made either way, with the same price and settings.
• A buy sent before its pool is open reverts, and costs its gas.

Pangea's launcher launches your token on every chain, as for any launch. With the bundle kit, on each chain that has private bundles you get our own signed launch transaction for a short hold (20 seconds by default): put it in a bundle of your own with your buys right after it, and the launch and your buys land together. You pay everything: the bundle's gas and tip, the gas of our held launch, your buys, and the usual launch fee. Pangea assembles no bundle, signs nothing of yours and keeps no gas of its own on the held transaction.

Two ways to bundle on Ethereum or BSC. Here: along OUR signed launch transaction, as below. Or with "Launch it yourself": you send each EVM launch from your own wallet and bundle it however you like.

How to use it

• Prepare the launch with bundleKitHeld: true (a hold key is reserved for you on Ethereum and BSC: the quote then charges each such chain the gas to clear the hold key if a hold lapses, 52,500 gas, and NOT that chain's launch transaction's gas -- its launch, launch buys, dev buy and fee check -- which your bundle pays; a chain with no free hold key, and the chain you pay on (never held), is quoted and launched un-held, and bundleKitHeld.unheld names it), pay the fee on any chain and submit with bundleKit: true (POST /api/v1/launch/submit). Base and Robinhood Chain buys: name them as launch buys when you prepare the launch.
• Poll POST /api/v1/launch/bundle-kit with { ticket }. A held chain shows state: "held", holdUntil (unix seconds) and tx: tx.raw (the raw signed transaction) on Ethereum and BSC, tx.wire (base64, a v1 transaction) on Solana. Only your ticket gets it, and only while it is held.
• Solana: put our transaction FIRST in your Jito bundle, your tip transaction after it, before holdUntil.
• Ethereum and BSC (once Solana is live): our transaction is signed by a hold key that holds no gas. Your bundle is three transactions, in this order: (1) yours, sending fund.wei (shown with it) to fund.to, the hold key; (2) ours, tx.raw; (3) your buys. Send it before holdUntil.
• Not landed by holdUntil on Ethereum or BSC: the kit shows state: "lapsed" -- that chain is NOT launched (our launcher never sends a held leg itself: its launch gas is your bundle's, not in the fee). The hold key's nonce is burnt (the 52,500 gas in your fee), and you are refunded that chain's share of the fee, and the route fee you paid for that chain if you ticked "Open all bridge routes at launch". Solana: state: "sent", our launcher sends exactly the held transaction. A bundle sent after the hold may revert, at your gas.
• Live: state: "live". Solana shown state: "ours" could not be held (its transaction could not be signed): our launcher sends it, as for every launch. An Ethereum or BSC leg quoted held is never sent by our launcher: one that could not be held at launch (for example, every hold key was in use) is state: "lapsed", as above. state: "checking": the chain could not be read after its hold -- it is read again, and is then live or lapsed.
• The chain you pay on is never held (owner rule): paid on Ethereum or BSC, that chain is launched by our launcher as usual, un-held, with its launch gas in the fee, and you cannot bundle on it. Instead you can bundle on your other chains, use "Launch it yourself" and send that chain's launch from your own wallet, or pay on another chain. Prepare's bundleKitHeld.payChain says so, and the launch page shows it before you pay.
• A lapsed chain is not launched, and nothing is bridged to it: it is left out of the coin's chains, its routes and every bridge quote.

Before factory v2. Every launch deployed the same token on all five chains at once. Each chain got 1B tokens in its liquidity pool, 5B in all, and all five pools opened at the same US dollar price: $3,000 of market cap a chain.

Every token went into its liquidity pool from the start. There is no team allocation, treasury or vesting. Each pool started with tokens only and collects the quote asset as people buy.

Each chain operates independently, and one thing keeps the five prices together: arbitrage, which is open to anyone. Buy on a cheaper chain and sell on a more expensive one.

What a v1 coin does not have

These came with factory v2, and a v1 coin has none of them: a launch on selected chains, a chosen opening market cap, degen mode, a different trading fee on each chain, a fee receiver apart from the creator wallets, and coin tokenomics. How v2 works →

The v1 factory

Nothing new launches from it. The coins it launched trade, bridge and pay their fees as this tab describes.

Each chain got 1 billion tokens in its liquidity pool, held in a concentrated liquidity position. As the price rises, the pool sells tokens and collects the quote asset.

Each pool pays sellers from its own reserves. A chain with fewer buyers may have less quote asset available, regardless of how much liquidity exists elsewhere.

Opening market cap

Every v1 coin opened at $3,000 a chain, $0.000003 a token, on all five chains at once. It was fixed by the contracts, not chosen.

Each chain has its own token contract and address, so buyers choose which chain to trade on.

A token’s address is different on every chain (unless its creator chose “Same contract address on all EVM chains”, which puts it at one address on the four EVM chains), and every one of them ends in 6ea: the last three hex digits on the four EVM chains, the last three characters of the mint on Solana. The token’s page lists every one.

Each chain has 1 billion tokens in its own liquidity pool, so 5 billion across the five chains.

Each contract reports its own chain’s 1B supply.

Terminals and apps calculate market cap in different ways. A token’s full market cap is the sum of its market caps on all five chains.

The price is the same on every terminal and app. You can bridge your tokens, or buy on any of the five contracts, at the same dollar price for the same number of tokens.

To see a token’s complete market cap, use its page on this site: it is the most accurate source.

The differences between platforms come from how Pangea manages supply on each chain to keep prices in line. That is what keeps the price gap between chains small, and what makes a single token across many chains possible. Every platform is consistent with itself, and many of them show the same figures.

The key point: the same token, at the same price, on every chain.

Each v1 launch set a trading fee between 0.3% and 5%, once, at launch, the same on all five chains. No contract function or program instruction changes it afterwards.

The platform takes 20% of the trading fee, with a floor of 0.2% of volume. The creator receives the rest.

80% of platform fees go to PANGEA buybacks.

Who receives the creator’s share. The creator wallets the launch named: one EVM address for the four EVM chains and one Solana address for Solana. On Solana, the fee split is enforced by Pangea's splitter program.

Where the fee goes can change. Either side may hand its stream to another address, in two steps — the new address has to accept it — so a project that changes hands does not have to relaunch to move its revenue with it.

Fees are paid in the quote asset: ETH, BNB or SOL. Never in the token that was launched.

Meteora supports collecting fees directly in the quote asset. Uniswap v4 collects fees in whichever token enters a swap, so fees from sells accrue in the launched token.

To convert them, the platform swaps those tokens for the quote asset when fees are claimed. This keeps extra code off the trading path, reducing the risk of a bug disrupting swaps. The trade-off is a small price impact from selling the collected tokens into the pool.

$PANGEA is live. It launched through Pangea on all five chains, with the same five-chain structure as every other token. Trade $PANGEA →

The team holds about 19% of the total supply of $PANGEA, which is 5B summed across the five chains. Most of it is locked: about 14.4% sits in vesting contracts and is released in equal monthly steps over two years. The remaining 4.18% is a marketing treasury. Nothing is held in an anonymous wallet: every address below can be checked on chain.

Locked allocation

The locked tokens are not in a team wallet. They sit in Team Finance lock contracts on Ethereum, Robinhood and BSC, and in a Streamflow vesting stream on Solana. Each releases in equal monthly steps over 24 months, about 0.6% of the total supply a month across the four. No one can withdraw ahead of that schedule: the three Team Finance locks have no owner (it was handed to 0x…dEaD on 2026-10-24, which ends their emergency withdrawal and revocation), and the Streamflow stream cannot be cancelled by its sender or its recipient.

Marketing treasury

The treasury funds marketing and growth. It is one address on every EVM chain, 0x402908cd6eB5176A1B9FdE3690CCccF41d7D54D0, named pangeatreasury.eth, pangeatreasury.base.eth and pangeatreasury.bnb.

The token uses LayerZero OFT. Transfers burn tokens on the source chain and mint them on the destination, keeping the total across the five chains unchanged. There are no wrapped tokens.

Each chain’s pool received its 1 billion tokens at launch, so all five pools opened at once.

Standard or fast

A standard transfer takes LayerZero’s own path. On every route the verifiers attest once the source transaction has 1 confirmation, and a transfer typically arrives in 4 to 16 seconds. From Ethereum, whose blocks are slower, it takes longer. How to bridge, step by step →

A fast transfer arrives in seconds: a relayer pays the recipient at once from its own tokens and is repaid when the standard transfer lands. It costs the fast lane’s own 0.2% on top of the standard 0.2%, plus the relayer’s price, which is capped at 10%. The bridge screen offers it only when a relayer is quoting your transfer. Relayers →

What a transfer costs

• The token’s fee. The token keeps 0.2% of every transfer between chains. It goes to the platform. On the four EVM chains it is fixed in the token contract and nobody can change it. On Solana, the fee split is enforced by Pangea's splitter program.
• The message fee. LayerZero’s price for carrying the transfer, paid in the source chain’s native asset. It is quoted for the exact transfer before you sign.
• A Solana route’s setup. The first transfer on a Solana route nobody has used yet also pays a one-time setup fee for that route. Every later transfer on it does not.

A transfer of 1,000 tokens: 2 go to the platform and 998 arrive.

Bridging moves your tokens from one chain to another. It is the same token on both sides: the tokens are burned where you send them from and minted where they arrive, so nothing is wrapped and the total across the five chains does not change.

On the Bridge page

• Pick the token. Open Bridge in the menu and choose the token, or open a token’s page and use its bridge tab. A link with the token in it, such as /app/bridge?token=ptest4, opens it ready.
• Pick From and To. The chain your tokens are on now, and the chain you want them on. The swap button between them turns the route around.
• Connect a wallet. An EVM wallet for Ethereum, Base, Robinhood Chain and BSC, a Solana wallet for Solana. A route between an EVM chain and Solana needs both: one sends, the other receives.
• Enter the amount. Your balance on the From chain is read from the chain. The page shows what you send, the token’s fee, what arrives, and the message fee, before you sign anything.
• Choose Standard or Fast. Standard is the token’s own path. Fast appears only when a relayer is quoting your transfer.
• Sign. One transaction on the From chain for a standard transfer. A fast transfer may ask for an approval first. The first transfer on a Solana route that nobody has used yet may ask for a setup step first; see below.
• Wait for it to arrive. The page follows the transfer and says when it has landed. Recent transfers are listed under the card.

What it costs

• The token’s fee, 0.2%. Kept by the token for the platform, out of the amount you send. 1,000 tokens sent, 998 arrive. (A token from before factory v3. A factory v3 token's fee is its chain's registry figure, 0.2% unless changed, at most 0.5%.)
• A factory v3 token: the price-gap fee. A transfer from the chain where the token is cheaper to the chain where it is dearer also pays the price gap, burned at the destination. The quote shows the estimate before you sign; the other way is free.
• LayerZero’s message fee. Paid in the From chain’s native asset: ETH on Ethereum, Base and Robinhood Chain, BNB on BSC, SOL on Solana. It pays the verifiers and the delivery on the other side, and it is quoted for your exact transfer before you sign.
• A factory v3 token into Ethereum: Pangea's delivery. LayerZero's executor does not deliver there, so Pangea's delivery keys land the transfer; their cost is part of the network fee, in the From chain's coin (out of Solana, in SOL), and the quote shows it as its own line (Pangea delivery).
• A factory v3 token into Solana: the Solana delivery. Pangea's delivery key lands the transfer on Solana; its cost is withheld from what arrives, in the token, and shown as its own line (Solana delivery). A new wallet's first arrival also pays its token account's rent from it.
• A transfer too large for one send: every part pays. Sent in parts, each part is its own transfer and pays the full network fee (LayerZero, and any delivery above); the quote shows the fee per part and the total for all parts before the first signature. A co-signed transfer (one send) shows its fee and its guaranteed minimum before you sign it.
• Gas. The transaction itself, on the From chain, as for any transaction there.

Those are live quotes from 19 October 2026, to show the size of the fee; it moves with gas prices. A transfer into Solana costs more because it also pays for the token account the tokens arrive in.

How long it takes

A standard transfer waits for its transaction to have 1 confirmation on the From chain, then for two verifiers to attest it, and is then delivered. Measured on mainnet, transfers between Base, BSC, Robinhood Chain and Solana took 4 to 16 seconds:

From Ethereum it takes longer. Ethereum makes a block only every 12 seconds, and the verifiers wait for the transfer’s block to be confirmed before they attest, so expect about half a minute or more. No transfer out of Ethereum has been measured on mainnet yet, and the Bridge page currently shows the same estimate for every route.

The fast lane

Fast is an option on top of the standard transfer. When you choose it, the transfer carries a public order on Pangea’s fast bridge, PangeaFastBridge, one shared contract per chain. A relayer sees the order and pays you on the To chain within seconds from its own tokens, and is repaid when your standard transfer lands. It costs the fast lane’s 0.2% and the relayer’s price on top of the standard 0.2%, and the price is fixed in the order before you sign. If nobody fills the order, your tokens still arrive the standard way and you get the relayer’s fee too. How relayers work →

• Fast appears only when a relayer is quoting your route and amount. Otherwise only Standard is offered.
• Into Solana it needs the token to allow a 232-byte message. Tokens launched from the current factories allow 256; some earlier launches allow 200, and for those the page offers Standard only into Solana.
• A fast transfer may need an approval first: the fast bridge moves the tokens for you, once.

Solana

• Into Solana, the recipient is a wallet. Name the Solana wallet that will own the tokens, not a token account. The tokens arrive in that wallet’s token account for the token, which is created on delivery if it does not exist.
• That account’s rent is in the message fee. Every transfer into Solana carries 2,074,080 lamports (about 0.002 SOL), the rent of a new Token-2022 account, paid in the From chain’s asset as part of LayerZero’s fee. You need no SOL to receive. For a factory v3 coin today, the first arrival to a new wallet instead has that rent withheld from the tokens that arrive (the quote’s gap.delivery.ata), and an arrival too small to pay it waits on Solana until the account exists (gap.warning).
• The first transfer on a route pays its setup. A token’s route between Solana and a chain is opened the first time anyone uses it. That first transfer also pays a one-time setup fee: the rent of the accounts LayerZero keeps for the route. The page shows it as a separate line and may ask for two steps. Every later transfer on that route, by anyone, does not pay it.
• Out of Solana, you pay in SOL. The message fee and the transaction fee are paid from your Solana wallet, so keep a little SOL there.
• Amounts cross at six decimals. The odd base units below 0.000001 token stay in your wallet.

If a transfer seems stuck

• Look it up on LayerZero Scan. Paste the transaction hash or signature of your send at layerzeroscan.com. It shows each verifier’s attestation and the delivery, with links to both transactions.
• Inflight or confirming. The verifiers are waiting for the confirmation or attesting. Wait: this is the ordinary state for the first seconds, and longer from Ethereum.
• Verified but not delivered. Delivery is open to anyone once a message is verified. LayerZero’s executor delivers it, and Pangea runs its own delivery service that delivers every Pangea token’s messages as soon as they are verified. If one sits verified and undelivered for more than a few minutes, anyone can deliver it by calling the destination endpoint’s lzReceive with the message, at their own gas cost. The exception: a factory v3 token's charged arrival into Solana, which only Pangea's appointed deliverers may land.
• Into Solana, on a route that is not open. A transfer sent into Solana before its route is opened waits, and is delivered once the route is opened; LayerZero Scan may show it as blocked until then. Nothing is lost in between. The Bridge page opens the route as part of the first transfer on it.
• A held fast order. When a fast order cannot be paid on the To chain, the fast bridge holds it for the sender. The Bridge page shows a button that sends it back; anyone may do it, paying LayerZero’s fee for the trip back.
• Nothing on LayerZero Scan. The send did not go through on the From chain. Check it on that chain’s explorer: if it failed, the tokens never left your wallet.

One token, five contracts

• An address per chain. A token is a LayerZero OFT contract on each of Ethereum, Base, Robinhood Chain and BSC, and a mint on Solana, held by LayerZero’s OFT program. The five addresses are all different (or, with “Same contract address on all EVM chains”, one on the four EVM chains and the mint on Solana) and all end in 6ea. They are on the token’s page and in /api/pools.
• 1B per chain. Each chain mints its own 1 billion at launch, all of it into that chain’s pool, 5 billion across the five. On an EVM chain launchSlice() is that 1B and launchTotal() the 5B (on a launch on fewer chains, 1B for each of them). Nothing can mint more: there is no mint function and no minter. In degen mode each chain mints its equal share of 1B instead, and launchTotal() is the 1B.
• Burn and mint. A transfer burns the tokens on the chain it leaves and LayerZero’s message mints the same number on the chain it reaches. On an EVM chain the token’s fee is moved to bridgeFeeTo() and only the rest is burned, so what is burned on one side is exactly what is minted on the other. A factory v3 token's price-gap fee is the exception: the destination withholds it and never mints it.
• What is on a chain, and what is reported. On each EVM chain localSupply() is what is on that chain now; it moves as tokens cross. totalSupply() is a reported figure: it starts at the chain’s 1B, and for tokens with a SupplyReporter the platform’s reporter on that chain mirrors the token’s supply on Solana into it. A report moves no balance and mints nothing, and a factory v1 token refuses one below its own localSupply() or above launchTotal(). Earlier launches have no reporter and always report their slice. A degen mode token reports the 1B total and takes no reports.
• Peers are sealed at launch. A peer is the token’s counterpart on another chain, the only address it accepts a mint from. The factory registers the four peers in the transaction that creates the token and hands ownership to a LaunchOwner contract that is sealed from the start: sealed_() is true and it has no way to add, change or remove a peer.

How every route is set up

A route is one direction between two chains, for one token. When the factory creates a token it is, for that one transaction, the token’s LayerZero delegate, and it writes every route from a table fixed in its own constructor. Nothing is left on LayerZero’s defaults, because a default can be changed by whoever administers the endpoint.

• Libraries. The send and the receive message library are named explicitly: LayerZero’s Ultra Light Node on every chain, the same contracts the endpoint’s defaults point at today, pinned so they stay.
• Executor. LayerZero’s executor on each chain is named explicitly, with a cap on the message size.
• Verifiers. No required verifiers. An optional set of Pangea’s own verifier plus the external ones, and 2 of the set must attest before a message counts. So no single party can deliver a message: not Pangea’s verifier, and not any one external one.
• Confirmations. 1 on every source chain, Solana included: the verifiers attest once the send has 1 confirmation. Both ends of a route hold the same number.
• A gas floor. Every transfer must give the delivery at least 100,000 gas on an EVM chain, and 200,000 compute units plus 2,074,080 lamports on Solana, for the recipient’s token account. It is an enforced option, added to every send, so a sender cannot under-pay delivery.
• A message size. Up to 10,000 bytes between EVM chains and from Solana. Toward Solana 256 bytes for launches from the current factories; the factory admin can move that between 200 and 800 for launches after, never for a token that exists. A Solana transaction is small, and a cap above what Solana can deliver would let a message be sent that can never land.

That is the set on each chain, for its routes to Ethereum, Base, BSC and Solana. Robinhood Chain has two of the external verifiers, so a route with Robinhood Chain at either end uses the verifiers both chains have: Pangea, LayerZero Labs and Nethermind, 2 of 3. Every other route has 5, 2 of 5.

On Solana the same is done by Pangea’s splitter program. The program holds one route setting per destination chain, and the first transfer on a token’s route applies it to that token, once: the libraries, the executor, the verifiers in both directions, the confirmations and the gas floor. The token’s LayerZero admin and delegate on Solana is an address only that program can sign for, and the program has no instruction that changes a peer, a library or a verifier afterwards.

Why nobody can change a route later

• On an EVM chain the factory writes the routes while it is the token’s delegate, then never calls the endpoint for that token again and has no function that could. The token’s owner, the sealed LaunchOwner, has no way to name another delegate. So no key, including Pangea’s, can change a token’s libraries, executor or verifiers.
• This matters because a delegate who could name the verifiers could name itself, attest a message nobody sent, and mint. Sealing the peers alone would not close that.
• One thing stays adjustable on purpose: the gas floor. The LaunchOwner’s admin can raise or lower it, so that a chain changing its gas costs does not break bridging for good. It accepts exactly one lzReceive option and nothing else, under hard caps of 1,000,000 gas and 10,000,000 in value, so it cannot add a payment to anyone or set a floor nobody can pay. On Solana the gas floor is fixed when the route is opened.
• The other side of this: if LayerZero retires a verifier a route depends on, that route keeps working only while two of its verifiers still attest, and nobody can swap one in. A paused bridge can be lived with; a token anyone could mint could not.
• On Solana the admin can change the route setting for launches still to come. A token’s route is applied with the setting in force when it launched, and the program refuses a setting edited after that, unless the admin signs the opening; once a route is open nothing changes it.

Check it yourself

Everything above can be read from the chains, with no help from Pangea. The worked example is PTEST4, a live test launch, on Base. Its address there is 0x2dEC1F0FBe66ef78a7cec00cD1FD9c58345ED6Ea; the other addresses are in the table at the end. These are read-only calls, with Foundry’s cast and any RPC endpoint for the chain.

TOKEN=0x2dEC1F0FBe66ef78a7cec00cD1FD9c58345ED6Ea
ENDPOINT=0x1a44076050125825900e736c501f859c50fE728c
RPC=your-base-rpc-endpoint

# its counterpart on Ethereum, BSC, Robinhood Chain and Solana
for EID in 30101 30102 30416 30168; do
  cast call $TOKEN "peers(uint32)(bytes32)" $EID --rpc-url $RPC
done

# the owner is a LaunchOwner, sealed: true
OWNER=$(cast call $TOKEN "owner()(address)" --rpc-url $RPC)
cast call $OWNER "sealed_()(bool)" --rpc-url $RPC

# the delegate, the only key that can set verifiers, is the factory that launched it
cast call $ENDPOINT "delegates(address)(address)" $TOKEN --rpc-url $RPC

EID=30416
SEND_LIB=$(cast call $ENDPOINT "getSendLibrary(address,uint32)(address)" $TOKEN $EID --rpc-url $RPC)
cast call $ENDPOINT "isDefaultSendLibrary(address,uint32)(bool)" $TOKEN $EID --rpc-url $RPC
cast call $ENDPOINT "getReceiveLibrary(address,uint32)(address,bool)" $TOKEN $EID --rpc-url $RPC

# verifiers: (confirmations, required count, optional count, threshold, required, optional)
ULN=$(cast call $ENDPOINT "getConfig(address,address,uint32,uint32)(bytes)" $TOKEN $SEND_LIB $EID 2 --rpc-url $RPC)
cast decode-abi "f()((uint64,uint8,uint8,uint8,address[],address[]))" $ULN

# executor: (max message size, executor)
EXE=$(cast call $ENDPOINT "getConfig(address,address,uint32,uint32)(bytes)" $TOKEN $SEND_LIB $EID 1 --rpc-url $RPC)
cast decode-abi "f()((uint32,address))" $EXE

# the gas floor every send carries
cast call $TOKEN "enforcedOptions(uint32,uint16)(bytes)" $EID 1 --rpc-url $RPC

What those return for this token, read on 19 October 2026:

The three optional verifiers it returns are Pangea’s on Base, 0x6dbFda44baB6bf0DDF3E9F88d7823eDdB48f4b25, and LayerZero Labs’ and Nethermind’s there. Toward Solana the same read returns 5 verifiers and an executor cap of 200 bytes: this token was launched before the factories raised it to 256. The gas floor toward Solana reads 0x00030100210100000000000000000000000000030d40000000000000000000000000001fa5e0: 0x30d40 is 200,000 compute units and 0x1fa5e0 is 2,074,080 lamports.

On LayerZero Scan, look up the token’s address, or any transfer. Its transfer from Base to Robinhood Chain on 16 October 2026, 0x5860a6920fd6fe6d97f7d88104d6ce105bb43fd4a9654d7d84cdd9229e961f65, shows all three of the route’s verifiers attesting, and the delivery five seconds after the send. Each message lists the verifiers that attested and the lzReceive gas it carried.

On Solana, a token’s route to a chain is open when LayerZero’s receive config account for it exists: the ULN program’s address for the seeds "ReceiveConfig", the chain’s endpoint id as four big-endian bytes, and the OFT store. Its contents are the confirmations and the verifiers, in the same order as above. For PTEST4, read on 19 October 2026, the routes from Base and Robinhood Chain are open, each with 1 confirmation and 2 of its verifiers, and the routes from Ethereum and BSC are not open yet: nobody has bridged on them. Bridging from code → has a script that checks it.

A relayer pays the recipient on the destination chain within seconds, out of its own stock of the token, and is paid back, plus its fee, when the bridged tokens arrive over the standard path a few seconds later. Nobody has to trust it: the recipient, the amount and the fee are fixed by the order, and a relayer that pays anything else is simply never repaid. If no relayer fills an order, the transfer arrives the standard way, and the fee no relayer earned goes to the recipient.

There is one fast bridge per chain, shared by every token launched on Pangea. A new token can use it the moment its launch lands: nothing is deployed for it. An order names its launch, never a token address, and the bridge reads the token itself from Pangea’s own factories, so a relayer is only ever repaid in, and a recipient only ever paid in, that launch’s own token on that chain.

What a transfer costs, and who is paid

• The token’s fee. The token keeps 0.2% of every transfer between chains, on either lane. It goes to the platform.
• The fast lane’s fee. On the fast lane the fast bridge keeps 0.2% first, also for the platform, and the token’s fee is then taken from what is left. The bridge’s admin can change it, per launch or for all, but never above 1%.
• The relayer’s fee. This is a price, not a platform fee. Relayers publish what they charge and the app takes the lowest. The bridge refuses any order that would pay a relayer more than 10% of what arrives, or the lower cap its admin sets.
• Your limit. You set a slippage, 0.5% unless you change it and 10% at most. If the best relayer price is above it, no fast transfer is offered, and the bridge refuses an order that would pay the recipient less.

One transfer of 1,000 tokens, three ways, with a relayer charging 0.1% as the example price:

On the fast lane the fast bridge keeps 2 tokens and the token keeps 1.996, so 996.004 are on their way. The relayer pays the recipient 995.007996 at once and receives the 996.004 when they arrive, keeping 0.996004. Both platform fees are taken on the chain the transfer leaves, when it is sent, so a fast transfer that nobody fills has still paid them.

Becoming a relayer

Anyone can be a relayer. There is nothing to apply for and nothing to stake: you publish a price, watch for orders and fill the ones you want. Filling is never an obligation, and leaving an order unfilled takes nothing from anyone. It does count against you if the order was posted at your published price, as described under benching below.

What follows is the whole protocol, two HTTP calls and a handful of contract calls, and any program that follows it is a relayer. The HTTP calls are for the price board only: watching and filling work entirely on chain.

1. What you need

• The token, on every chain you deliver to. Fills are paid from your own wallet. The fast bridge holds no stock of its own.
• An approval. On each of those chains, approve that chain’s fast bridge to move your tokens: approve(fastBridge, amount) on the token. Without it your prices are not taken and a fill reverts.
• Gas. A fill is a transaction on the destination chain, paid in its native asset: ETH on Ethereum, Base and Robinhood Chain, BNB on BSC.
• An RPC endpoint for each chain. You read OrderPosted logs on the chains orders leave and send fills on the chains they go to, so the endpoint must serve eth_getLogs. A WebSocket endpoint makes you faster: subscribed to the fast bridge’s logs it tells you about an order the moment it is posted.
• One key. The address that signs your prices is the address the app checks for tokens and approval, so sign with the wallet you fill from.

Check a bridge before you approve it. tokenOf(launchId) returns the token it moves for a launch, read from Pangea’s factories (isFactory(factory) says which it accepts), and remoteBridge(eid) its counterpart on another chain.

2. Publish your price

You send a signed price sheet to the price board. The board is public: read it to see the prices you are competing with, the ceiling, and who is benched. A route is a pair of chains on one shared bridge, so one price covers every token on that route; the app only takes it for a transfer when you hold that token on the destination.

{
  "sheet": {
    "v": 1,
    "relayer": "0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
    "issuedAt": 1760000000,
    "expiresAt": 1760000120,
    "routes": [
      {
        "fromEid": 30184,
        "toEid": 30102,
        "bridge": "0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
        "feeBps": 10,
        "minFee": "1000000",
        "maxAmount": "50000000000000"
      },
      {
        "fromEid": 30101,
        "toEid": 30102,
        "bridge": "0xcccccccccccccccccccccccccccccccccccccccc",
        "feeBps": 10,
        "minFee": "1000000",
        "maxAmount": "50000000000000"
      }
    ]
  },
  "signature": "0x<65-byte signature, 130 hex characters>"
}

The signature is over the text below, signed as an Ethereum personal message: EIP-191, which wallets offer as personal_sign. The lines are joined by a single newline with none at the end, addresses are in lower case, and the routes are sorted by fromEid, then toEid, then bridge, whatever order the JSON lists them in. This is the text for the body above:

Pangea relayer quotes v1
relayer: 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
issued: 1760000000
expires: 1760000120
30101>30102 0xcccccccccccccccccccccccccccccccccccccccc 10bps min 1000000 max 50000000000000
30184>30102 0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 10bps min 1000000 max 50000000000000

Your fee for a transfer is feeBps of what arrives, rounded up, and never less than minFee. If that comes to more than the ceiling allows on that transfer, or the transfer is larger than maxAmount, you have no price for it.

A sheet stops counting at its expiry, so publish again before then. Every 30 seconds is plenty, and the board accepts 120 publishes per caller in ten minutes. Each new sheet replaces your last one and must carry a later issuedAt. Stop publishing and you are off the board when your last sheet expires.

{
  "now": 1760000030,
  "maxFeeBps": 1000,
  "sheets": [
    {
      "sheet": "<a sheet, as published>",
      "signature": "0x<its signature>"
    }
  ],
  "benched": [
    {
      "relayer": "0x<address>",
      "until": 1760003600
    }
  ],
  "neverBenched": [
    {
      "relayer": "0x<address>",
      "strikes": 1
    }
  ]
}

Reading is limited to 300 requests per caller in ten minutes. maxFeeBps is the ceiling in force, sheets every live sheet with its signature, and benched the relayers whose prices are not being taken, with the unix second each bench ends. neverBenched lists the relayers this deployment never benches that have strikes within the hour, with how many.

How the app chooses. For each transfer it works out every live sheet’s price and looks at the 4 lowest, lowest first. Between equal prices the sheet with the earlier issuedAt comes first. It takes the first whose relayer holds what the fill pays, in that launch’s token on the destination chain, and has approved the fast bridge there for it. Benched relayers are left out. If that price would leave the recipient less than the sender’s slippage allows, no fast transfer is offered. When no relayer quotes a transfer at all, the fast lane is simply not shown.

3. Watch for orders

Every fast transfer is an order, posted on the fast bridge of the chain it leaves. That bridge emits one event for it:

event OrderPosted(
    bytes32 indexed orderId,
    bytes32 indexed launchId,
    uint32 dstEid,
    bytes32 indexed sender,
    uint64 senderNonce,
    bytes32 to,
    uint256 amount,
    uint256 relayerFee,
    uint64 lzNonce
);

Orders from Solana

An order from Solana is posted by Pangea’s fast-bridge program (post_order) and carried by the sender’s own OFT send, in the same Solana transaction. On an EVM destination, for source endpoint 30168, the order’s srcBridge is the sender’s own key (the OFT’s composeFrom), and the sender in the order is always taken to be that key: nobody can post in another’s name.

Verify before you fill. Skipping post_order only skips the fast lane’s fee, so an EVM-side check cannot tell you the order was paid for. Before filling an order from Solana, read the Solana transaction yourself and fill only when it holds both the post_order instruction and the OFT send it checks, with the same launch, recipient, amount and fee, and the transaction is finalized. A fill on anything less is a bet nobody else is making for you.

4. Fill

A fill is one call, made on the chain the order is going to:

function fillOrder(
    uint32 srcEid,
    bytes32 srcBridge,
    bytes32 launchId,
    bytes32 sender,
    uint64 senderNonce_,
    address to,
    uint256 amount,
    uint256 relayerFee,
    uint64 lzNonce
) external returns (bytes32 id);

srcEid is the endpoint id of the chain you saw the event on, and srcBridge the bridge that emitted it, as 32 bytes (the address left-padded with zeros): the destination accepts only a bridge it has named for that chain, else NotARemoteBridge. From Solana, srcBridge is the sender’s own key instead (see below). The other arguments are the event’s own fields, with to as the 20-byte address it pads: senderNonce_ is its senderNonce. In the same transaction the bridge moves amount - relayerFee of tokenOf(launchId) from your wallet to the recipient and records you as owed amount.

Every one of those fields is hashed into the order’s id. Change the source bridge, the launch, the amount, the recipient or the fee and you have filled an order nobody posted: you have paid someone, and nothing will ever repay you.

Check before you send, on the destination bridge. Each check is a read and saves the gas of a fill that would revert:

• filledBy(orderId) is the zero address: nobody has filled it yet.
• notYetArrived(token, srcEid, lzNonce), with token the launch’s token on this chain, is true: the order’s own message has not reached this chain. Once it has, there is nothing left to deliver early and a fill is refused.
• You hold amount - relayerFee of the token there and your approval covers it.
• relayerFee is at least your own price for that amount. You are never obliged to fill.

A fill that goes through emits OrderFilled(orderId, relayer, to, paid).

5. Get repaid

You are repaid on the chain you filled on, in the token, when the order’s own message arrives and the bridge settles it: seconds after the order was posted. The bridge checks that the message came from the launch’s own token and the source chain’s own fast bridge before it pays anyone. settlement(orderId) on the destination bridge says how the order settled:

The same order can only arrive twice from Solana, when a sender reuses a nonce. The second arrival is paid to the recipient (ArrivedAgain and SettledSlow) and the first settlement stands: each arrival brought its own tokens, so none is refused.

Sending a held order back

Anyone may send a held amount back to its sender on the chain it came from: quoteRefund(guid) gives LayerZero’s fee for the message back, and refund(guid), paying that fee, sends it (Refunded). refunds(guid) shows what is held. The bridge screen offers this button itself when a transfer it sent is held.

What earns the fee. The fee pays for delivering early with your own tokens, so a fill earns it only when both of these are true:

• The lzNonce your fill named is the nonce of the message that settles the order.
• The settlement lands in a later block than your fill. A fill settled in its own block is repaid what it paid out and earns nothing.

filledBy(orderId) and filledLzNonce(orderId) return the filler and the nonce it named. So fill as soon as you are willing to.

Ceilings

What gets you benched

When the app sends an order at your published price, it remembers that the price was yours. Each order is judged once: reporting the same transaction again records nothing. It looks at the order again from 2 minutes after it was posted and judges it once it has settled, or after 30 minutes if it still has not. An order nobody filled, or one you filled without earning the fee, is a strike against you.

After 3 strikes within 60 minutes your prices are not taken for 60 minutes, however low they are. Those are the defaults, and a deployment can set its own. Your sheets stay on the board, and benched in the board’s answer says until when.

A deployment can name relayers it never benches, in BRIDGE_RELAYERS_NEVER_BENCH: EVM addresses, or Solana accounts a sheet names and has signed with. These are its own relayers, so nobody can switch its fast lane off by posting orders at its price while its stock is busy. Their unfilled orders are still struck and shown under neverBenched, but the strikes never add up to a bench. When the setting is empty, every relayer can be benched.

• It is not a strike if any relayer’s fill earned the fee: the sender was served.
• It is not a strike if another address filled the order without earning the fee within 90 seconds of it being posted and before the block that settled it, because that fill paid the recipient early and shut you out. A fill made later, or in the settling block itself, delivered nothing early, so it does not excuse you.
• It is not a strike if you could not have filled it. When the app gives your price it reads, at one block of the destination chain, your balance of that launch’s token and your approval of the fast bridge, and it only gives your price if they cover the fill. What you could pay out is the lower of the two. An order is matched to the last quote given before it was posted, if that was no more than a few minutes earlier (an order posted long after its quote counts against nobody), so asking for the quote again later changes nothing. Only when a strike is about to be given, the app subtracts what you have paid out since in other fills of that same launch that served somebody, until the order settled (or until it is judged, if it never did), or 90 seconds after it was posted if that is later. If what is left is less than the order pays, there is no strike. So somebody draining your stock with many small orders first does not turn the larger ones after them into strikes. A fill that would excuse you but has not settled yet is waited for, up to 30 minutes after the order was posted.
• A fill counts only if it was your own direct call of the bridge’s fillOrder for that launch (not through a contract or a batch, which cannot be read), came from an EVM chain, paid someone other than you, and earned the fee: it named the order’s own message and came before the block that settled it. A fill of an order nobody posted never settles, and one that names the wrong message or lands in the settling block is repaid at once, so neither excuses anything. Fills of orders from Solana do not count, because a plain token send from Solana can make one without paying the fast lane’s fee. Moving your stock away or revoking the approval excuses nothing either, nor does running out of native gas: both are yours to top up. Repayments that arrive in the meantime are not added back.
• Into Solana only the balance read when the price was given is used, because there is no cheap list of your fills there. Orders into Solana are not judged yet.
• If a read fails, there is no strike then. The order is checked again later, a few times, and if it still cannot be checked it is dropped without a strike, and the server logs it. A rate limit or a slow node is such a failure. Having more fills in the window than are read, or more in one block than the chain will list, is not: it is no excuse, and neither is a drain made of more than that many fills. The app makes at most a few of these checks a minute, and fewer for any one relayer, so a strike can come a little later than the order was due.
• A fill does not clear earlier strikes. Each one stops counting 60 minutes after it was given.

The risks you take

Relaying is a business you run with your own money. Nothing here promises that it pays.

• A reorg on the source chain. Between your fill and your repayment, the fill is unsecured. If the source chain reorganises and the order’s transaction is gone, the message never arrives and nothing repays you. How many blocks you wait before filling is your own trade between speed and that risk. If a reorg keeps the order but moves its message to a different LayerZero nonce, you are repaid what you paid out and earn nothing.
• Filling before the order is in a block. Acting on pending transactions is the fastest way to fill and the riskiest: a transaction that has not been mined is likelier to vanish than a confirmed one.
• Inventory. You hold the token on every chain you serve, and its price moves while you hold it. Your fee is paid in the token too.
• Gas. A fill that reverts still costs gas, and gas is paid in the chain’s native asset while your fee is paid in the token. A price that does not cover gas loses money slowly.
• Time. Your tokens are out until the order settles. Settlement is run by LayerZero’s executor; if it stalls, anyone may run it, and until someone does you wait.
• Being shut out. Only one fill per order is accepted. Another address can fill ahead of you, even with a nonce that earns it nothing, and that order is then closed to you.

Contract addresses

One fast bridge per chain, shared by every launch: Ethereum, Base, Robinhood Chain and BSC (deployed 16 October 2026), then Solana. The full interface is the bridge’s ABI and INTERFACE.md. These are the addresses, and the endpoint ids a price sheet and a fill use:

Pangea is a token launchpad. Each launch deploys its token as five contracts, a LayerZero OFT on Ethereum, Base, Robinhood Chain and BSC and a mint on Solana, and opens one liquidity pool per chain at the same US dollar price. This section is the reference for reading and using it from code.

These docs are also published as Markdown, generated from the same source as this page:

Each section is also on its own, at /app/docs/<section id>.md. This section is /app/docs/integrators.md.

The five chains

The endpoint id is LayerZero’s, and it is how the token names a chain. Solana has no EVM chain id.

Units

• Every token has 9 decimals, on all five chains. An amount in base units is a whole number at 9 decimals: one token is 1,000,000,000 base units.
• A transfer between chains crosses at 6 decimals. It is rounded down to a multiple of 1,000 base units, and the odd base units stay in the sender’s wallet.
• Fees are in basis points. One basis point is 0.01%.
• The standard supply is 5 billion tokens, 1 billion in each chain’s liquidity pool at launch. On an EVM chain totalSupply() starts at that chain’s 1 billion and is a reported figure that moves no balance, so every chain shows a market cap on the same basis (LayerZero routes says how it is reported); launchTotal() is the sum across the launch’s chains, and localSupply() what is on that chain now. On Solana the mint’s supply is what is on Solana now: tokens bridged in are minted there and tokens bridged out are burned. The market cap situation explains why terminals show different market caps.
• A launch on selected chains is 1B on each of its chains only. A degen mode launch is 1B in all: each chain mints an equal share, every chain’s totalSupply() and launchTotal() report the 1B, and on Solana the mint holds the full 1B with the rest in its bridge reserve. Degen mode has the figures.
• Times in the API are unix seconds unless a field says otherwise.

Rules that surprise people

• Every launch is paid for by the person launching it, once, on the chain they pick, in that chain’s native asset. There are no free launches.
• Every launch opens at the same price on every chain, at the market cap its creator chose for the whole coin, every chain together: $3,000 to $500,000 a chain times the chains (in all, for a degen mode coin), signed into the launch. The price per token is that market cap over the whole supply. Launches before factory v2 all opened at $3,000 a chain, $0.000003 a token. Read a token’s price from the API; do not assume its opening one. On factory v3 there is no locked supply: degen mode is normal mode, every chain minting its own 1B and pooling all of it, opening at $600 a chain ($3,000 for a coin on five chains). The least a v3 launch may open at is $600 a chain, which the platform may set between $600 and $3,000 a chain; standard mode still opens at $3,000 a chain unless the creator picks another cap.
• A token has one address per chain it is on, all different (or one address on the EVM chains, for a token launched with “Same contract address on all EVM chains”), and every one of them ends in 6ea: the last three hex digits on the EVM chains, the last three characters of the mint on Solana. Read the addresses from the API. Do not assume two chains share one.
• A transfer between chains of a token from before factory v3 costs 0.2% of the amount, kept by the token for the platform, plus LayerZero’s message fee in the source chain’s native asset. A factory v3 token's bridge fee is its chain's registry figure (0 to 0.5%), and a transfer from the chain where it is cheaper to the chain where it is dearer also pays the price-gap fee, burned at the destination: the quote's gap.burned, an estimate. It is attested after 1 confirmation on its source chain and typically arrives in 4 to 16 seconds.
• Each launch sets its trading fee once, between 0.3% and 5%. No contract function or program instruction changes it afterwards.
• The first transfer on a Solana route nobody has used yet also pays a one-time setup fee for that route. Every later transfer on that route does not. Any wallet can pay it, a smart-contract wallet too, except a Safe: its transactions wait for its owners, so a Safe bridges once the route is set up. Pay it from your own wallet, as the bridge page does: a payment sent through another contract (a multicall or a router) is refunded to that contract, not to you, and one made by delegatecall is not seen at all.
• On the four EVM chains nothing can mint more of a token. On Solana the mint authority is the token's store in Pangea's deployment of LayerZero's OFT program, which mints exactly what was burned on another chain. Bridging burns on one chain exactly what it mints on another, with one exception: a factory v3 token's price-gap fee is withheld at the destination and never minted, so it is burned.
• Prices on the five chains are separate markets. They are held together by arbitrage, not by a mechanism, and can differ.

What you can and cannot do from code

• You can read every launch’s pools, prices, reserves and addresses, its trades and volume, recent bridge transfers and its metadata, over the HTTP endpoints below.
• You can trade directly against the pools: Uniswap v4 on the EVM chains, Meteora DAMM v2 on Solana. The API gives each pool’s id and venue.
• You can bridge by calling the token itself, or price a transfer over HTTP and sign the transaction it returns.
• You can launch over the Launch API: quote a launch, pay for it from your own wallet, hand it over and follow it. The price snapshot every chain launches with is still signed by the platform, after your payment is checked. Launch API →
• No API key is needed and there are no accounts. Every endpoint here is public. Where one is limited, the limit is per caller, by IP address. The Launch API has no rate limit for normal use, and takes an optional partner key: API keys and limits →.
• Do not crawl the API. Each read costs reads on five chains. Call an endpoint when you need its answer; robots.txt asks crawlers to stay out of /api/.

HTTP endpoints

All are under https://www.pangea.trade/api. They take and return JSON and need no key. Over a limit the answer is 429 with a message saying how many seconds to wait. An error is { "error": "..." }. A value the chains could not give is null rather than a guess, so check for it.

No parameters. The answer is { live, readAt, rates, blockers, launches }. When nothing has launched, live is false and launches is empty. Each launch carries:

Query: launch, a slug, or leave it out for every launch; hours, a whole number from 1 to 168, 24 unless given. The answer is { readAt, hours, cursor, rates, totals, launches }. An unknown slug is a 404. Each launch carries volumeUsd, trades, coverage, chains, candles and recent.

• coverage runs from 0 to 1. Below 1 the figures describe part of the window you asked for, not all of it. Show it, or check it.
• candles are { t, o, h, l, c, v, vu }, one per bucket that traded, where t is the bucket's start. A bucket with no trade is left out, not filled with the last price. The prices are in US dollars. v is the quote volume in each chain's own asset, so across chains it adds ether, BNB and SOL together; vu is the bucket's volume in US dollars at the same rates as volumeUsd, and null when a trade in it had no rate.
• recent is the last trades, newest first: { id, chain, timestamp, txHash, side, tokenAmount, quoteAmount, quoteSymbol, priceUsd, valueUsd }, where side is buy or sell.
• A coin's whole history, a page at a time: add trades=latest (the newest page) or trades=before:<next> (the page after the one that gave next) with launch, and limit of 50, 100 or 200. The answer is { slug, readAt, trades, next }, every chain newest first, the rows as in recent; next is null on the page that reached the first trade. The first page also carries total, every trade since the launch, and complete, whether every chain is recorded back to it.

Query: token, a slug, optional; hours, 1 to 168, 24 unless given; limit, 1 to 100, 25 unless given. The answer is { recording, hours, since, uncovered, totals, cursor, transfers }. A transfer is { id, guid, slug, from, to, at, amount, party, complete, tookSeconds }.

• recording false means this deployment keeps no record, and the list is empty for that reason, not because nobody bridged. reason says why.
• uncovered lists the chains whose sends are not recorded. A transfer out of such a chain appears as an arrival with no send.
• complete false means one side is recorded: a transfer in flight, or one that failed. The feed does not guess which.

Query: launch, a slug, required. The answer is { uri, resolvable, name, symbol, description, image, website, twitter, telegram }, or { uri, resolvable: false, reason } when the document cannot be opened. Every field is the token author’s own claim. The name and symbol that cannot be edited are the contract’s, in the pools endpoint.

{
  "slug": "<launch slug>",
  "from": "base",
  "to": "bsc",
  "amount": "1000000000000",
  "user": "0x<sender, and the recipient unless one is given>"
}

The answer is { symbol, from, to, amount, routes }, where routes holds two routes: canonical, the token’s own LayerZero transfer, and fast, the same transfer with a fast order. A route that cannot be used says why in unavailable. It carries: