Skip to main content
Open app

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

· 8 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. Sometimes it is a gas escrow — not a fee at all, but a deposit against gas the platform is about to spend on your behalf. And sometimes the right answer is to design the deposit out of existence.

BT365's HyperEVM launchpad has been on both sides of that line. Our first-generation launcher took a 0.1 HYPE gas escrow, because our own wallet executed the launch. Our current launcher takes no deposit, because you execute it. This article is the reasoning behind both — which is really a tour of the ways prepaid gas goes wrong, and of why the cleanest fix is not a better escrow.

The problem: whoever signs the launch needs the gas first​

A launch that the platform executes for you is not one transaction. In our first generation it was eight: deploy the token, create the pool, mint the liquidity position, deploy the fee splitter, lock the position, attest the lock, open trading, hand over ownership. Each spent real HYPE from the platform's deployer wallet, and that wallet had to hold enough 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 we shipped first: each launch funds itself. The creator sent 0.1 HYPE to the deployer wallet before the launch could start, the launch spent from exactly that, and the wallet held approximately nothing between launches. No float to exhaust, no honeypot to raid.

What a gas escrow has to get right​

An escrow is only better than a fee if the rules around it are precise. Ours were, and they are worth recording because they are the questions to ask any launchpad that still takes one:

  • Verified before anything is committed. The deposit was checked for the right sender, the right recipient, a successful receipt, the full amount, and never having funded another launch — and the platform's own readiness checks ran before the deposit was claimed, so a platform-side problem failed the launch while the deposit was still whole and reusable.
  • A fixed floor, not a live quote. The amount you were asked for was the amount you saw, not a number that moved while your transfer confirmed. If the live gas estimate ever exceeded the floor, launches refused to start rather than starting something they might not finish.
  • Measured, not estimated. Settlement read the actual gas spent from the launch's own transaction receipts and refunded the difference on-chain, with its own transaction hash. A full launch actually spent around 0.002 HYPE, so most of the deposit came back.
  • Honest about the awkward cases. A clean failure refunded everything minus the refund's own gas. A remainder smaller than the gas it would take to send it was recorded as dust and not sent. A launch that failed partway with real on-chain evidence waited for reconciliation before refunding, because refunding before the spend is final is how a platform pays the same money twice.

All of that machinery exists to solve one problem: the platform is spending on the creator's behalf. Which raises the question of whether it should be.

The current answer: there is no deposit, because you sign​

Our current HyperEVM launcher is a bonding-curve launch that the creator signs and broadcasts from their own wallet. The backend prepares the launch and signs an authorization over its exact terms — name, ticker, metadata, opening buy, fee, a ten-minute deadline and a digest of the launch economics — but it never broadcasts anything and never spends anything. You send one transaction to the launch router; it deploys the token and its curve, pins the economics, and makes your opening buy if you asked for one. It fits comfortably in a HyperEVM small block, and the gas is yours, paid the same way you pay for any other transaction.

That dissolves the deposit problem rather than solving it:

  • No float, no honeypot. The platform's wallet holds no gas for launches and never touches the token, the supply or the pool. There is nothing to run dry and nothing to drain.
  • No escrow to verify. The transaction carries exactly what it needs — the opening buy, if any, plus the platform's ordinary 0.35% routing fee on it — and the router refuses a transaction whose value does not match. There is no launch fee.
  • No partial spend to reconcile. The launch is atomic. If anything in it fails, the whole transaction reverts, the opening buy and the fee are never taken, and only the gas is gone. There is no "failed partway with on-chain evidence" state to settle.
  • No refund to measure. Nothing was prepaid, so nothing needs returning. The one refund in the system is on the curve itself: the buy that crosses the graduation threshold is filled up to the line and refunded the rest.

What remains is the class of problem a signature cannot remove: your transaction landed but your browser lost the confirmation. A second submission for the same ticker is refused and reconciled against the chain — a launch that already exists is recovered, never relaunched, because the alternative is the same symbol deployed twice.

The question to ask any launchpad​

None of this machinery is visible on a launch form, which is rather the point. If a launchpad asks for money before launching, 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? And the sharpest one: why is the platform's wallet signing my launch at all?

A launchpad that can answer those precisely has thought about the ways prepaid money goes wrong. One that has arranged for you to sign the launch yourself has thought about it and concluded the money should never leave your wallet in the first place.

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