How a launch works

Launching is permissionless: anyone can call launch() on the launcher with a flat 0.001 ETH fee. One transaction deploys the token, creates and initialises its pool, mints the entire supply as a single position, locks that position forever, and optionally executes your first buy. When the transaction confirms the token is already tradeable and already indexed. There is no second step, no graduation, and no migration.

#What the transaction does

It then pays the launch fee to the treasury, records the launch in an on-chain registry (launches[token], allTokens), and emits a TokenLaunched event carrying every parameter an indexer needs.

#Why single-sided liquidity behaves like a bonding curve

A concentrated-liquidity position that holds only the token, priced from its lower boundary upward, is mathematically a bonding curve. There is no WETH in the pool, so the only thing a buyer can do is consume token liquidity and push the price up the range; the only thing a seller can do is push it back down. Price discovery starts at your chosen tick and walks monotonically with net flow — the same shape a curve contract would give you.

The difference is what it is. It is a real Uniswap V3 pool from block one, so:

• every aggregator, router and chart on the chain can see it immediately;
• there is no reserve pot sitting in a launchpad contract waiting to be migrated — the liquidity is in the pool the whole time;
• there is no graduation event to time, front-run, or fail. Nothing about the token changes at any market cap.

#Choosing a venue

The launcher holds an append-only venue registry. The owner can add a venue; no one can re-point or remove one, so a launched token’s infrastructure can never be swapped out from under it. Venue ids share the platform-wide dexId space, so one number means the same venue everywhere.

Each venue gets its own FeeLocker and fee receiver, because a locker binds its position manager immutably. Everything downstream — the ownership registry, both fee-policy managers, the fee split — is shared, so the choice of venue changes where your pool lives and nothing else about how your token works.

#Launch parameters

struct LaunchParams {
    uint8   venueId;               // 1 = Uniswap V3, 5 = SushiSwap V3
    string  name;
    string  symbol;
    string  image;                 // artwork URI
    string  description;
    string  socials;               // single JSON string
    string  metadataURI;           // ERC-7572 contractURI
    bytes32 userSalt;              // vanity-mineable; final salt binds msg.sender
    int24   tickIfToken0IsNewToken;// starting price tick, multiple of 200
    uint256 supply;                // 0 => 1,000,000,000e18
    bool    sniperGuard;           // opt in to launch protections
    uint256 devBuyMinOut;          // slippage floor for the atomic dev buy
    bytes   tokenFeeConfig;        // abi.encode(uint16 policyId, bytes data); empty = in-kind split
    bytes   creatorFeeConfig;      // same encoding; empty = fees paid to the creator
}

#Starting price and the FDV band

tickIfToken0IsNewToken is the starting price expressed as a Uniswap tick, normalised as though your token were token0 — so you do not need to know the eventual CREATE2 address ordering to compute it. It must be a multiple of the 1% tier’s tick spacing (200), which makes each step about 2%.

The launcher derives the implied starting FDV on-chain as 1.0001^tick × supply and rejects anything outside an owner-tunable band with MarketCapOutOfRange. This is a reject-only sanity rail — it never moves value — and exists so a mis-signed tick cannot open a pool at an absurd price.

#Vanity addresses

The token is deployed with CREATE2 from keccak256(abi.encode(msg.sender, userSalt)), so you can mine userSalt for an address you like. computeTokenAddress(deployer, params) is the on-chain predictor and mirrors launch() exactly.

#The dev buy

Send launchFee + X and X is spent buying your own token in the same transaction, delivered straight to you. devBuyMinOut is your slippage floor. Because it happens inside launch(), it is the first trade against the pool by construction — and with the sniper guard on, it is the only buy the launch block allows.

#Fee policies

tokenFeeConfig and creatorFeeConfig are where you decide what happens to your LP fees — burn, vest, stake, or buy-and-burn. Both bind immutably to the token at launch. Leave either empty for the default (in-kind split / paid to the creator). Full reference: Fee policies.

#After the launch

There is nothing you are required to do. Fees accrue whether or not anyone cranks them, collection is permissionless, and the token needs no maintenance. What you can do, as the token’s registered owner:

• edit the on-chain metadata — image, description, socials, contract URI — from the Edit form on My Tokens;
• rotate where your creator fee share is paid;
• trigger a buy-and-burn, or rotate the vesting recipient, if you chose those policies;
• transfer ownership to another wallet, or renounce it and freeze everything as it stands.

What you cannot do — because no one can — is mint more supply, unlock the liquidity, change the fee split, or alter the sniper-guard constants. Those were decided when the transaction confirmed.