An NFT launchpad is a platform that runs primary mints for many creators: it vets projects, deploys or configures their collection contracts, manages allowlists and mint phases, handles the reveal, and gives collectors one trusted place to mint. Building one is mostly about getting mint mechanics and project vetting right; the storefront is the easy part.
This guide is for founders and product teams deciding whether to build a launchpad, use a hosted one, or license a white-label product. It explains the mechanics, the components, a realistic build process, cost drivers, and what to ask any team you hire.
What a launchpad is, and what it is not
A launchpad handles the primary sale: the moment a collection is first minted. A marketplace handles secondary sales afterward. Many products do both (Magic Eden and OpenSea both run launch programs alongside trading), but they are different systems with different risks.
It is also different from a token launchpad. An IDO or IGO launchpad sells fungible tokens, usually with vesting and tiered allocations; see our token launchpad guide and IGO launchpad guide for those. An NFT launchpad sells unique or semi-fungible items, and its hard problems are fair access, randomness and reveal integrity.
If your focus is metaverse items such as land or avatars, the NFT metaverse launchpad guide covers that variant; if you only need a single collection's mint site, you may not need a launchpad at all.
Who launchpads serve
The mechanics are shared, but the audience shapes product decisions:
- Artists want curation, an editorial presentation and fair access for collectors.
- Musicians often need editions, token-gated perks such as unreleased tracks, and split payments to collaborators. See our guide to NFT marketplaces for music.
- Game studios launch item or character collections, usually needing integration with game accounts.
- Brands and creators with audiences need card payments and email-based wallets, because most of their fans do not hold crypto.
- Film and media projects use editions to presell access or collectibles; rights clearance becomes a real workload.
Core mechanics
Mint phases and allowlists
Most launches run in phases: a team reserve, one or more allowlist phases, and a public phase, each with its own price, per-wallet limit and time window. Allowlists are usually implemented as a Merkle root stored in the contract. Each allowlisted wallet submits a Merkle proof when minting; the contract verifies it without storing every address on-chain. An alternative is a server-signed mint voucher, which is more flexible but makes your backend key a critical secret.
Gas-efficient minting
Batch minting in standard ERC-721 is expensive. ERC-721A, popularized by Azuki, makes minting several tokens in one transaction cost close to minting one, by deferring ownership writes. ERC-1155 suits editions where many copies are identical. The launchpad should offer templates for both.
Randomness and reveal
For generative collections, nobody should know which token is rare before mint ends, or bots will snipe rare items. The standard pattern:
- Publish a provenance hash of the full ordered metadata before mint.
- Mint with placeholder metadata.
- After mint, obtain a random offset from a verifiable source (for example Chainlink VRF) and apply it to the token-to-metadata mapping.
- Reveal by switching the base URI to the real, content-addressed metadata.
Our MekaVerse teardown shows what happens when collectors suspect a reveal was not fair.
Bot and Sybil resistance
Popular mints attract bots. Options include per-wallet limits (easily bypassed with many wallets), allowlists earned through community activity, signed vouchers issued after a captcha or account check, raffles instead of first-come-first-served, and Dutch auctions that make sniping less profitable.
Payments and payouts
Proceeds should split automatically between the creator and the launchpad, ideally through a splitter contract creators can verify. Card payments require a regulated payment or on-ramp partner who mints on the buyer's behalf. Royalty settings (EIP-2981) are configured at deployment, with clear disclosure of whether they are enforced anywhere.
Creator vetting
A launchpad's reputation is the sum of its launches. Vetting typically covers team identity (KYC for project owners), rights to the art or IP, a delivery plan for any promised utility, and a check of the contract configuration. A launchpad that lists rug pulls loses its collectors fast.
Components
| Component | Purpose | Notes |
|---|---|---|
| Contract templates | ERC-721A, ERC-1155, editions, with phases and allowlists | Audited once, deployed as clones per project |
| Factory / deployer | Deploys a project's contract with its parameters | Creators should own the contract, not the launchpad |
| Project admin | Upload art, set phases, manage allowlists | Validation to catch misconfigured prices or supplies |
| Metadata pipeline | Generate, pin and reveal metadata | IPFS or Arweave; provenance hash before mint |
| Mint page | Countdown, phase status, wallet connect, mint | Must handle traffic spikes and RPC limits |
| Allowlist engine | Collect, dedupe and export allowlists, generate Merkle roots | Often integrated with social or community tools |
| Payments | Crypto, plus optional card checkout | Card adds KYC and chargeback handling |
| Vetting and review | KYC, IP checks, contract review | A process plus tooling |
| Analytics | Mint progress, holder distribution, revenue | Useful for creators and for spotting bot activity |
Chain choice
On EVM chains (Ethereum, Base, Polygon, Arbitrum and others) the same contract templates deploy everywhere, so supporting several is relatively cheap once indexing is set up. Solana launches typically use Metaplex's tooling (Candy Machine and its successors) and its compressed NFTs for very large, cheap collections, which is a different stack entirely. Bitcoin Ordinals inscriptions are another separate world; see our guide to Ordinals marketplaces. Start with one ecosystem.
The build process
- Define the launch model. Curated or self-serve, which chains, which audiences, card payments or not, and your fee model.
- Write and audit contract templates. Phases, allowlists, ERC-721A or ERC-1155, royalty info, withdraw logic, reveal. Every launch inherits these, so a bug multiplies. Get an external audit.
- Build the factory and project admin. Include guards against common creator mistakes: wrong decimals, unlimited supply, missing withdraw address.
- Build the metadata and reveal pipeline with provenance hashes and verifiable randomness.
- Build the mint page and load-test it. Mints are traffic spikes; plan RPC capacity and caching.
- Set up vetting. KYC provider, IP checklist, contract review checklist, written listing criteria.
- Run a pilot launch with a friendly creator on testnet, then mainnet with low supply.
- Add secondary trading only if needed. Many launchpads simply link to existing marketplaces.
Cost and timeline drivers
As a reasoned estimate: a curated, single-chain EVM launchpad with audited templates, an admin, mint pages and crypto-only payments is roughly a three to five month project for a team of one smart contract engineer, two full-stack engineers, a designer and part-time QA/DevOps. What pushes cost up:
- Self-serve creation (anyone can launch) needs much more validation, moderation and support tooling than a curated model.
- Card payments and embedded wallets add a payments integration, KYC flows and support load.
- Non-EVM chains roughly double contract and indexing work per ecosystem.
- Secondary marketplace turns the project into a marketplace build as well.
- Audits are separate and scale with contract complexity.
Build, buy or white-label
| Option | Good for | Trade-offs |
|---|---|---|
| Use an existing launchpad | A single creator or brand doing one or a few drops | Their fees, rules and branding; no platform of your own |
| No-code mint tools | Simple editions and small collections | Limited customization of phases, payments and reveal |
| White-label launchpad | A business that wants its own branded platform quickly | Check who owns the contracts, upgrade rights, audit history and lock-in |
| Custom build | A launchpad as a core business with specific mechanics | Highest cost and longest timeline; full control |
Questions to ask a vendor or team
- Which audits have your contract templates had, by whom, and can I read the reports?
- Who owns each deployed collection contract, and can the launchpad change it after deployment?
- How is randomness for reveals generated, and can collectors verify it?
- How does the mint page behave under a traffic spike? What RPC and caching setup do you use?
- What happens to creator funds between mint and payout?
- Is the code mine at the end, and under what license?
Frequently asked questions
Do I need a launchpad to launch one NFT collection?
No. A single collection only needs an audited contract and a mint page. A launchpad is worth building when you plan to host many launches for other creators.
What is the difference between an NFT launchpad and a minting platform?
A minting platform lets anyone create NFTs on demand. A launchpad runs scheduled, phased primary sales with vetting and allowlists. Our minting platform guide covers the self-serve tool.
Should the launchpad own the collection contracts?
Creators and collectors generally prefer that the creator owns the contract. If the launchpad keeps admin rights, disclose them and limit what they can do.
How do launchpads make money?
Usually a percentage of primary sales, sometimes a listing fee, and occasionally a share of secondary royalties. Charging projects to list without vetting them tends to damage the platform's reputation.
How do I stop bots from taking the whole mint?
Combine allowlists, signed mint vouchers issued after a human check, per-wallet limits and, for high-demand drops, raffles or Dutch auctions. No single measure is enough.
Can one launchpad support Ethereum and Solana?
Yes, but they are separate stacks: different contracts (or programs), tooling, wallets and indexers. Launch on one first and add the other once the first is stable.