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
| what it is | bounds | |
|---|---|---|
| name / symbol | the usual | 1–64 and 1–16 characters |
| pair asset | what your coin trades against | anything that clears the gate — see Pair assets |
| supply | fixed forever, no mint function exists | 1,000,000,000 on this site; 1 to 1,000,000,000,000 through the contract |
| opening valuation | where the price starts, denominated in the pair asset | fixed at a $4,000 market cap on this site; any value through the contract |
| trading fee | charged on every trade | 1% or 0.3% as presets, or any fee you type inside the launchpad's bounds — 0.3% to 10%, the top of which is a ceiling written into the contract that not even its owner can raise. The site pairs the fee with a tick spacing (200 from 1% up, 60 below); the contract takes any spacing from 1 to 1000 |
| creator premine | share of supply you keep | 0 on this site; up to 20% through the contract |
| first buy | pair-asset amount you spend buying your own coin as the pool's opening trade | 0 by default |
| fee routing | what happens to your share — see Fees | keep, buy back and burn, or pay your holders |
| salt | picks your coin's address | mined off-chain |
The launch fee is 0.15 AVAX, roughly a dollar and a half, and it is capped at 10 AVAX in the contract so it can never quietly become a tax. Gas on Avalanche is a few cents. A Uniswap V4 pool is an entry in the PoolManager rather than a contract of its own, so the only thing a launch deploys is your coin.
The one that trips people up
The opening valuation is denominated in the pair asset, not in dollars. Typing 1000 means a
thousand USDt against USDt — $1,000 — and a thousand BTC.b against BTC.b, about $80 million. Five
orders of magnitude apart for the same number in the same box.
This site takes the choice away rather than asking you to get it right: every coin launched from it opens at the same $4,000 market cap, converted into the pair asset at its live price. You do not set it, and nobody gets a different starting line. The contract only ever sees ticks.
Integrating directly? The SDK exists so you never have to think about this either: 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 — USDt has 6, BTC.b 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.
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.
Paying for it in AVAX works too: the interface swaps your AVAX into the pair asset first, through whichever Avalanche venue has the best route, then approves and launches — in one signature when your wallet supports batched calls.
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.
| your coin is | price reads as | buying moves the tick |
|---|---|---|
| currency0 | pair asset per coin | up |
| currency1 | coin per pair asset | down |
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
| revert | what happened |
|---|---|
QuoteNotEligible | the pair asset does not clear the depth bar — the error carries the reason code |
QuoteDenied | the pair asset is on the deny list |
PoolAlreadyInitialized | somebody opened your coin's pool first |
FeeOutOfRange | the fee is outside the launchpad's bounds |
TickSpacingOutOfRange | the tick spacing is not between 1 and 1000 |
TicksNotAligned | your range is not a multiple of the tick spacing |
DevBuyBelowMinimum | your first buy would have returned less than the floor you set |
InsufficientLaunchFee | you sent less than the launch fee |
CreatorShareTooHigh | premine above 20% |
PoolAlreadyInitialized is the interesting one. Your coin's address is predictable from your salt,
and a V4 pool is opened by whoever first names its key and a price — so a griefer can open yours
first, at a price of their choosing. The launch reverts cleanly rather than seed a pool somebody
else priced; you pick another salt and have lost nothing but a few cents of gas. Cheap to attack, cheaper to defend, never a
loss of funds.