Skip to main content

Why does a launchpad ask for a deposit before launching your token?

· 7 min read
BT365 Team
BlockTrader365

Every launchpad has a moment where it asks for money before doing anything, and it reads as a toll booth. Sometimes it is one. But there is a version of that deposit which is not a fee at all, and the difference is worth understanding before you pay either kind.

On BT365's HyperEVM launchpad the deposit is a gas escrow: 0.1 HYPE, sent by the creator to the launch wallet before the launch may start, measured against actual spend afterward, remainder returned. This article is the reasoning behind each of those clauses — which is really a tour of the ways prepaid gas can go wrong.

The problem: eight transactions need gas before the first one signs​

A token launch on HyperEVM is not one transaction. Deploying the token, creating the pool, minting the liquidity position, deploying the fee splitter, locking the position, opening trading, handing over ownership — each is a real transaction spending real HYPE, and the wallet signing them has to hold enough gas for the whole sequence before step one.

Someone has to put that gas there. The obvious answer — the platform keeps a funded wallet and eats the gas as a cost of business — is how most systems start, and it has two failure modes that only show up later. The float runs dry at the worst moment, silently, and every launch starts failing on an empty tank. And the funded wallet becomes a honeypot: a standing balance that a leaked key or a buggy code path can drain, belonging to no specific user, watched by nobody in particular.

The alternative: each launch funds itself. The creator sends the gas money to the launch wallet before their launch runs, the launch spends from exactly that, and the wallet holds approximately nothing between launches. No float to exhaust, no honeypot to raid. Our deployer wallet's near-zero balance is not an operational embarrassment — it is the design.

Why a fixed amount, verified before anything runs​

The escrow is a deterministic floor — 0.1 HYPE — rather than a live gas quote, so the amount you are asked to pay is the amount that was quoted when you looked, not a number that moved while your transaction confirmed. A live estimate is computed alongside it (a full launch currently runs around 0.002 HYPE), and if the estimate ever exceeds the floor, the chain reports itself unavailable and launches refuse to start — the system fails closed rather than starting launches it might not be able to finish.

Verification is deliberately fussy, and each rejection is distinct because each means something different:

  • Not visible yet — a transient state; the deposit may simply be unconfirmed, and retrying is correct.
  • Wrong sender, wrong recipient, or reverted — conclusive; this transaction can never fund a launch.
  • Below the floor — conclusive, and the deposit becomes an orphan that an operator refunds; topping it up with a second transfer would make attribution ambiguous.
  • Already used by another launch — a deposit funds exactly one launch, ever. Without that rule, one payment hash could be replayed across many launches.

The ordering matters as much as the checks. The platform's own preflight gates — is the deployer wallet ready, is the fee collector configured, are the on-chain contracts provisioned — all run before your deposit is claimed. A platform-side problem fails your launch while your deposit is still whole and reusable. Your money is only committed once everything that could be checked without spending has passed.

The refund is measured, not estimated​

When a launch reaches a terminal state, settlement reads the actual gas spent from the launch's own transaction receipts — not from the original estimate — and returns the difference to the creator. Deposit minus measured spend, as a real on-chain transfer, recorded with its own transaction hash.

The edge cases are where you can tell whether a system was designed or improvised:

  • Success: unspent remainder refunded. With a 0.1 HYPE floor and roughly 0.002 HYPE of real spend, most of the deposit comes back.
  • Clean failure (nothing durable made it on-chain): the whole escrow, minus the refund transaction's own gas, goes back.
  • Dust: if the remainder is worth less than the gas the refund transfer itself would burn, sending it would destroy value to move it. It is recorded as dust and not sent.
  • Failure partway, with real on-chain evidence: settlement deliberately waits. The launch enters recovery, and refunds only happen after an operator reconciles what was actually spent — because refunding before the spend is final is how a platform pays the same money twice.
  • Shortfall: if measured spend somehow exceeds the escrow, the gap is recorded and surfaced rather than silently absorbed, because a recurring shortfall means the floor is mispriced and should be raised deliberately, not eaten quietly.

The question to ask any launchpad​

None of this machinery is visible on the launch form, which is rather the point — the visible part of every deposit is identical: send us money first. The distinguishing questions live underneath. Is the deposit a fee or an escrow? Is it verified before or after the platform commits your launch? What happens to the remainder — and is the answer measured from receipts or asserted from an estimate?

A launchpad that can answer those precisely has thought about the ways prepaid money goes wrong. A launchpad that answers "it's just the launch fee" has answered a different question than the one you asked.

Part of our series on Hyperliquid's EVM side — see HyperEVM vs HyperCore and what actually happens during a launch. Explore the platform or read the documentation.