IDO Platform Development

We design and develop full-cycle blockchain solutions: from smart contract architecture to launching DeFi protocols, NFT marketplaces and crypto exchanges. Security audits, tokenomics, integration with existing infrastructure.
Showing 1 of 1 servicesAll 1306 services
IDO Platform Development
Complex
from 2 weeks to 3 months
FAQ
Blockchain Development Services
Blockchain Development Stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1214
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1161
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    852
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1041
  • image_logo-advance_0.png
    B2B Advance company logo design
    561
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    823

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.