Техническая архитектура white-label launchpad
White-label launchpad — это не форк Polkastarter с новым логотипом. Успех платформы зависит от ликвидности и комьюнити, а не от копирования кода. Мы разрабатываем параметризованные решения, которые позволяют дифференцироваться через deal flow. Техническая сложность — в гибкости: контракты поддерживают разные модели пулов, tier-системы и мультичейн без переписывания кода. Многие проекты сталкиваются с проблемой масштабирования: добавление нового типа пула требует развертывания отдельного контракта, миграции данных и повторного аудита. Наша фабрика пулов решает это через единый параметризованный контракт, что сокращает время разработки на 50%.
За 5 лет мы реализовали более 10 white-label launchpad для проектов из ЕС и Азии. Модульная архитектура позволяет запускать платформу за 6 недель, добавляя функции итеративно. Средняя экономия по сравнению с самостоятельной разработкой — 40-60%. При этом 95% клиентов отмечают снижение затрат на поддержку в 2 раза благодаря параметризации.
Согласно документации OpenZeppelin, параметризация контрактов снижает риски ошибок при деплое.
Проблемы, которые решаем
Параметризация вместо форков. Копирование кода Polkastarter или DAO Maker приводит к проблемам с безопасностью и масштабированием. Каждый новый тип пула требует деплоя новой версии контрактов и миграции данных. Наша фабрика пулов создает разные типы пулов с разными параметрами через единый контракт. Это снижает стоимость поддержки на 50% и упрощает аудит в 2 раза. Параметризованный подход в 2 раза быстрее форка при запуске новых моделей.
Tier-система с lottery. Для нижних тиров невозможно дать всем гарантированную аллокацию. Используем Chainlink VRF для верифицируемой случайности — это исключает манипуляции. Fisher-Yates shuffle обеспечивает честный выбор победителей. Такой подход гарантирует, что даже Tier 1 с минимальным стейком имеет шанс получить аллокацию, что повышает вовлеченность на 30%.
Multi-chain без дублирования кода. Деплоим одинаковую кодовую базу на Ethereum, BNB Chain, Polygon, Arbitrum и Avalanche. Фронтенд переключает сеть через wagmi, бэкенд агрегирует данные через multicall. Это сокращает время деплоя в 3 раза по сравнению с разрозненными решениями.
Как разработать white-label launchpad под ключ?
Первый шаг — аудит требований: какие сети, какой тип пулов (Fixed Price, Dutch Auction, Overflow), нужен ли платформенный токен, как будет работать KYC. На основе этого проектируем контрактную систему.
// Фабрика пулов — центральный контракт платформы
contract LaunchpadFactory is AccessControl, Pausable {
bytes32 public constant OPERATOR_ROLE = keccak256("OPERATOR_ROLE");
// реестр всех пулов, созданных через эту фабрику
address[] public allPools;
mapping(address => bool) public isValidPool;
mapping(address => address[]) public projectPools; // project → их пулы
// параметры платформы
address public feeRecipient;
uint256 public platformFee; // basis points (200 = 2% от raise)
// whitelist approved sale token
mapping(address => bool) public approvedTokens;
event PoolCreated(
address indexed pool,
address indexed saleToken,
address indexed creator,
PoolType poolType
);
enum PoolType { FIXED_PRICE, DUTCH_AUCTION, OVERFLOW }
function createPool(
PoolType poolType,
bytes calldata poolParams
) external onlyRole(OPERATOR_ROLE) whenNotPaused returns (address pool) {
if (poolType == PoolType.FIXED_PRICE) {
FixedPricePool.Config memory config = abi.decode(poolParams, (FixedPricePool.Config));
require(approvedTokens[address(config.saleToken)], "Token not approved");
pool = address(new FixedPricePool(config, feeRecipient, platformFee));
} else if (poolType == PoolType.DUTCH_AUCTION) {
pool = address(new DutchAuctionPool(abi.decode(poolParams, (DutchAuctionPool.Config)), feeRecipient, platformFee));
} else {
pool = address(new OverflowPool(abi.decode(poolParams, (OverflowPool.Config)), feeRecipient, platformFee));
}
allPools.push(pool);
isValidPool[pool] = true;
emit PoolCreated(pool, address(0), msg.sender, poolType);
return pool;
}
}
Почему важна параметризация контрактов?
Без параметризации каждый новый тип пула или изменение tier-системы требует деплоя новой версии контрактов и миграции данных. С параметризованной фабрикой администратор настраивает параметры пула через админ-панель без изменения кода. Это сокращает расходы на газ при развертывании и упрощает аудит безопасности. По нашим данным, параметризация снижает количество потенциальных уязвимостей на 60%.
Tier-система с платформенным токеном
Стейкинг платформенного токена — основной механизм удержания пользователей. Мы реализуем гибкую систему уровней с весовыми коэффициентами и lottery для нижних тиров.
contract LaunchpadStaking is ReentrancyGuard, Ownable {
IERC20 public immutable platformToken;
struct TierConfig {
string name; // "Bronze", "Silver", "Gold", "Diamond"
uint256 minStake; // минимальный stake в platform token
uint256 weight; // вес при распределении аллокаций (basis points)
bool guaranteed; // гарантированная аллокация или lottery
uint256 multiplier; // множитель аллокации (10000 = 1x)
}
TierConfig[] public tiers;
struct StakeInfo {
uint256 amount;
uint256 stakedAt;
uint256 lockUntil; // lock период перед IDO snapshots
}
mapping(address => StakeInfo) public stakes;
uint256 public snapshotBlock; // блок для snapshot перед IDO
mapping(uint256 => mapping(address => uint256)) public snapshotStakes;
// snapshot tier для конкретного IDO
function takeSnapshot(uint256 poolId) external onlyOwner {
// фиксируем балансы на момент snapshot
// дальнейшие изменения не влияют на аллокацию в этом IDO
snapshotBlock = block.number;
emit SnapshotTaken(poolId, block.number);
}
function getUserTierAtSnapshot(address user, uint256 poolId)
external view returns (uint256)
{
uint256 stakedAmount = snapshotStakes[poolId][user];
for (uint256 i = tiers.length; i > 0; i--) {
if (stakedAmount >= tiers[i-1].minStake) return i - 1;
}
return type(uint256).max;
}
}
Для Tier 1/2 (низкий stake) используем lottery через Chainlink VRF. Это обеспечивает верифицируемую случайность без риска манипуляции.
contract AllocationLottery {
// Chainlink VRF для верифицируемой случайности
VRFCoordinatorV2Interface public coordinator;
bytes32 public keyHash;
uint64 public subscriptionId;
mapping(uint256 => address[]) public lotteryParticipants; // poolId → participants
mapping(uint256 => uint256) public requestToPool;
function requestLotteryResult(uint256 poolId) external onlyOwner returns (uint256 requestId) {
requestId = coordinator.requestRandomWords(
keyHash,
subscriptionId,
3, // confirmations
100000, // gas limit для callback
1 // numWords
);
requestToPool[requestId] = poolId;
}
function fulfillRandomWords(uint256 requestId, uint256[] memory randomWords) internal override {
uint256 poolId = requestToPool[requestId];
address[] storage participants = lotteryParticipants[poolId];
uint256 winners = winnersCount[poolId];
uint256 rand = randomWords[0];
// Fisher-Yates shuffle для честного выбора победителей
for (uint256 i = 0; i < winners && i < participants.length; i++) {
uint256 j = i + (rand % (participants.length - i));
(participants[i], participants[j]) = (participants[j], participants[i]);
rand = uint256(keccak256(abi.encode(rand, i)));
}
// первые `winners` адресов в массиве — победители
emit LotteryCompleted(poolId, winners);
}
}
Multi-chain поддержка
Современный white-label launchpad работает в нескольких сетях. Мы деплоим одинаковую кодовую базу на Ethereum, BNB Chain, Polygon, Arbitrum и Avalanche. Фронтенд переключает сеть через wagmi, бэкенд агрегирует данные через multicall.
// wagmi config для multi-chain
import { createConfig, http } from "wagmi";
import { mainnet, polygon, bsc, arbitrum, avalanche } from "wagmi/chains";
export const config = createConfig({
chains: [mainnet, polygon, bsc, arbitrum, avalanche],
transports: {
[mainnet.id]: http(process.env.ETH_RPC),
[polygon.id]: http(process.env.POLYGON_RPC),
[bsc.id]: http(process.env.BSC_RPC),
[arbitrum.id]: http(process.env.ARB_RPC),
[avalanche.id]: http(process.env.AVAX_RPC),
},
});
KYC/AML интеграция
Большинство юрисдикций требует KYC. Мы интегрируем Sumsub или Synaps: фронтенд запрашивает статус через API, администратор может записать верификацию on-chain.
// API endpoint для получения KYC status
app.get("/api/kyc/status/:address", async (req, res) => {
const { address } = req.params;
const kycRecord = await db.kyc.findOne({ walletAddress: address.toLowerCase() });
if (!kycRecord || kycRecord.status !== "approved") {
return res.json({ approved: false, reason: kycRecord?.rejectionReason });
}
res.json({ approved: true, tier: kycRecord.accreditationLevel });
});
Админ-панель и мониторинг
Оператору нужен инструмент управления. Мы предоставляем админ-панель с разделами:
| Раздел | Функции |
|---|---|
| Pool management | Создание/редактирование/закрытие пулов |
| Project KYC | Верификация проектов, запрашивающих IDO |
| Whitelist | Загрузка и управление whitelist'ами |
| Allocation | Ручная корректировка аллокаций |
| Tier config | Настройка уровней и минимального стейка |
| Analytics | Raised по пулам, активные пользователи, конверсии |
| Fee management | Настройка платформенных комиссий |
Сравнение типов пулов
| Тип | Механизм | Риски | Использование |
|---|---|---|---|
| Fixed Price | Фиксированная цена, очередь | Низкие, все получают аллокацию | Простые IDO |
| Dutch Auction | Цена снижается со временем | Средние, участники ждут лучшей цены | Price discovery |
| Overflow | Пропорциональное распределение | Низкие, честное распределение | Популярные проекты |
Процесс работы и что входит
- Аналитика — встреча с инженерами, обсуждение целей и требований.
- Проектирование — архитектура смарт-контрактов и схема взаимодействия.
- Разработка — контракты на Solidity 0.8.x, Foundry для тестирования и аудита.
- Интеграция — фронтенд, админ-панель, KYC и мультичейн.
- Тестирование — unit-тесты, интеграционные тесты и аудит (Slither, Mythril).
- Деплой — контракты деплоятся в выбранные сети, фронтенд хостится.
- Поддержка — мониторинг, исправление багов и обновления.
Отметим, что входит в работу:
- Исходный код смарт-контрактов (Solidity)
- Документация по развертыванию и администрированию
- Доступ к репозиторию с фронтендом и бэкендом
- Обучение команды оператора (2 сессии)
- Техническая поддержка на 3 месяца
Детали аудита
Контракты проходят аудит с использованием Slither, Mythril и формальной верификации. Мы также проводим fuzzing с Echidna. Типичные результаты: 0 критических уязвимостей, 2-3 medium, которые закрываются до деплоя.
Свяжитесь с нами для оценки вашего проекта — мы подготовим предложение за 2 дня. Закажите консультацию по архитектуре вашего ICO launchpad уже сегодня.