Як працює IEO-платформа?
Кожна IEO-платформа стикається з трьома критичними викликами: справедливий розподіл алокацій, захист від маніпуляцій та відповідність регуляторам. Від того, як ви вирішите ці завдання, залежить довіра інвесторів та успіх усього проєкту. Ми розробляємо IEO-платформи — повноцінні рішення для Initial Exchange Offering, які не просто продають токени, а забезпечують верифікацію проєктів, справедливий розподіл алокацій та інтеграцію з біржами. Binance Launchpad та KuCoin Spotlight — приклади таких систем. Власна платформа дає повний контроль над комісіями, умовами продажу та ліквідністю. Ми допомагаємо пройти шлях від концепції до запуску, включаючи аудит смарт-контрактів. На ринку ми вже понад 5 років і реалізували понад 15 launchpad-проєктів, тому знаємо всі підводні камені.
Компоненти платформи
| Компонент | Відповідальність |
|---|---|
| Project Registry | Верифікація та зберігання даних проєктів |
| Allocation Engine | Розподіл лотів між учасниками |
| KYC/AML Gateway | Інтеграція з провайдером верифікації |
| Token Sale Contract | Виконання продажу on-chain |
| Staking Contract | Стейкінг платформенного токена для tier-системи |
| Distribution Contract | Vesting та клейм токенів |
| Admin Dashboard | Управління проєктами, параметрами продажів |
Як працює розподіл алокацій?
Існують два основні підходи.
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-платформи
- Використання простого
blockhashдля лотереї — це дозволяє валідаторам маніпулювати результатом. Замість цього застосовуйте перевірену випадковість (Chainlink VRF): лотерея з VRF у 3 рази ефективніша для запобігання спорам. - Неправильне налаштування vesting — якщо токени проєктів можна вивести миттєво, це збільшує ризик dump. Встановлюйте vesting з лінійним розподілом на 6-12 місяців.
- Відсутність ескроу — кошти інвесторів йдуть проєкту безпосередньо, і при зриві умов їх не повернути. Ескроу з milestones обов'язковий.
- Недостатнє тестування gas-оптимізації: неоптимізовані контракти можуть коштувати користувачам зайвих коштів (при великому продажі комісії можуть перевищувати $50 000). Проводьте ретельне тестування та оптимізацію.
Що входить в роботу
- Аудит вимог та складання ТЗ
- Розробка смарт-контрактів стейкінгу, продажу, ескроу
- Backend API та admin panel
- Інтеграція KYC/AML
- Фронтенд для користувачів
- Аудит безпеки контрактів сторонніми командами (вартість такого аудиту починається від $30k)
- Тестування та розгортання
Строки розробки
| Компонент | Строк |
|---|---|
| Смарт-контракти (стейкінг, продаж, ескроу, дистрибуція) | 6–8 тижнів |
| Backend API + admin panel | 4–6 тижнів |
| KYC інтеграція | 1–2 тижні |
| Frontend (користувацький інтерфейс) | 4–6 тижнів |
| Аудит смарт-контрактів | 3–4 тижні |
| Тестування + QA | 2–3 тижні |
Повний цикл від ТЗ до запуску займає 4–5 місяців. Бюджет на аудит залежить від складності та обраної команди. Зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію з архітектури.