Design Token Launchpad

Problem Statement: IDO Launchpad at Exchange Scale

A token launchpad is a primary-sale orchestrator: projects configure their tokenomics (price, caps, vesting), investors commit stablecoins during a bounded sale window, and the platform settles allocations — pro-rata or first-come-first-served — with vesting cliffs enforced on-chain. This is the engine behind CoinList, DAO Maker, Polkastarter, and Binance Launchpad.

Why it is hard: it is a financial system that goes from 0 to peak in seconds. A hyped sale opens and tens of thousands of investors race to commit before the hard cap fills — a hot L1 IDO can hit a $42M cap in under 90 seconds. The system must enforce the cap exactly (one dollar over is a sev-1 financial incident), never double-debit a retrying client, and show a live progress bar that doesn't lie — all under a thundering-herd load (~350 commit RPS sustained, 18k commits in the first 90s) that arrives with zero ramp.

The core tension: fast UX vs on-chain truth. Investors expect sub-second commit confirmation, but blockchain finality takes seconds to minutes. So a real launchpad runs a custodial commit ledger (a fast, serializable database that accepts commits and enforces the cap) reconciled against on-chain settlement (the slow, authoritative truth). The authoritative raised amount is the sum of confirmed commitments plus the on-chain SalePool.raised() at the finalize block; the UI counter is a hint bounded to ~2s staleness.

The defining invariants. (1) Exact cap enforcement — accepted commitments never exceed the hard cap, even when two regions race the same wallet. (2) Exactly-once commits — a client retry with the same idempotency key returns the original row, never a second debit. (3) Deterministic, auditable settlement — final allocations follow a reproducible rule and are published as a Merkle root so anyone can verify their own allocation.

Scale to anchor on: $42M hard cap, 18k commits in T+90s, 350 commit RPS peak, p95 commit < 800ms. The hard parts aren't storage — they are serializable cap enforcement under a thundering herd, exactly-once money movement, and honest reconciliation between the custodial ledger and the chain. Get any of those wrong and you either oversell the cap or hand someone else's allocation away — both unrecoverable in public.