What actually happens when you launch a token on a HyperEVM launchpad?
From the outside, a token launch is a form: name, symbol, supply, logo, submit. From the inside, it is a sequence of on-chain steps that all have to succeed, in order, with real gas spent at each one — and every step exists because of a specific way launches go wrong without it.
BT365 runs a token launchpad on HyperEVM (Hyperliquid's EVM chain, ID 999). This is what our launch pipeline actually does between "submit" and "your token is trading," step by step.
The eight steps
A launch on our pipeline executes these stages, journaled individually so a crash mid-sequence can be recovered rather than leaving a half-launched token:
- Deploy the token. A standard ERC-20 is deployed through a token factory. The deployer wallet — not the creator — temporarily owns it and holds the initial supply, because the next steps have to be signed by whoever holds the tokens.
- Create the pool. A liquidity pool is created on a Uniswap V3-style DEX, pairing the new token against WHYPE (wrapped HYPE), at the 1% fee tier.
- Mint the liquidity position. The entire token supply goes into the pool as single-sided liquidity — all tokens, no WHYPE. Nobody has to fund the other side.
- Deploy a fee splitter. A small immutable contract is deployed for this specific token, with the creator's address baked in at deployment. One splitter per launch, so fees from different tokens never commingle in a shared pot.
- Lock the liquidity NFT. The V3 position is an NFT, and it goes into an on-chain liquidity locker with an unlock date roughly nine hundred years out — operationally, forever. The splitter is registered as the lock's fee collector.
- Attest the lock. The pipeline reads the lock back from the chain and verifies it says what it should — owner, pool, collector — before proceeding. Trust, then verify, in the same transaction sequence.
- Open trading. Trading starts at a preset time (a couple of minutes after launch by default), not the instant the pool exists. During the first hour a per-wallet maximum buy applies, which blunts the advantage of being the first bot to see the pool.
- Hand over ownership. Token ownership transfers from the deployer to the creator. The platform's wallet ends the launch owning nothing.
If the sequence fails after it has durably started, it does not silently retry from scratch — a launch that already deployed a token must be recovered, not relaunched, or the same symbol ends up deployed twice. That distinction between "failed clean" and "failed with on-chain evidence" runs through the whole pipeline.
Where the money goes
The economic design answers the question every launchpad gets asked: who profits, and how?
The creator's supply is not held back for them to sell — all of it goes into the pool. What the creator earns is trading fees: the pool charges 1% on every swap, those fees accrue to the locked position, and the per-token splitter pays them out — 60% to the creator, 40% to the platform, enforced by the immutable contract from step 4, with the creator share readable on-chain by anyone.
This is worth dwelling on, because it inverts the usual incentive. A creator who holds a large allocation profits most by selling into early buyers. A creator paid from trading fees profits from volume over time, which is at least directionally aligned with the token being something people keep trading rather than something they exit.
The lock from step 5 is the other half of that alignment. The single most common way token buyers lose everything is not a price crash — it is the liquidity being withdrawn. Locking the position NFT with a far-future unlock date makes the pull impossible for everyone, the platform and the creator included. Fees remain collectable through the locker; the underlying liquidity does not.
The guardrails you only notice when they stop you
A few limits in the pipeline exist to keep the launchpad from being used as a spam cannon or a footgun:
- Three successful launches per creator per day, five attempts counting failures. Hitting the attempt limit before the success limit usually means something is wrong with the launch configuration, and the right move is reading the earlier errors, not retrying harder.
- One durable launch per symbol per creator. If you already have a launch with on-chain evidence for
$TICKER, a second submission is refused and pointed at recovery instead. Symbols already taken platform-wide are rejected outright. - Gas is escrowed up front. The launch sequence spends real HYPE across all eight steps, and the creator pre-funds that gas into escrow before anything runs — with the unspent remainder returned once the launch reaches a terminal state. The platform's deployer wallet deliberately holds no gas of its own.
- Provisioning is checked before your deposit is touched. Three preflight gates — the deployer wallet, the fee collector, and the on-chain contract provisioning — run before the launch claims your escrow, so a platform-side configuration problem fails the launch while your deposit is still fully reusable.
What "launched" means at the end
When the pipeline finishes, the state is: an ERC-20 owned by the creator; a pool holding the full supply; a liquidity position nobody can withdraw; a fee contract paying the creator 60% of a 1% fee on every trade, forever; and trading open to anyone on a permissionless DEX. No admin key holds the liquidity, and the platform's launch wallet has handed off everything it briefly owned.
That end state — rather than any single step — is the actual product of a launchpad. The eight steps are just the only safe order in which to assemble it.
BT365's launchpad runs on HyperEVM (chain 999), alongside token swaps and the HyperCore exchange integrations. Curious how the two sides of Hyperliquid differ? Start with HyperEVM vs HyperCore. Explore the platform or read the documentation.