Как работает 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 месяцев.
- Отсутствие эскроу — средства инвесторов уходят проекту напрямую, и при срыве условий их не вернуть. Эскроу с milestons обязателен.
- Недостаточное тестирование 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 месяцев. Бюджет на аудит зависит от сложности и выбранной команды. Свяжитесь с нами для оценки вашего проекта. Получите консультацию по архитектуре.