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 to 1,000,000,000,000 coins |
| opening valuation | where the price starts, denominated in the pair asset | any |
| trading fee | charged on every trade | 0.01% to 3% |
| tick spacing | granularity of the price range | 1 to 1,000 |
| creator premine | share of supply you keep | 0 by default, hard-capped at 20% |
| fee routing | what happens to your share — see Fees | keep, or buy back and burn |
| salt | picks your coin's address | mined off-chain |
The launch fee is 0.0006 ETH, roughly a dollar and a half, and it is capped at 1 ETH in the contract so it can never quietly become a tax.
The one that trips people up
The opening valuation is denominated in the pair asset, not in dollars. Typing 1000 means a
thousand AERO against AERO — about $600 — and a thousand WETH against WETH, about $2.5 million. Four
orders of magnitude apart for the same number in the same box.
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 — cbXRP has 6, NVDAc 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.
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 and priced your coin's pool first |
TicksNotAligned | your range is not a multiple of the tick spacing |
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,
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.

