What modules does an IDO launchpad need?
An IDO launchpad is a set of modules, not a single contract, and IDO launchpad development means building or assembling all of them. The core modules are the sale engine, compliance controls, the token claim portal, vesting, multi-chain deployment, and the fee mechanism, with a front end binding them into one branded experience. Each handles a distinct part of the sale lifecycle, and each that moves funds needs to be audited before real money touches it.
Thinking in modules matters because it is how cost, risk and the build-versus-buy decision break down. You can build some modules and buy others, but every module you build adds development time and a slice of audit scope. The sections below cover what each module does and where building it yourself is and is not worth it.
The sale engine
The sale engine is the heart of an IDO launchpad: it accepts contributions, enforces caps and contribution limits, handles oversubscription, computes allocations, and issues on-chain refunds for excess. This is the module that actually runs the raise, and it has to get the accounting exactly right under load, because a bug here means lost or misallocated funds.
The hard parts are oversubscription and refunds. When a sale is oversubscribed, the engine must allocate fairly (weighted or pro-rata) and return excess contributions on-chain, all verifiable by participants. Getting this right is non-trivial, which is why a proven sale engine is worth more than a freshly written one.
Compliance: KYC, allowlist and geo
The compliance module enforces who is allowed to participate, and it must fail closed in the contract rather than just hiding options in the interface. That means KYC verification where required, an allowlist of approved wallets, and geo restrictions for excluded jurisdictions, all kept in sync between the front end and the chain. If eligibility is only enforced in the UI, a user can bypass it by calling the contract directly.
This module is where regulatory risk concentrates, so the standard is strict: an ineligible wallet should have its transaction reverted by the contract, not merely greyed out on screen. Saleium's compliance gates, including US-person exclusion, KYC and geo-gating, are built to fail closed.
Distribution: claim portal and vesting
The distribution modules deliver tokens after the sale, and they carry the most post-sale risk because they release real value to many wallets. The two pieces are the token claim portal, which lets eligible holders claim their allocation safely by Merkle proof or signature, and token vesting, which releases allocations gradually on a schedule.
These deserve the most scrutiny in IDO launchpad development. A claim contract needs fail-closed eligibility, double-claim protection and audited transfer logic; a vesting contract needs correct unlock math enforced on-chain. Because the failure modes here are expensive and public, reusing audited, battle-tested distribution code is where buying beats building most clearly.
Multi-chain deployment
The deployment module lets you launch the same audited contracts on whichever chain your community uses. In 2026 this is table stakes, because liquidity and holders are spread across multiple EVM networks, and forcing contributors to bridge adds friction that costs you participation. The module handles per-chain configuration, addresses and RPC so one platform serves all supported networks.
Building robust multi-chain support is a major cost driver in custom development, since each chain adds testing and configuration surface. Saleium ships it across five EVM chains (BNB Chain, Polygon, Base, Arbitrum and Avalanche), with other EVM chains on request.
Fees and treasury
The fee module governs how the platform and the project take their cut, and the best practice is to stamp the fee immutably into the contract at deploy. An immutable fee means the rate cannot be raised on a project after the fact, which is a trust property contributors and projects both care about. The module routes fees to the right treasury on each settled sale.
Saleium uses a flat 15% self-serve sale fee written immutably at deploy, with staking, vesting and airdrop fees set the same way. The point is predictability: everyone can read the contract and know the economics will not change underneath them.
Security and audit (cross-cutting)
Security is not a module, it is a requirement across all of them, and audit cost scales with how many fund-handling modules you build. Reputable audits run $10,000 to $40,000 each, and any change to audited code should trigger a re-audit. Using established cryptographic libraries (such as OpenZeppelin for Merkle proofs and safe token transfers) reduces both risk and audit scope.
| Module | What it does | Build risk |
|---|---|---|
| Sale engine | Contributions, oversubscription, allocation, refunds | High (fund accounting) |
| Compliance | KYC, allowlist, geo, fail closed | High (regulatory) |
| Claim portal | Safe post-sale distribution | High (releases funds) |
| Vesting | Scheduled unlocks | Medium (unlock math) |
| Multi-chain | Deploy across EVM chains | Medium (config surface) |
| Fees | Immutable rate and routing | Low to medium |
Build each vs buy the stack
The right call is to build only what differentiates your product and buy the commodity modules pre-audited. For an IDO launchpad, the sale engine, compliance, claim portal, vesting and multi-chain deployment are commodity infrastructure: every project needs the same capabilities, and reinventing them adds six figures of cost and months of audit work without adding value users can see.
White-label infrastructure ships all of these modules already built and audited, so your engineering goes into your actual product. If you want to see the full stack assembled and CertiK-audited, see the launchpad, and for the broader decision across your whole product, read what to whitelabel vs build.