IDO Platform Development
IDO (Initial DEX Offering) is a mechanism for primary token placement through a decentralized exchange. Technically it sounds simpler than it really is. The main problem with any token launch—front-running and MEV: bots monitor mempool and buy tokens before real buyers, immediately dumping the price. A good IDO platform is primarily a system defending against this, not just "a contract with a buy button."
IDO Platform Models
Before designing, choose fundamental model:
Fixed price sale — simplest: price fixed, whitelist participants. Problem: if undervalued, bots buy in first block. Requires strict whitelist + commit-reveal or time slots.
Dutch auction — price starts high and decreases until full sale. Gives fair price discovery. Problem: hard to explain to users, high risk of last-minute manipulation.
Overflow/refund model (Binance Launchpad style) — users "deposit" any amount, final distribution proportional to contribution. Overpayment refunded. Fair but requires complex allocation logic.
Liquidity Bootstrapping Pool (LBP) — Balancer-based mechanism. Initial pool weight ratio (e.g., 95/5 token/USDC) changes over time to final value (50/50). Price starts high and decreases. Good bot protection through high initial price.
Smart Contract Architecture
Core: IDO Pool Contract
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";
contract IDOPool is ReentrancyGuard, AccessControl {
using SafeERC20 for IERC20;
bytes32 public constant ADMIN_ROLE = keccak256("ADMIN_ROLE");
struct PoolConfig {
IERC20 saleToken;
IERC20 paymentToken; // USDC, USDT or native
uint256 tokenPrice; // in paymentToken, 18 decimals
uint256 hardCap; // max raise in paymentToken
uint256 softCap; // min raise for success
uint256 minAllocation; // min purchase per wallet
uint256 maxAllocation; // max purchase per wallet
uint64 startTime;
uint64 endTime;
uint64 claimTime; // when claim opens
bytes32 whitelistMerkleRoot;
bool isPublic; // false = whitelist only
}
struct UserInfo {
uint256 contributed; // paymentToken amount contributed
uint256 tokenAllocation; // saleToken to receive
bool claimed;
bool refunded;
}
PoolConfig public config;
mapping(address => UserInfo) public userInfo;
uint256 public totalRaised;
PoolStatus public status;
enum PoolStatus { PENDING, ACTIVE, FILLED, FAILED, FINALIZED }
event Contributed(address indexed user, uint256 amount, uint256 tokenAllocation);
event Claimed(address indexed user, uint256 amount);
event Refunded(address indexed user, uint256 amount);
function contribute(
uint256 paymentAmount,
bytes32[] calldata merkleProof
) external nonReentrant {
require(status == PoolStatus.ACTIVE, "Pool not active");
require(block.timestamp >= config.startTime, "Not started");
require(block.timestamp <= config.endTime, "Ended");
// whitelist check via Merkle proof
if (!config.isPublic) {
bytes32 leaf = keccak256(abi.encodePacked(msg.sender));
require(
MerkleProof.verify(merkleProof, config.whitelistMerkleRoot, leaf),
"Not whitelisted"
);
}
UserInfo storage user = userInfo[msg.sender];
uint256 newContribution = user.contributed + paymentAmount;
require(newContribution >= config.minAllocation, "Below min allocation");
require(newContribution <= config.maxAllocation, "Exceeds max allocation");
require(totalRaised + paymentAmount <= config.hardCap, "Exceeds hard cap");
config.paymentToken.safeTransferFrom(msg.sender, address(this), paymentAmount);
uint256 tokenAmount = (paymentAmount * 1e18) / config.tokenPrice;
user.contributed += paymentAmount;
user.tokenAllocation += tokenAmount;
totalRaised += paymentAmount;
if (totalRaised >= config.hardCap) {
status = PoolStatus.FILLED;
}
emit Contributed(msg.sender, paymentAmount, tokenAmount);
}
function claim() external nonReentrant {
require(status == PoolStatus.FINALIZED, "Not finalized");
require(block.timestamp >= config.claimTime, "Claim not open");
UserInfo storage user = userInfo[msg.sender];
require(user.tokenAllocation > 0, "Nothing to claim");
require(!user.claimed, "Already claimed");
user.claimed = true;
config.saleToken.safeTransfer(msg.sender, user.tokenAllocation);
emit Claimed(msg.sender, user.tokenAllocation);
}
function refund() external nonReentrant {
require(status == PoolStatus.FAILED, "Pool not failed");
UserInfo storage user = userInfo[msg.sender];
require(user.contributed > 0, "Nothing to refund");
require(!user.refunded, "Already refunded");
user.refunded = true;
uint256 refundAmount = user.contributed;
config.paymentToken.safeTransfer(msg.sender, refundAmount);
emit Refunded(msg.sender, refundAmount);
}
function finalize() external onlyRole(ADMIN_ROLE) {
require(
status == PoolStatus.ACTIVE || status == PoolStatus.FILLED,
"Cannot finalize"
);
require(block.timestamp > config.endTime, "Not ended");
if (totalRaised >= config.softCap) {
status = PoolStatus.FINALIZED;
// transfer raised funds to project
config.paymentToken.safeTransfer(projectWallet, totalRaised);
} else {
status = PoolStatus.FAILED;
// return saleToken to project
uint256 unsoldTokens = config.saleToken.balanceOf(address(this));
config.saleToken.safeTransfer(projectWallet, unsoldTokens);
}
}
}
Merkle Tree Whitelist
Storing whitelist on-chain is expensive — 1000 addresses = ~$30-50 gas on Ethereum at deploy. Merkle tree solves this: only 32-byte root stored, user provides proof on transaction:
import { MerkleTree } from "merkletreejs";
import keccak256 from "keccak256";
function buildWhitelist(addresses: string[]): { root: string; proofs: Map<string, string[]> } {
const leaves = addresses.map(addr => keccak256(addr));
const tree = new MerkleTree(leaves, keccak256, { sortPairs: true });
const root = tree.getHexRoot();
const proofs = new Map<string, string[]>();
for (const addr of addresses) {
proofs.set(addr, tree.getHexProof(keccak256(addr)));
}
return { root, proofs };
}
IDO Factory
For platform with multiple concurrent IDOs, Factory pattern is needed:
contract IDOFactory {
address[] public pools;
mapping(address => bool) public isPool;
event PoolCreated(address indexed pool, address indexed projectToken);
function createPool(IDOPool.PoolConfig calldata config) external returns (address pool) {
pool = address(new IDOPool(config, msg.sender, address(this)));
pools.push(pool);
isPool[pool] = true;
emit PoolCreated(pool, address(config.saleToken));
}
}
Tier System and Staking
Professional IDO platforms (DAO Maker, Polkastarter, TrustPad) use tier-system: users stake platform token, get guaranteed allocation proportional to level:
contract TierSystem {
IERC20 public platformToken;
struct Tier {
string name;
uint256 minStake; // minimum stake for tier
uint256 allocationMultiplier; // in basis points (10000 = 100%)
uint256 guaranteedAllocation; // guaranteed USD amount
}
Tier[] public tiers;
mapping(address => uint256) public stakedAmount;
mapping(address => uint256) public stakeTimestamp;
uint256 public lockPeriod = 7 days; // lock before IDO
function getUserTier(address user) public view returns (uint256 tierIndex) {
uint256 staked = stakedAmount[user];
for (uint256 i = tiers.length; i > 0; i--) {
if (staked >= tiers[i-1].minStake) return i-1;
}
return type(uint256).max; // no tier
}
}
Bot and MEV Protection
Commit-reveal scheme: users in phase 1 send hash(amount, nonce, address) without revealing sum. In phase 2 reveal real data. Bots don't know final amount until moment of reveal.
FCFS with time slots: each tier gets time window. Tier 1 buys 12:00-12:05, Tier 2—12:05-12:15. Bots can't frontrun higher tier.
Anti-snipe: first N blocks after sale opens—100% tax on sell to deter snipers. Controversial but often applied.
Private mempool / Flashbots Protect: for EVM, submit via Flashbots RPC to exclude transactions from public mempool, protecting from front-running.
Vesting on Claim
Immediate cliff release of all tokens on claim creates immediate sell pressure. Right scheme: 20% TGE unlock, rest by vesting. Implemented via vesting contract integration on finalize:
function finalize() external {
// ...
// create vesting schedules for each participant
for (address participant in participants) {
uint256 tgeAmount = userInfo[participant].tokenAllocation * TGE_PERCENT / 100;
uint256 vestingAmount = userInfo[participant].tokenAllocation - tgeAmount;
vestingContract.createSchedule(participant, tgeAmount, 0, 0, 1);
vestingContract.createSchedule(participant, vestingAmount, claimTime, 0, vestingDuration);
}
}
Platform Infrastructure
Besides smart contracts, IDO platform requires:
| Component | Technologies |
|---|---|
| Frontend dApp | React + wagmi/viem, Web3Modal |
| KYC/AML | Sumsub, Synaps or custom |
| Whitelist management | API + Merkle tree generation |
| Real-time updates | WebSocket + event listening |
| Admin panel | Pool management, allocation calculator |
| Analytics | The Graph subgraph for on-chain data |
| Notifications | Email + Telegram on pool opening |
KYC integration is mandatory topic for regulated jurisdictions (EU MiCA, US). Essence: KYC provider verifies user, passes signature/status, checked before whitelist registration or on-chain.







