Design a Token Launchpad (IDO/ICO Platform)

Problem statement

Design a token launchpad platform where crypto projects create a token sale (IDO or ICO), define token supply and a sale model, and participants commit funds to receive an allocation, subject to KYC gating, vesting schedules, and real-time sale progress reporting. The platform must let a project configure a sale, open participation at a precise moment, accept commitments from potentially tens of thousands of wallets within minutes, compute each wallet's allocation deterministically, distribute tokens fairly, and enforce unlock schedules after the token generation event (TGE).

This is not a conventional web backend. Three properties make it distinctive. First, the load profile is a thundering herd: a hot sale compresses weeks of normal traffic into the first sixty seconds after participation opens. Second, money is moving on-chain, so correctness is not a nice-to-have. A double-credited allocation, an over-minted distribution, or a reorg-reversed deposit that was already counted against the cap is a financial loss and a reputational catastrophe. Third, fairness is a first-class product property. If sophisticated bots with direct RPC access can front-run retail participants, the launchpad loses its reason to exist.

The design therefore separates three planes that a naive design would merge. The participation plane must survive a stampede without double-allocating. The settlement plane must reconcile off-chain intent with on-chain confirmation and reorgs. The fairness plane must make allocation outcome deterministic and resistant to ordering games, MEV, and sybil wallets.

Why the problem is distinctive

An e-commerce checkout can retry a failed payment and restock inventory. A token sale cannot easily retry once the cap is hit and allocations are computed, because participants have already transferred value and the allocation snapshot is a social contract. The design separates mission success (sale completes, tokens distributed, vesting enforced) from participation correctness (no wallet is credited more than its committed funds justify, no allocation exceeds the cap, no double-spend is honored). Mission success is an eventually-progressing workflow. Participation correctness is an invariant.

A strong answer keeps the off-chain application layer and the on-chain settlement layer cleanly separated, and it is explicit about which decisions happen where. Whitelist eligibility, allocation math, vesting schedules, and cap enforcement can live in a deterministic smart contract. KYC verification, user accounts, project due diligence, dashboards, and notifications live off-chain. The boundary between the two is the load-bearing wall of the whole architecture.

Public operating baseline versus design assumptions

Public evidence establishes that the category is operationally real and large. CoinList ran the Filecoin raise, which collected over $200M from participants in 2020 using a multi-round, KYC-gated, compliant sale structure. Polkastarter publicly reports having hosted well over 100 IDOs across Ethereum, Binance Smart Chain, and Polkadot, using a staking-and-lottery pool model. DAO Maker publicly describes its Strong Holder Offering (SHO) model with staking tiers and a refundable vesting mechanism called DYCO. These are cited public figures, not requirements for our fictional system.

For capacity planning, this answer explicitly assumes a mature multi-chain launchpad with 500,000 registered users, 50,000 simultaneously active during a major sale, 10,000 participation requests per second at the drop moment, and a ten-times event peak. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold, not a claim about any company's private architecture.

The four architectural planes

1. Participation plane: rate-limited ingress, idempotent commitment intake, queueing, and allocation computation.
2. Settlement plane: deposit ingestion, blockchain confirmation tracking, reorg handling, and cap accounting.
3. Fairness plane: whitelist merkle proofs, sybil resistance, anti-front-running ordering, and deterministic allocation.
4. Distribution plane: token claim contracts, vesting schedules, cliff and linear unlock, and treasury custody.

A strong interview answer keeps these planes separate. It allows the participation plane to degrade (show a queue, slow the dashboard) without weakening the settlement plane, and it lets the fairness plane reject a sophisticated attacker without silently changing the validated sale rules.