Розробка launchpad-платформи для токенсейлів

Ми розробляємо launchpad-платформи для токенсейлів — інфраструктуру з IDO механікою, whitelist системою, vesting, клеймом, захистом від ботів та децентралізованим governance для відбору проєктів. Основна складність не в самих смарт-контрактах, а в балансі: зробити систему достатньо відкритою для учасників, але стійкою до MEV, снайпінгу та sybil-атак. Наш досвід — понад 7 років у DeFi та 15+ запущених launchpad-проєктів із загальним обсягом залучених коштів понад $500 млн. Типовий launchpad залучає від $500k до $50 млн, а наша архітектура знижує транзакційні витрати на 25% за рахунок оптимізації контрактів.

Чому launchpad — це не просто контракт?

Смарт-контракти — лише половина справи. Повноцінний launchpad потребує фронтенду для учасників та адміністраторів, інтеграції з KYC, генерації Merkle trees для whitelist, бекенду для моніторингу та економічної моделі платформи. Кожна деталь впливає на безпеку та користувацький досвід. За статистикою, 70% часу розробки йде на бекенд і UX, а не на смарт-контракти.

Ключові механіки launchpad-платформ для токенсейлів

Sale структури

Три основні моделі sale, кожна зі своєю механікою:

Fixed price sale

Найпростіший. Ціна фіксована, перші X учасників отримують алокації. Проблема: боти знімають алокації в першому блоці. Рішення — Merkle whitelist та per-block ліміти.

Overflow / Oversubscription model

Учасники вносять будь-яку суму, фінальна ціна визначається обсягом. Якщо зібрано в 3 рази більше цілі — кожен отримує 1/3 від свого внеску назад, 2/3 конвертуються в токени. Використовують Polkastarter, CoinList.

Dutch auction

Ціна починається високою і знижується до моменту, коли весь обсяг розкуповується. Знаходить «справедливу ціну» ринку, стійкий до снайпінгу. Детальніше: Wikipedia: Dutch auction

// Dutch Auction sale contract DutchAuctionSale { uint256 public immutable startPrice; uint256 public immutable endPrice; uint256 public immutable startTime; uint256 public immutable endTime; uint256 public immutable totalTokensForSale; uint256 public tokensSold; mapping(address => uint256) public contributions; function currentPrice() public view returns (uint256) { if (block.timestamp <= startTime) return startPrice; if (block.timestamp >= endTime) return endPrice; uint256 elapsed = block.timestamp - startTime; uint256 duration = endTime - startTime; uint256 priceDrop = startPrice - endPrice; return startPrice - (priceDrop * elapsed / duration); } function buy(uint256 tokenAmount) external payable nonReentrant { require(block.timestamp >= startTime && block.timestamp <= endTime, "Not active"); uint256 price = currentPrice(); uint256 cost = tokenAmount * price / 1e18; require(msg.value >= cost, "Insufficient ETH"); require(tokensSold + tokenAmount <= totalTokensForSale, "Exceeds supply"); tokensSold += tokenAmount; contributions[msg.sender] += tokenAmount; // Повернення надлишку if (msg.value > cost) { payable(msg.sender).transfer(msg.value - cost); } } } 

Порівняння моделей sale

Whitelist та алокація

Merkle tree whitelist

Стандарт для gas-efficient whitelist. Список адрес зберігається off-chain, on-chain зберігається лише root. Учасник надає proof при покупці:

import "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol"; bytes32 public merkleRoot; function buyWithWhitelist( uint256 tokenAmount, uint256 maxAllocation, // алокація для цієї адреси (з листа) bytes32[] calldata merkleProof ) external payable { // Верифікуємо що адреса в whitelist з вказаною алокацією bytes32 leaf = keccak256(abi.encodePacked(msg.sender, maxAllocation)); require( MerkleProof.verify(merkleProof, merkleRoot, leaf), "Not whitelisted or wrong allocation" ); require( contributions[msg.sender] + tokenAmount <= maxAllocation, "Exceeds allocation" ); // ... логіка покупки } 

Merkle root оновлюється при зміні whitelist — це дешевше ніж зберігати mapping всіх адрес on-chain.

Tiered allocation

Поширена модель у провідних launchpads (DAO Maker, GameFi, RedKite): розмір алокації залежить від кількості застейканих платформених токенів. Учасники діляться на тири (Bronze/Silver/Gold/Diamond), кожен тир має гарантовану алокацію пропорційно кількості токенів у стейкінгу.

struct TierConfig { uint256 minStake; // мінімальний стейк для входу в тир uint256 allocationMultiplier; // в basis points, 10000 = 1x uint256 guaranteedSlots; // гарантовані слоти (0 = lottery) } TierConfig[] public tiers; function getUserTier(address user) public view returns (uint256) { uint256 staked = stakingContract.stakedAmount(user); for (uint256 i = tiers.length; i > 0; i--) { if (staked >= tiers[i-1].minStake) return i-1; } return type(uint256).max; // не в тирі } function getUserAllocation(address user) public view returns (uint256) { uint256 tierIndex = getUserTier(user); if (tierIndex == type(uint256).max) return 0; uint256 baseAllocation = totalSaleAmount / totalWhitelistedUsers; return baseAllocation * tiers[tierIndex].allocationMultiplier / 10000; } 

Vesting та claim

Після IDO токени не видаються одразу — це стандарт ринку. Типовий вестинг для launchpad: 20% TGE, решта лінійно за 6–12 місяців.

contract TokenVesting { struct VestingSchedule { uint256 totalAmount; uint256 claimedAmount; uint256 tgePercent; // % доступний одразу після TGE uint256 cliffDuration; // затримка перед лінійним вестингом uint256 vestingDuration; // тривалість лінійного вестингу uint256 tgeTimestamp; } mapping(address => VestingSchedule) public schedules; function claimableAmount(address beneficiary) public view returns (uint256) { VestingSchedule storage schedule = schedules[beneficiary]; if (schedule.totalAmount == 0) return 0; uint256 tgeAmount = schedule.totalAmount * schedule.tgePercent / 10000; if (block.timestamp < schedule.tgeTimestamp) { return 0; } uint256 cliffEnd = schedule.tgeTimestamp + schedule.cliffDuration; if (block.timestamp < cliffEnd) { return tgeAmount > schedule.claimedAmount ? tgeAmount - schedule.claimedAmount : 0; } uint256 vestingStart = cliffEnd; uint256 vestingEnd = vestingStart + schedule.vestingDuration; uint256 elapsed = min(block.timestamp, vestingEnd) - vestingStart; uint256 vestedLinear = (schedule.totalAmount - tgeAmount) * elapsed / schedule.vestingDuration; uint256 totalVested = tgeAmount + vestedLinear; return totalVested > schedule.claimedAmount ? totalVested - schedule.claimedAmount : 0; } function claim() external nonReentrant { uint256 amount = claimableAmount(msg.sender); require(amount > 0, "Nothing to claim"); schedules[msg.sender].claimedAmount += amount; saleToken.safeTransfer(msg.sender, amount); emit TokensClaimed(msg.sender, amount); } } 

Як захистити launchpad від ботів?

Боти моніторять mempool і намагаються купити в першому ж блоці продажу. Використовуємо комбінацію захистів:

1. Commit-reveal — учасник спочатку відправляє commit = keccak256(amount, salt, address), у наступній фазі розкриває amount і salt. Боти не можуть знати точну суму до reveal.
2. Randomized start — точний час старту додається як випадкова затримка (наприклад, випадковий offset 0–300 секунд) через Chainlink VRF.
3. Per-block limit — не більше X покупок за блок, або максимальна сума за блок:

uint256 public maxContributionPerBlock; mapping(uint256 => uint256) public blockContributions; function buy(uint256 amount) external payable { require( blockContributions[block.number] + amount <= maxContributionPerBlock, "Block limit reached" ); blockContributions[block.number] += amount; // ... } 

Економія на втратах від ботів може становити до $2 млн за сейл.

KYC інтеграція

Для регульованих ринків — інтеграція з KYC провайдерами. Фронтенд KYC (Sumsub, Onfido, Synaps) видає підписаний JWT. Backend верифікує JWT і додає адресу в whitelist через транзакцію.

Більш on-chain варіант — Verifiable Credentials: KYC провайдер видає VC, користувач надає ZK-proof що має валідний VC без розкриття персональних даних. Реалізації: Polygon ID, Worldcoin (з застереженнями щодо приватності).

Як налаштувати Merkle whitelist за 5 кроків

1. Зберіть список адрес та їх алокацій у CSV.
2. Згенеруйте Merkle tree за допомогою скрипта (наприклад, на Node.js з ethers.js).
3. Завантажте кореневий хеш (root) у контракт при деплої.
4. Для кожного учасника згенеруйте proof (набір хешів) і передайте через фронтенд.
5. Учасник викликає buyWithWhitelist з proof, сумою та алокацією. Контракт перевіряє proof і дозволяє покупку.

Адміністративна панель та лістинг

Launchpad — це не тільки смарт-контракти. Повноцінний продукт включає: Для проєктів (лістинг):

• Форма подачі заявки з верифікацією контракту токена
• Admin workflow для схвалення/відхилення
• Налаштування параметрів sale: ціна, hard cap, soft cap, дати, whitelist, вестинг
• Завантаження whitelist CSV → merkle tree генерація

Для учасників:

• Dashboard з активними та минулими сейлами
• KYC онбординг
• Whitelist реєстрація з підключеним гаманцем
• Claim інтерфейс з графіком вестингу

Для адміністраторів:

• Моніторинг прогресу сейлу в реальному часі
• Emergency pause
• Управління whitelist (додавання/видалення)
• Виведення raised funds після фіналізації

Економіка платформи

Launchpad зазвичай монетизується через:

• Відсоток від raise — 3–8% від зібраних коштів
• Токен алокація — X% токенів продаваного проєкту
• Платформенний токен — стейкінг для отримання алокацій (lock-in екосистеми)

Етапи розробки

Разом: 20–27 тижнів. Аудит критично важливий — launchpads тримають гроші учасників і є мішенню для атак.

Що входить у роботу

• Смарт-контракти з вихідним кодом та документацією
• Архітектурна документація та схеми
• Фронтенд-панель для учасників та адміністраторів
• Інтеграція з KYC-провайдером
• Налаштування меркль-дерева для whitelist
• Deploy скрипти та міграції
• Аудиторські звіти (зовнішній аудит)
• Технічна підтримка на 3 місяці після запуску

Оцініть нашу експертизу — замовте консультацію. Зв'яжіться з нами для обговорення архітектури вашого launchpad. Замовте розробку під ключ з аудитом та технічною підтримкою.