How the Core rail works

Fund a token before it exists.
Own the float when the order book opens.

A Core launch is a crowdfund whose funders ARE the early buyers. Their pooled USDC pays for the scarce HIP-1 deploy slot and the opening liquidity; in return they receive the genesis float — earlier money on a published bonus. No bonding curve, no bundles, no insider round: everyone trades the same HyperCore order book from second one.

01The big picture — two chains, one handoff

Trustless money lives on HyperEVM. Token creation can ONLY happen on HyperCore (no smart contract can call spotDeploy — it's an off-chain signed action). The bridge between them is the operator, who is never trusted with the pool: it fronts its own capital and gets reimbursed only after the chain itself proves the deploy.

trustless / on-chainoperator (bonded, verifiable)

The funders' USDC never leaves the vault until step ⑥ passes. If the raise fails, the operator vanishes, or the platform fails the deploy during the challenge window — every path ends in refunds (plus the operator's slashed bond when it misbehaved after proving).

02Earlier money, better rate — the bonus curve

Commits earn points on a continuous linear decay: 1.25× per USDC when the raise bar is empty, sliding to 1.00× when full. Your commit integrates the curve across its own span, so splitting commits or wallets changes nothing. At genesis the fixed funder pool is divided by points — pure redistribution, supply always reconciles.

It rhymes with a bonding curve (earlier = cheaper) but strips the pathology: no selling during the raise (nothing to snipe and flip), the early edge is capped at +25%, and price discovery happens where it should — on the order book after genesis.

Delivery is simultaneous for everyone. Nobody trades early; the only asymmetry is who took funding risk, and that premium is published before the raise opens.

03The vault lifecycle — every road ends safe

Refund-XOR-reimburse is structural. A vault that has refunded anyone can never pay the operator; a vault that reimbursed can never enable refunds. The contract's invariant suite fuzzes this thousands of ways — it can't desync.

04The deploy auction — why launches are scarce

HyperCore allows roughly one new token per 31-hour window, network-wide. The right to deploy is sold in a Dutch auction paid in HYPE: price starts at 2× the last winner and decays linearly to the 500 floor. This is the moat — no 100k-coins-per-day firehose, one launch everyone watches.

05Genesis — the supply must balance to the wei

After winning the slot, the relayer walks the 5-step deploy. The critical moment is genesis: HyperCore demands that max supply equals the exact sum of every credit — our planner refuses to run unless it balances.

06The book at open — startPx is the keystone

HIP-2 "Hyperliquidity" is a protocol-native market maker: a ladder of orders 0.3% apart, refreshed every ~3s, no operator needed. The open price is set at a small premium over the funders' blended cost basis: early funders open in profit, late funders near break-even, and the public still has room to buy.

07Names are NOT unique — identity is the token index

A sharp edge most people miss: HyperCore enforces no uniqueness on tickers. Anyone can deploy another token called the same thing. Identity on Core is the token index (and tokenId) — never the name.

"Then what is the auction even selling?" — not the name. The slot. The auction prices the right to add a new asset to HyperCore at all (~one per 31h, network-wide): a canonical order book, main-UI visibility, HIP-2 liquidity, the deployer fee stream. The name is just metadata. And that's exactly why squatting is rare in practice — copying your ticker costs the squatter their own 500+ HYPE auction win and a whole network window, the most expensive shitpost on the chain. The scarcity IS the anti-spam; uniqueness doesn't need enforcing when duplication costs ~$29k a pop.

What our system does about it

Plan-time collision scan — the relayer queries spotMeta and warns if your ticker already exists before any auction money moves.
Proof pins the deployer — the vault verifies tokenInfo(index).deployer == operator AND name AND decimals AND fee-share ceiling together. An impostor token with your name fails instantly — it has the wrong deployer.
UI shows the index — once live, cards display the token index + spot pair, the only unforgeable handle.

What nobody can prevent

Someone deploying a same-name token in a different auction window (squatting/confusion). Protocol-level — true for every launch on Hyperliquid.
Mitigation is social: announce the official token index at genesis; the vault's on-chain record IS the canonical pointer.

08Who can steal what? (the honest table)

actor	attack	outcome
Operator runs away pre-deploy	never had the pool	funders refund in full — money never left escrow
Operator deploys wrong token/params	fails on-chain checks	proof reverts; no reimbursement possible
Operator shorts allocations subtly	platform fails it in the 12-48h window	refunds + the operator's slashed 100% bond split pro-rata to funders
Platform tries to take the raise	no such function exists	platform's only lever is funder-favorable (failDeploy → refunds)
Whale games the bonus	splits commits/wallets	changes nothing — the curve integrates per-span, split-invariant

Residual trust, stated plainly: the operator executes the deploy honestly enough to pass the objective checks, and the platform stays live to adjudicate the challenge window. Both are bonded/visible — neither ever custodies the pool.

HyperPad · Core rail mechanics · unaudited — verify everything on-chain · back to the app