Launching a coin

One transaction. It deploys the coin, opens its pool, seeds it with the whole float, and records the launch. If any part fails, none of it happened.

What you choose

The launch fee is paid in ETH and set to about five dollars — 0.002 ETH at deployment — and it is capped at 1 ETH in the contract so it can never quietly become a tax. The launch form reads the live figure off the launchpad (launchFee()) rather than printing this one.

The one that trips people up

The opening valuation is denominated in the pair asset, not in dollars. Typing 1000 means a thousand UNI against UNI — about $10,000 — and a thousand WETH against WETH, about $2.7 million. Nearly three orders of magnitude apart for the same number in the same box.

The interface takes that decision away: every launch from the form opens at a $4,000 market cap, converted into the pair asset at its live price (Chainlink where Unichain has a feed, DexScreener otherwise). Only the contract and the SDK take a raw pair-asset figure.

The SDK exists so you never have to think about this: startFdvInQuote takes a figure in pair-asset units and sdk/src/range.ts converts it into ticks, including the correction for pair assets that do not have 18 decimals — USDC and USDT0 have 6, WBTC has 8. Get that correction wrong by hand and the launch opens twelve orders of magnitude off.

A Foundry test pins the SDK's arithmetic against the price a real pool actually opens at, so the two cannot drift apart.

Buying first, inside the launch

devBuyQuote spends pair-asset tokens on your own coin as the pool's very first trade, in the same transaction that opens it. You have to approve the launchpad for that amount beforehand, and the coin lands in the launching wallet.

You do not need to hold the pair asset first. The form lets you pay the dev buy in ETH: it is wrapped when the pair asset is WETH, and otherwise swapped for the pair asset through KyberSwap, which routes across Uniswap v2, v3 and v4 and Velodrome on Unichain. A wallet that accepts batched calls (EIP-5792 — a smart wallet, or a 7702-delegated one) signs swap, approval and launch as one prompt; any other wallet is walked through them one at a time. If the launch fails after the swap, the pair asset is in your wallet and the form points the dev buy at it, so the retry does not swap twice.

Doing it here rather than through a router afterwards is not about speed. The launchpad records msg.sender as the creator, so a router that bought on your behalf would have been recorded as the creator instead — and taken the fee stream with it.

devBuyMinOut is the least you will accept. It is not protection from other traders: nobody can trade before this, because the pool does not exist until this transaction. It guards against you and the pool disagreeing about the opening price, which is a real risk when the valuation is denominated in a pair asset with unusual decimals.

Why you mine a salt

PairToken takes no constructor arguments, so its init code hash is constant and its address is a pure function of the salt. That matters because a concentrated-liquidity pool prices currency1 in terms of currency0, and which of those your coin becomes is decided purely by whether its address sorts above or below the pair asset's.

Both work, and the contract handles both. But charts, screeners and human intuition all expect the first, so the SDK mines a salt that lands you there. It costs nothing but a few eth_calls.

What can go wrong

PoolAlreadyInitialized is the interesting one. Your coin's address is predictable from your salt, so a griefer can open its pool first and price it wrong. The launch reverts cleanly, you pick another salt, and you have lost nothing but gas. Cheap to attack, cheaper to defend, never a loss of funds.