An IDO launchpad runs public token sales through smart contracts and lists the token on a decentralized exchange afterward. A multichain IDO launchpad lets buyers join the same sale from several blockchains, such as Ethereum layer 2s, BNB Smart Chain and Solana. This guide covers the three main designs, how the token exists on several chains, the bridge risks, and the effort each design takes.
How an IDO launchpad works
An IDO (initial DEX offering) sale follows the same steps on every chain:
- The project applies, and the launchpad checks the team, the contracts and the token plan.
- Users register, pass KYC if the sale needs it, and receive an allocation through tiers, a lottery or a pro rata formula.
- Users send stablecoins or the chain's native coin to the sale contract during the sale window.
- A vesting contract releases the purchased tokens on a schedule.
- The project pairs part of the raise with tokens in a DEX pool and locks the pool's LP tokens.
The crypto launchpad development guide compares the sale formats and the vetting process in detail, while this page covers what changes when the same sale runs on several chains.
Why run a sale on several chains
Buyers hold their funds on many networks, so a sale on one chain asks every buyer to bridge funds first, and some buyers drop out at that step. But each added chain also adds contracts to audit, nodes and indexers to run, a pool to seed and support questions to answer, so most teams start with the two or three chains where their community already holds funds.
Three multichain launchpad designs
| Design | How it works | Advantages | Drawbacks |
|---|---|---|---|
| Independent per-chain sales | Each chain has its own sale contract with its own caps | Simple, with no link between chains | One chain can sell out while another sells only part of its supply |
| Hub with signed allocations | A backend or a home chain computes tiers and KYC, then signs a per-chain allocation for each buyer | One set of fair caps without a messaging protocol | Buyers must trust the signing backend, and its key must be well protected |
| Message-based global state | Sale contracts on each chain report contributions to a hub contract through a cross-chain messaging protocol | Global caps are enforced on-chain | Messages arrive late or fail, and the messaging layer adds its own risk |
Polkastarter is an example of the first design: its sales run on nine chains, and buyers pay into a separate sale on the chain they choose. The signed-allocation design keeps each chain's contract small and puts the global logic in one audited service. In every design, the launchpad should tell buyers where the final allocation is decided.
Cross-chain messaging options
When contracts on different chains must exchange data, a general messaging protocol carries the messages. LayerZero, Chainlink CCIP, Wormhole, Axelar and Hyperlane are the main options, and they differ in who confirms that a message is real, which chains they support and what they charge.
The messaging layer can move value, so it needs the same care as the sale contracts:
- Require several independent verifiers to confirm each message, not one.
- Limit how much value a single message can move.
- Add a pause function that a multisig controls.
The interoperability and layer 2 explainer covers how these protocols fit into a wider architecture.
How the token exists on several chains
- One native chain plus third-party bridges. The token lives on one chain, and bridges issue wrapped copies on other chains. This setup is simple, but each wrapped copy has its own pools and depends on its bridge's security.
- Lock-and-mint with an official bridge. The project names one bridge as the official route, so users see one version of the token on each chain, but that bridge becomes a single point of failure.
- Burn-and-mint frameworks. The token burns on the source chain and mints on the destination chain, so it is native on every chain. LayerZero's OFT standard, Chainlink's Cross-Chain Token standard and Wormhole's Native Token Transfers work this way. The draft xERC20 standard (ERC-7281) lets the issuer set a separate mint limit for each bridge.
Mint limits matter because bridges have lost large sums. Attackers drained the Ronin, Wormhole, Nomad and Harmony Horizon bridges in 2022, and the Multichain bridge protocol stopped working in 2023 after its operators lost control of its keys. A mint limit for each bridge stops one compromised bridge from minting unlimited tokens.
Practical problems to solve
- Identity across addresses. One KYC identity may control addresses on several chains, including Solana and other non-EVM formats, so the launchpad links those addresses so one person cannot claim a full allocation on each chain.
- Caps and refunds. The team decides whether each cap is global or per chain, and refunds should be claimable on the chain where the buyer paid.
- Stablecoin differences. The same stablecoin can have different decimals or a different issuer on another chain. USDT and USDC on BNB Smart Chain use 18 decimals, while their Ethereum versions use 6, so the sale code must convert every amount to one unit.
- Claim location. Buyers can claim on the chain they paid from, or on a chain they choose, and the app should show the default chain before the buyer pays.
- Liquidity. Pools on every chain split the liquidity, and a pool on only one chain forces buyers to bridge, so many projects seed one or two deep pools.
- Non-EVM chains. Solana, Cardano and Polkadot-native deployments need separate code and separate audits, which the Polkadot and Cardano guides cover.
Build effort and cost drivers
The following figures are reasoned estimates. A launchpad that already uses signed allocations needs a few weeks and an audit review to add a second and a third EVM chain, while a message-based design across EVM chains takes three to six months for three or four engineers, including audits. Each non-EVM chain is close to a separate build, because the contracts, wallets and indexers all change.
The Ethereum launchpad guide and the BSC launchpad guide cover the single-chain contracts, and the multichain blockchain development guide covers general multichain architecture.
Frequently asked questions
What is an IDO launchpad?
An IDO launchpad is a platform that runs token sales through smart contracts and lists the token on a decentralized exchange after the sale. It handles registration, allocation, payment, vesting and the first DEX pool.
Does a multichain IDO need a cross-chain messaging protocol?
Not always. A well-secured backend can sign allocations that enforce one set of caps, while each chain runs its own independent contract.
What is the biggest risk in a multichain launch?
The biggest risk is the bridge or messaging layer that moves tokens or messages, and a limit on the value each route can move keeps the loss small if one route fails.
Should the token be native on every chain?
Only if the project can secure every mint path. A burn-and-mint design with a mint limit per bridge is safer than a design that gives any bridge unlimited minting rights.