Розробка launchpad під ключ: смарт-контракти, KYC, аудит

Як працює IEO-платформа?

Кожна IEO-платформа стикається з трьома критичними викликами: справедливий розподіл алокацій, захист від маніпуляцій та відповідність регуляторам. Від того, як ви вирішите ці завдання, залежить довіра інвесторів та успіх усього проєкту. Ми розробляємо IEO-платформи — повноцінні рішення для Initial Exchange Offering, які не просто продають токени, а забезпечують верифікацію проєктів, справедливий розподіл алокацій та інтеграцію з біржами. Binance Launchpad та KuCoin Spotlight — приклади таких систем. Власна платформа дає повний контроль над комісіями, умовами продажу та ліквідністю. Ми допомагаємо пройти шлях від концепції до запуску, включаючи аудит смарт-контрактів. На ринку ми вже понад 5 років і реалізували понад 15 launchpad-проєктів, тому знаємо всі підводні камені.

Компоненти платформи

Як працює розподіл алокацій?

Існують два основні підходи.

Guaranteed allocation

Кожен учасник отримує гарантовану алокацію пропорційно тиру. Це простий і передбачуваний метод, але частина токенів може залишитися непроданою.

contract GuaranteedSale { mapping(address => uint256) public maxAllocation; mapping(address => uint256) public purchased; function buy(uint256 amount) external payable { require(saleActive(), "Sale not active"); require(purchased[msg.sender] + amount <= maxAllocation[msg.sender], "Exceeds allocation"); uint256 cost = amount * price; require(msg.value >= cost, "Insufficient ETH"); purchased[msg.sender] += amount; totalSold += amount; if (msg.value > cost) payable(msg.sender).transfer(msg.value - cost); } } 

Lottery з oversubscription

Більш справедливий підхід при великому попиті. Учасники реєструються, після чого випадковий вибір переможців пропорційний їх тиру. На практиці лотерея з Chainlink VRF дає в 3 рази менше скарг на несправедливість порівняно з гарантованою алокацією при перепідписці. Це підтверджують дані великих launchpad — Polkastarter та TrustPad перейшли на лотерею саме з цієї причини.

Чому Chainlink VRF обов'язковий?

Для чесної лотереї on-chain необхідна перевірена випадковість. blockhash або block.timestamp маніпулюються валідаторами, тому використовуємо Chainlink VRF — це стандарт безпеки для launchpad-платформ.

contract LotteryAllocation is VRFConsumerBaseV2Plus { mapping(uint256 => address[]) public tierParticipants; mapping(address => bool) public isWinner; uint256 public randomSeed; function register() external { require(registrationActive(), "Registration closed"); StakeInfo memory info = staking.stakes(msg.sender); require(info.tier > 0, "No tier"); tierParticipants[info.tier].push(msg.sender); } function requestRandomness() external onlyOwner { uint256 requestId = s_vrfCoordinator.requestRandomWords( VRFV2PlusClient.RandomWordsRequest({ keyHash: keyHash, subId: subscriptionId, requestConfirmations: 3, callbackGasLimit: 500000, numWords: 1, extraArgs: VRFV2PlusClient._argsToBytes( VRFV2PlusClient.ExtraArgsV1({nativePayment: false}) ) }) ); } function fulfillRandomWords(uint256, uint256[] calldata randomWords) internal override { randomSeed = randomWords[0]; _selectWinners(); } function _selectWinners() internal { uint256 seed = randomSeed; for (uint8 tier = 5; tier >= 1; tier--) { uint256 winnersForTier = tierWinners[tier]; address[] storage participants = tierParticipants[tier]; uint256 shuffleLen = participants.length; for (uint256 i = 0; i < winnersForTier && i < shuffleLen; i++) { uint256 j = i + (uint256(keccak256(abi.encodePacked(seed, tier, i))) % (shuffleLen - i)); (participants[i], participants[j]) = (participants[j], participants[i]); isWinner[participants[i]] = true; seed = uint256(keccak256(abi.encodePacked(seed, i))); } } } } 

Як налаштувати tier-систему?

Більшість успішних платформ (Polkastarter, TrustPad) використовують модель: чим більше користувач застейкав платформенний токен, тим вищий його пріоритет в алокації. Типові tier-и: 100 токенів — бронза, 1000 — срібло, 5000 — золото. Кожен tier дає множник алокації: x1, x3, x10. Така система збільшує залученість користувачів у 2 рази порівняно з фіксованими алокаціями.

contract TierStaking { struct Tier { uint256 minStake; uint256 multiplier; uint256 poolWeight; } Tier[] public tiers; struct StakeInfo { uint256 amount; uint256 stakedAt; uint256 lockEnd; uint8 tier; } mapping(address => StakeInfo) public stakes; function stake(uint256 amount, uint256 lockDuration) external { require(lockDuration >= MIN_LOCK, "Lock too short"); token.safeTransferFrom(msg.sender, address(this), amount); uint8 tier = calculateTier(amount); stakes[msg.sender] = StakeInfo({ amount: amount, stakedAt: block.timestamp, lockEnd: block.timestamp + lockDuration, tier: tier }); emit Staked(msg.sender, amount, tier); } function calculateTier(uint256 amount) public view returns (uint8) { for (uint8 i = uint8(tiers.length - 1); i >= 0; i--) { if (amount >= tiers[i].minStake) return i; } return 0; } } 

KYC/AML інтеграція

IEO-платформа працює з регуляторними вимогами. Використовуємо SaaS-провайдерів: Fractal ID, Synaps або Sumsub. Після верифікації адреса додається до on-chain білого списку. Також можливий підхід з Soulbound токенами (EIP-5484), де KYC-статус представлений як non-transferable NFT. Зверніться до нас для підбору оптимального рішення KYC.

Escrow та розподіл коштів

Кошти від продажу не повинні надходити безпосередньо проєкту — стандартний захист покупців. Використовуємо ескроу з milestones:

contract IEOEscrow { struct Milestone { string description; uint256 releasePercent; uint256 releaseTime; bool approved; uint256 approvalVotes; uint256 rejectionVotes; } Milestone[] public milestones; uint256 public totalRaised; address public project; function voteMilestone(uint256 milestoneId, bool approve) external { require(projectToken.balanceOf(msg.sender) > 0, "Must hold tokens"); } function releaseFunds(uint256 milestoneId) external { Milestone storage ms = milestones[milestoneId]; require(ms.approved, "Not approved"); require(block.timestamp >= ms.releaseTime, "Too early"); uint256 amount = (totalRaised * ms.releasePercent) / 100; payable(project).transfer(amount); } } 

Лістинг та post-sale ліквідність

Частина залучених коштів автоматично додається в DEX для забезпечення початкової ліквідності. LP-токени при цьому блокуються на 180 днів.

function finalizeAndAddLiquidity() external onlyOwner { require(saleFinished(), "Sale not finished"); uint256 liquidityETH = (totalRaised * liquidityPercent) / 100; uint256 liquidityTokens = calculateLiquidityTokens(liquidityETH); token.approve(address(uniswapRouter), liquidityTokens); uniswapRouter.addLiquidityETH{value: liquidityETH}( address(token), liquidityTokens, 0, 0, address(this), block.timestamp + 3600 ); lpLockEnd = block.timestamp + 180 days; } 

Типові помилки при розробці IEO-платформи

1. Використання простого blockhash для лотереї — це дозволяє валідаторам маніпулювати результатом. Замість цього застосовуйте перевірену випадковість (Chainlink VRF): лотерея з VRF у 3 рази ефективніша для запобігання спорам.
2. Неправильне налаштування vesting — якщо токени проєктів можна вивести миттєво, це збільшує ризик dump. Встановлюйте vesting з лінійним розподілом на 6-12 місяців.
3. Відсутність ескроу — кошти інвесторів йдуть проєкту безпосередньо, і при зриві умов їх не повернути. Ескроу з milestones обов'язковий.
4. Недостатнє тестування gas-оптимізації: неоптимізовані контракти можуть коштувати користувачам зайвих коштів (при великому продажі комісії можуть перевищувати $50 000). Проводьте ретельне тестування та оптимізацію.

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

• Аудит вимог та складання ТЗ
• Розробка смарт-контрактів стейкінгу, продажу, ескроу
• Backend API та admin panel
• Інтеграція KYC/AML
• Фронтенд для користувачів
• Аудит безпеки контрактів сторонніми командами (вартість такого аудиту починається від $30k)
• Тестування та розгортання

Строки розробки

Повний цикл від ТЗ до запуску займає 4–5 місяців. Бюджет на аудит залежить від складності та обраної команди. Зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію з архітектури.