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 0.2 INJ, roughly a dollar and a half, and it is capped at 15 INJ in the contract so it can never quietly become a tax. Gas on Injective is a fraction of a cent: a launch uses about 1.45 million gas. An Infinity pool is an entry in Choice's CLPoolManager 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 wETH against wETH, about $2.7 million. Three 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 dollar 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 and USDC have 6. Get that correction wrong by hand and the launch opens twelve orders of magnitude off.

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 INJ works too: against wINJ the interface simply wraps it; against anything else it swaps your INJ into the pair asset first, through LI.FI, then approves and launches.

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. Charts, screeners and human intuition expect the first, so the SDK mines a salt that lands you there whenever it can.

Against wINJ it never can. wINJ lives at 0x0000000088827d2d…, an address that starts with eight zero bytes, so no mined address will ever sort below it: a coin paired with wINJ is always currency1, and the interface reads its price the other way up for you.

What can go wrong

PoolAlreadyInitialized is the interesting one. Your coin's address is predictable from your salt, and an Infinity 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 fraction of a cent of gas. Cheap to attack, cheaper to defend, never a loss of funds.

One more thing specific to Injective: its RPC nodes sometimes report no receipt for a transaction that did land, and under-estimate gas. The interface sends every write with a generous explicit gas limit and, if a receipt does not come, checks the chain for the launch itself before telling you anything failed.