How Launches Work

No bonding curve, no graduation event, no team allocation. One transaction, and it's final.

What happens when you create a launch

LaunchFactory.createLaunch() does everything atomically, in one transaction:

  • Deploys a new ERC-20 with a fixed total supply — 1,000,000,000 tokens, minted once, never again.
  • Deposits the entire supply as a single-sided Uniswap v3 position (100% token, 0% paired asset) — no counter-liquidity required from the creator.
  • Deploys a fresh PermanentLockVault and transfers the position NFT into it.
  • Optionally executes a dev-buy, if the creator attached funds for one (see below).
  • Charges a flat launch fee, paid directly to the treasury.

Every launch uses the same fixed fee tier and the same starting valuation — there's no per-launch parameter to misconfigure.

The lock is permanent, not timelocked

PermanentLockVault has no owner, no admin, and — unlike a typical liquidity locker — no withdraw function at all, for any caller, under any condition. This isn't a gated or time-delayed guarantee; there is no code path anywhere in the contract that can move the position out of it, ever. You can verify this yourself: a raw call to withdraw() on any vault address reverts with no such function existing.

The vault's one reachable action is collect() — callable by anyone, since it can only ever move accrued trading fees to two fixed addresses (the creator and the treasury), never the position itself. See Fees & Treasury.

The dev-buy is the only way a creator holds their own token

Since the entire supply goes into the locked position, a creator starts with zero balance of their own token by default. The optional dev-buy executes through the exact same public pool, at the exact same price, everyone else uses — in the same transaction as the launch itself. There is no reserved allocation, no discount, no separate mint.

Anti-snipe protection

Enforced inside the token's own transfer logic — not the frontend, not a router — so it applies no matter which contract someone calls through:

  • Launch block: only the creator's own dev-buy may touch the pool in the exact block the token deploys.
  • First-hour cap: for a configured window after launch, no single address can accumulate more than a fixed percentage of total supply.

Both restrictions self-expire — no admin action needed, and no admin action possible to extend them.

Protected names

A launch's name and ticker are checked against a banned list on-chain, before the launch can exist — rejecting anything that collides with a protected asset (stablecoins the protocol actually uses, and the chain's own native token symbol). The check is an exact match, case-insensitive — it is not a substring filter, so close variations aren't automatically caught.

The starting valuation, launch fee, and anti-snipe window are protocol parameters set at deploy time — see Supported Networks for the exact values live on each chain right now.