How can a new token have liquidity when nobody put money in the pool?
There is a small paradox at the bottom of every launchpad: a token that did not exist an hour ago is trading, right now, against real money — and nobody funded the pool. No treasury seeded it, no market maker was hired, and the creator didn't deposit a cent of the quote asset.
The mechanism that makes this work is single-sided concentrated liquidity, and it is genuinely elegant. It also has one failure mode subtle enough that you can write a plausible-looking launchpad that strands tokens permanently, and the difference between the two is a single rounding decision. BT365's launchpad mints these positions on HyperEVM; both the elegance and the trap below are from that implementation.
Two-sided pools, one-sided positions
In a classic constant-product pool (Uniswap V2 and its forks), liquidity is always both assets at once, spread across every price from zero to infinity. To launch a token there, someone must deposit both sides — the token and the quote asset — and the amount of quote capital deposited hard-limits how much depth the market has. This is why old-style launches needed a funded treasury or a presale: the pool eats real money before the first trade.
Concentrated liquidity (Uniswap V3 and its forks — on HyperEVM, that includes HyperSwap) changed the geometry. A position covers a chosen price range, and the composition of the position depends on where the current price sits relative to that range:
- Price below the range → the position is 100% the token.
- Price inside the range → a mix of both.
- Price above the range → 100% the quote asset.
That first case is the launchpad trick. Put the entire token supply in a range that starts just above the current price and extends to the top of the price spectrum, and the position is valid while containing zero quote asset. The pool is fully armed with sell-side inventory and needs no money at all.
The first buyer funds the pool
Once trading opens, the mechanics run themselves. The first buy pushes the price up into the bottom of the range, where the position starts selling tokens and accumulating WHYPE. Every subsequent buy walks the price further up the curve, converting more of the position from token to quote asset; sells walk it back down. The pool's WHYPE side is built entirely out of buyers' money, trade by trade.
Seen this way, a single-sided launch is a fully collateralized, continuously-priced offering: the supply sits on a fixed curve, and the market decides how far up it to climb. Nobody had to guess a fair price to seed the pool, because the starting price is simply the bottom of the range — and on our launches the position spans the full usable range, so there is no upper price at which the market runs out of curve.
It also explains something people find suspicious until they see the mechanism: the creator putting "no money in" is not a red flag here. There is no quote capital to put in. What matters instead is what happens to the position afterward — which is why the position NFT is locked in an on-chain locker immediately after minting. The pool's WHYPE side is the buyers' money, and the lock is what makes it unwithdrawable by the creator or the platform.
The one-tick trap
Now the failure mode, because it is instructive about how launch code has to think.
Concentrated-liquidity pools quantize prices into ticks, and positions may only start and end on ticks aligned to the pool's tick spacing (200, at the 1% fee tier we use). So launch code must round the range's lower boundary to an aligned tick — and the obvious choice is to round up to the nearest aligned tick above the current price.
The bug: if the pool's current tick happens to already be aligned, "round up to the nearest" returns the current tick itself. The range now starts exactly at the live price — which puts the live price inside the range — and a mint inside the range requires both assets. The launch is offering zero WHYPE. The mint reverts.
On an established pool this would be a nuisance: the price wobbles one tick and the retry succeeds. On a freshly created pool it is permanent. The pool has no liquidity yet, so no trade can ever occur, so the price can never move off that tick — and every retry fails identically, forever. The launch is stranded not by a transient error but by a rounding function, and nothing in the revert message says so.
The fix is one word of specification: the boundary must be strictly above the current tick, never equal to it. When the current tick is aligned, correct code steps up one full spacing rather than staying put. Our implementation encodes exactly that rule, with a comment explaining why — because the buggy version passes every test in which the starting tick happens to be unaligned, which is nearly all of them.
It is a good miniature of launch engineering generally: the interesting failures are not the ones that revert loudly on the happy path, but the ones that are legal, quiet, and permanent.
Part of our series on Hyperliquid's EVM side — see HyperEVM vs HyperCore, what happens during a launch, and why launches escrow gas up front. Explore the platform or read the documentation.