Every trading interface shows you a price. Almost none of them tells you what your order will actually pay.

The number on screen is the best price for the first unit. A market order of any real size does not trade at the best price; it trades at the best price, then the next one, then the next, until the size is filled. The cost of that walk is slippage, and the only honest way to quote it in advance is to do the walk before the order goes out.

From the outside, a token launch is a form: name, symbol, logo, submit. From the inside, it is a set of on-chain rules that decide who can buy when, at what price, where the fees go, and what nobody is allowed to touch — and every rule exists because of a specific way launches go wrong without it.

BT365 runs a token launchpad on HyperEVM (Hyperliquid's EVM chain, ID 999). Our first generation was an eight-step pipeline the platform's own wallet executed on the creator's behalf: deploy, create a pool, mint a single-sided position, lock it, hand ownership over. We have since replaced it with a bonding-curve launch the creator signs themselves, and this article describes that current design step by step. Tokens launched on the earlier pipeline keep running as they were.

Hyperliquid gets described as "an exchange" and "a blockchain" in the same breath, and both descriptions are correct — which is exactly what confuses people. It is one chain running two execution surfaces, and which surface an asset lives on decides how you trade it, what you actually hold, and what can go wrong.

BT365 is integrated against both sides — perps, spot and HIP-4 outcome markets on HyperCore, and token swaps plus a token launchpad on HyperEVM — so this is the distinction as it looks from having built against each, not from a diagram.

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.

There are two ways to make that work, and BT365's HyperEVM launchpad has shipped both. Our first generation minted the whole supply as a single-sided concentrated-liquidity position. Our current one mints it into a bonding curve with a virtual reserve, and only creates a pool once the curve has raised real money. Each is genuinely elegant, and each has a failure mode subtle enough that you can write a plausible-looking launchpad that strands tokens permanently. Both the elegance and the traps below are from our own implementations.

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.

Suppose an agent has been asked to buy a token, and your service can do that. How does it find out?

Not from your homepage — it cannot reliably read a JavaScript app, and marketing copy does not tell it which endpoint to call. Not from your docs site, which assumes a reader who already decided to integrate. If discovery depends on a human having read something and then written code, your service is not agent-accessible; it is human-accessible with an API attached.

An AI agent trying to use a paid API hits a wall that has nothing to do with intelligence. It cannot sign up.

Signup assumes a person: an email to confirm, a card with a billing address, sometimes a captcha or an SMS. An agent has none of that. What it can have is a wallet — and if a service is willing to be paid by wallet, the entire onboarding problem collapses into a single HTTP exchange.

From the outside, a prediction market is the same thing everywhere. You pay something under a dollar for a claim on an outcome, and if the outcome happens you collect a dollar.

The mechanics underneath are not the same, and the differences are not cosmetic — they determine what you actually own, what it costs to get in and out, and which specific things can go wrong. BT365 runs both Polymarket and Hyperliquid's HIP-4 outcome markets, so this is a comparison from having implemented against each rather than from reading their docs.

Most order-handling code is written as if there are two outcomes: the order worked, or it didn't.

There is a third, it is more common than people expect, and it is the one that actually costs money. You send an order. The connection stalls, or the venue returns a shape you don't recognise, or a gateway hands back a 502. You now do not know whether you have a position.

If you have integrated one exchange API you have integrated most of them. The signing scheme is near-universal: a key id, a secret, an HMAC over some canonical form of the request.

What varies — and what almost no documentation explains — is exactly which bytes go into the signature, what else the server checks, and in what order. Those details are the security. The HMAC is the easy part.