NASDANK Docs
Open app
Protocol/Launch mechanism

Launch mechanism

One transaction deploys the token, creates and initialises the pool, deposits the entire supply as single-sided liquidity, locks the position and optionally buys the first bag. This page is what that transaction actually does, in order, and what each step guarantees.

The transaction, drawn

ONE TRANSACTION · ALL OR NOTHING Deploy fixed-supply ERC-20 Create pool token / wrapped init at P0 Seed whole supply, single-sided Lock LP into the locker no way out Dev buy optional, before anyone else Tradable on the DEX same block, no graduation gate
Any revert in any step reverts the whole transaction. There is no state in which a token exists without its pool, or a pool exists without its lock.

Step 1 — Deploy the token

A plain fixed-supply ERC-20 is deployed with the name, symbol and supply from the form. The entire supply is minted once, to the launcher, inside the constructor.

  • No mint function. Supply after deploy is supply forever.
  • Not upgradeable. No proxy, no admin, no implementation to swap.
  • Not fee-on-transfer, not rebasing. A swap moves exactly the amount it says it moves.

This matters for integrators: a standard ERC-20 means balanceOf before a transfer plus the amount equals balanceOf after, and routers do not need supporting-fee-on-transfer variants.

Step 2 — Create and initialise the pool

The canonical pool for token / wrapped-gas-token is created at the fee tier the launch selected, and initialised at a deterministic starting price derived from the opening market cap.

Why initialising inside the launch matters

A pool that exists but is uninitialised can be initialised by anybody, at any price they like. Doing it inside the same transaction that deploys the token means there is no window in which someone else can set your opening price. This is the single most important piece of front-run protection in the whole design.

Two things about the pool are permanent from this moment and can never be changed by anyone, including us:

  • The fee tier. Uniswap has no function to change a pool's fee after creation.
  • The token ordering. Whether your token is token0 or token1 falls out of address sort order and decides whether the pool's price is your price or its reciprocal. The indexer publishes this as tokenIsToken0; read it rather than assuming.

Step 3 — Seed the liquidity, single-sided

The entire supply (minus a dev buy, if any) is deposited as a concentrated position whose range sits at or above the opening price. Because the range never dips below spot, the position needs only the token — no wrapped gas token has to be found to pair against it.

As buyers arrive with ETH or BNB, the price walks up through the range and the wrapped token accumulates inside the position. The concentrated-liquidity curve is the price curve. There is no separate bonding-curve contract anywhere in the system.

TierRange shapeConsequence
Pro (V3)Full range on the current launcher, with wide / balanced / aggressive presets availableDepth concentrated where trading happens.
Custom (V4)Full range with a hook attachedThe pool's own LP fee is zero; the hook charges the fee instead.

Step 4 — Lock the position

The liquidity position is transferred into a locker contract. On Pro and Custom that locker is immutable and has no function that can move the position out, decrease its liquidity, or return principal. The only externally callable path that touches money is fee collection, which splits what it collects between the creator and the treasury.

The lock is permanent on both tiers — there is no launch type whose liquidity returns on a timer. Liquidity and locks sets out exactly what the locker can and cannot do, and how to verify it yourself.

Step 5 — The optional dev buy

If a dev buy amount was set, the launcher performs the swap inside the same transaction, against the pool it has just created, before the pool is reachable by anyone else. Change is refunded. See Dev buy and snipe defence.

Atomicity, and what it guarantees

All five steps are one call. The properties that fall out of that are worth stating explicitly, because they are the ones an integrator can rely on:

  • A TokenLaunched event implies the pool exists, is initialised, holds the supply as liquidity, and that the position is in the locker. There is no partial success to handle.
  • There is no window between deploy and lock in which liquidity could be removed.
  • There is no window between pool creation and initialisation in which the price could be set by a third party.
  • There is no orphaned token, pool or position left behind by a failed launch — a revert unwinds everything.

What happens afterwards

Nothing else in the protocol touches the pool. Trading is ordinary DEX trading: our interface routes through the UniversalRouter, and any other router, bot or aggregator works identically. Fees accrue inside the position (Pro) or on the hook (Custom) and are pulled by whoever calls the collect function — which is permissionless, so a stalled keeper can never strand a creator's fees.

Read Fees and splits next for what the fee actually is and who gets it.

© NASDANK Not affiliated with Robinhood Markets, Inc. Risk disclosures nasdank.fun