Крипто-launchpad работает в условиях экстремального временного давления: IDO открывается в 15:00 UTC, за 5 минут до — страница не грузится, кнопка не реагирует, кошелёк зависает. Это не edge case — это гарантированный сценарий при трафике в 10 000 пользователей. Мы проектируем UX с учётом этого, обеспечивая стабильность даже при пиковых нагрузках. Правильная архитектура интерфейса снижает количество срывов IDO на 60%, а среднее время загрузки страницы держится ниже 0.5 секунд.
Как проектировать интерфейс IDO для тысяч одновременных пользователей?
Каждый этап IDO требует чёткого UI state: discovery, eligibility check, registration, purchase, post-purchase. Для purchase экрана важна простота: поле ввода суммы, показ аллокации, кнопка approve → buy. Состояния: idle → approving USDC → confirming purchase → success / error. Ошибки нужно показывать понятно, а не execution reverted. Используйте маппинг revert reasons на сообщения UI вроде «Ваша аллокация исчерпана». Как отмечается в документации Ethereum: «Транзакция считается окончательной после включения в блок и 12 последующих подтверждений». Соответственно, пользователь должен видеть прогресс подтверждений.
Почему investor journey и staker journey нужно разделять?
Investor journey — покупка токенов проекта. Staker journey — стейкинг платформенного токена для получения tier. Для стейкеров нужны: dashboard текущего тира, калькулятор «стейк X токенов на Y дней → tier Z → аллокация $W», история стейкинга. Для проектов — форма подачи и dashboard мониторинга IDO в реальном времени. Разделение снижает когнитивную нагрузку и повышает конверсию на 30%.
Ключевые UI компоненты
Countdown и time pressure
Таймер обратного отсчёта — один из самых психологически нагруженных элементов.
- Синхронизируйте с blockchain timestamp, не с клиентским временем.
- При < 5 минутах увеличьте визуальный вес и добавьте urgency индикатор.
- При открытии IDO — плавный переход без перезагрузки (WebSocket или polling 3–5 сек).
- При завершении дайте немедленный feedback, не ждите следующего RPC запроса.
Transaction status flow
Транзакции в EVM проходят несколько стадий. Пользователь должен видеть каждую:
[Ожидание подписи в кошельке]
↓
[Транзакция отправлена: 0x1234...]
↓
[Подтверждение 1/3]
↓
[Успешно] или [Ошибка: <human-readable причина>]
Wallet connect и network switching
Multi-wallet support — обязателен: MetaMask, WalletConnect v2, Coinbase Wallet, Safe. При подключении к неправильной сети немедленный prompt на переключение, не просто ошибка.
function useNetworkGuard(requiredChainId: number) {
const { chain } = useNetwork();
const { switchNetwork } = useSwitchNetwork();
const isWrongNetwork = chain?.id !== requiredChainId;
return {
isWrongNetwork,
switchToRequired: () => switchNetwork?.(requiredChainId),
networkName: CHAIN_NAMES[requiredChainId]
};
}
Allocation display
Инвестор видит свою аллокацию в нескольких форматах одновременно, включая возможное проскальзывание (slippage):
| Формат |
Пример |
| В токенах |
10 000 TKN |
| В USD |
$500 |
| % от раунда |
0.05% |
| Vesting |
20% TGE, 80% за 6 мес. линейно |
Оптимизация загрузки и состояний
Правила работы с loading states:
- Skeleton screens — лучший выбор для загрузки данных. Spinners используйте только для кнопок.
- Stale data с индикатором — лучше показать данные 30-секундной давности с пометкой, чем пустой экран.
- Optimistic updates для purchase — показывайте «Успешно» сразу после confirmation.
- Retry логика с exponential backoff для RPC запросов, без уведомления пользователя.
Сравнение подходов к обработке транзакций:
| Подход |
Описание |
| Оптимистичный |
Сразу показываем успех, затем проверяем on-chain |
| Пессимистичный |
Ждём подтверждения от RPC |
| Гибридный |
Показываем прогресс, обновляем статус |
Благодаря оптимистичным обновлениям более 95% пользователей успешно завершают IDO без видимых задержек.
Мобильная адаптация
Значительная часть аудитории launchpad — мобильные пользователи через WalletConnect. Специфика:
- Deep link для открытия кошелька при подтверждении транзакции.
- Touch targets минимум 44px.
- Клавиатура при вводе суммы — цифровая (
inputmode="decimal").
- Scroll к форме покупки при открытии IDO (форма может быть за fold).
Design system и токены дизайна
Для launchpad с несколькими проектами важна система дизайна, позволяющая каждому проекту иметь свои цвета и шрифты без переписывания компонентов:
const IDOCard = styled.div<{ theme: ProjectTheme }>`
--accent-color: ${p => p.theme.accentColor};
--background: ${p => p.theme.cardBackground};
background: var(--background);
border: 1px solid var(--accent-color);
`;
Состояния IDO консистентно кодируются цветом: UPCOMING (нейтральный), LIVE (зелёный), ENDED (серый), FILLED (золотой).
Типичные ошибки при проектировании launchpad UX
- Игнорирование mobile-first подхода.
- Отсутствие skeleton screens для загрузки данных.
- Неправильный маппинг revert reasons — пользователь видит
execution reverted вместо понятной ошибки.
- Отсутствие индикации сети при подключении не того blockchain.
- Задержка обновления статуса IDO после завершения блока.
Что входит в результат работы
- UX-аналитика и карты пользовательских путей (CJM) для трёх ролей: инвестор, стейкер, администратор.
- Интерактивные прототипы ключевых сценариев в Figma.
- Компонентная дизайн-система с поддержкой тем (CSS custom properties).
- UI Kit с атомарными компонентами для быстрой вёрстки.
- Адаптация под десктоп и мобильные устройства (Responsive + Mobile First).
- Техническая документация с описанием состояний, переходов и обработки ошибок.
- 3 месяца бесплатной поддержки после сдачи проекта.
Этапы разработки UX/UI launchpad
- Аналитика аудиторий и построение CJM.
- Проектирование user flows для трёх ролей: инвестор, стейкер, администратор.
- Создание wireframes и прототипов ключевых сценариев.
- Дизайн UI в Figma с компонентной системой.
- Адаптация под десктоп и мобильные устройства.
- Передача исходников и документация для разработчиков.
Срок разработки — от 4 до 6 недель. Стоимость рассчитывается индивидуально под ваш проект. Оценим ваш launchpad бесплатно — свяжитесь с нами, чтобы обсудить детали. Закажите разработку UX/UI под ключ и получите готовый дизайн, протестированный под высокую нагрузку.
Разработка токенов: ERC-20, токеномика, вестинг
«ERC-20 — это просто» — фраза, после которой начинаются проблемы. Базовый transfer написать несложно. Но токен, у которого через шесть месяцев не происходит инфляционный коллапс, governance работает как задумано, а вестинг нельзя обойти через хитрую схему с делегированием — это уже проектирование.
ERC-20: что под капотом
Стандарт ERC-20 — девять функций. Сложность начинается с расширений:
ERC-20Permit (EIP-2612) — gasless approve через подпись. Пользователь подписывает permit(owner, spender, value, deadline, v, r, s) off-chain, spender вызывает permit() + transferFrom() в одной транзакции. Это убирает отдельный approve step. Но: подпись можно перехватить и использовать — нужен deadline и проверка nonce.
ERC-20Votes (EIP-5805) — snapshot балансов для governance. Checkpoint-система хранит историю балансов по номеру блока. getPastVotes(address, blockNumber) — баланс на момент создания proposal, а не текущий. Это предотвращает flash loan governance attack: нельзя занять токены и проголосовать ими в одной транзакции.
Rebasing токены (stETH, Ampleforth) — balanceOf меняется автоматически через изменение internal shares ratio. Высокая сложность интеграции: большинство DeFi протоколов не работают корректно с rebasing без wrapping в non-rebasing версию.
Fee-on-transfer токены — при каждом transfer снимается процент. Ломают AMM расчёты: пул получает меньше, чем ожидал. Uniswap v2/v3 не поддерживают fee-on-transfer нативно — нужны специальные pair/router.
Tokenomics: где математика превращается в экономику
Токеномика — это не таблица в Excel с суммой 100%. Это модель инцентивов, которая либо работает в долгосрочной перспективе, либо создаёт давление продаж которое убьёт проект.
Emission schedule и инфляция
Фиксированный supply (Bitcoin-модель) — deflation через burn механику или просто ограниченное количество. Подходит для store-of-value или utility токенов с ограниченным спросом на новые токены.
Инфляционная модель (Ethereum post-Merge, Curve) — новые токены выпускаются для стимулирования участников. Нужен баланс: emission должен быть ниже или равен value capture протоколом. Если протокол зарабатывает $100k/месяц, а эмиссия в рыночной стоимости $500k/месяц — постоянное давление продаж неизбежно.
Halving schedules (Bitcoin-style) — уменьшение emission со временем. Создаёт предсказуемость, но требует что утилити токена росла чтобы компенсировать падающие rewards для stakers/validators.
Supply distribution
| Категория |
Типичный диапазон |
Риск |
| Команда + advisors |
15–20% |
Dumping при unlock |
| Investors (seed, private) |
15–25% |
Координированный выход |
| Treasury / DAO |
20–35% |
Governance capture |
| Ecosystem / grants |
10–20% |
Неэффективное распределение |
| Public sale / LBP |
5–15% |
Недооценка на LBP → whale capture |
| Liquidity provision |
5–10% |
Mercenary capital |
Нет универсальной формулы. Есть принцип: никакой одной сущности не должно принадлежать >33% voting power при запуске. Иначе governance — фикция.
Vesting контракты: детали имеют значение
Linear vesting с cliff — стандарт для команды и инвесторов. cliff — период после TGE, в течение которого ничего не доступно. После cliff: линейный unlock до duration.
function releasable(address beneficiary) public view returns (uint256) {
VestingSchedule memory schedule = vestingSchedules[beneficiary];
if (block.timestamp < schedule.cliff) return 0;
uint256 elapsed = block.timestamp - schedule.cliff;
uint256 vestingDuration = schedule.duration - (schedule.cliff - schedule.start);
uint256 vested = schedule.totalAmount * elapsed / vestingDuration;
return vested - schedule.released;
}
Типичные ошибки при реализации:
Revocable vesting без timelock — owner может отозвать vesting мгновенно. Если owner key скомпрометирован или команда недобросовестна — все unvested токены могут быть отозваны. Решение: revocation через multisig + governance vote.
Cliff не блокирует governance права — если используется ERC-20Votes, recipient может делегировать voting power с первого дня, даже если токены ещё не unlocked. Нужно явно разделить voting power и claim logic.
Отсутствие emergency pause — если обнаружена уязвимость в vesting контракте, нужна возможность приостановить claim. Pausable + timelock на unpause.
Liquidity Bootstrapping
Запуск ликвидности — критический момент. Три основных подхода:
Balancer LBP (Liquidity Bootstrapping Pool) — временный Balancer пул с высоким начальным весом токена (90/10 проект-токен/USDC) который автоматически снижается до 50/50 за несколько дней. Создаёт нисходящее ценовое давление, препятствуя ботам скупить всё по одной цене. После LBP ликвидность переносится в постоянный пул.
Fjord Foundry — специализированная платформа для LBP и fair launches. Меньше операционного overhead чем прямая интеграция с Balancer.
Uniswap v3 с ограниченным range — добавить ликвидность в узкий диапазон вокруг начальной цены. Высокая capital efficiency, но требует активного управления range.
TWAMM (Time-Weighted AMM) — механика для постепенной продажи/покупки больших объёмов без slippage. Paradigm предложил, реализован в FraxSwap.
Governance токены и voting механики
OpenZeppelin Governor — стандартная реализация on-chain governance. Модульная архитектура: GovernorVotes для counting, GovernorTimelockControl для timelock execution, GovernorSettings для изменяемых параметров.
Quorum — минимальный процент supply для валидности голосования. Слишком высокий quorum = apathy failure (не набирается голосов). Слишком низкий = whale capture. Compound установил quorum 400k COMP (4% supply) — на практике достигается редко без координации крупных holders.
Flash loan governance attack — атакующий занимает токены через flash loan, делегирует их себе, создаёт proposal или голосует, возвращает токены. ERC-20Votes с snapshot по номеру блока полностью блокирует это: нужно иметь токены на момент создания snapshot, который берётся в момент создания proposal.
Delegation — пользователи с малыми балансами часто не голосуют. Liquid delegation (как в Optimism) позволяет делегировать voting power конкретным addresses (delegates) без передачи ownership токенов.
Стек для токен-разработки
Контракты: Solidity 0.8.x, OpenZeppelin Contracts 5.x (ERC20, ERC20Permit, ERC20Votes, Governor, TimelockController, TokenVesting)
Аудит токеномики: Python модели с симуляцией emission/demand, cadCAD для complex systems modeling
Деплой и управление: Foundry scripts, Gnosis Safe для treasury, OpenZeppelin Defender для автоматизации
Аналитика: Dune Analytics для on-chain метрик, Token Terminal для protocol revenue
Процесс
Tokenomics design — модель supply, allocation, emission schedule, vesting. Стресс-тестирование сценариев (bear market, whale exit, governance capture attempt).
Контракт разработка — ERC-20 + extensions, vesting, governance. Foundry fuzz тесты на vesting calculations, governance thresholds.
Аудит — особое внимание на governance attack vectors, vesting bypass, permit replay attacks.
LBP / launch — выбор механики, настройка параметров, мониторинг первых 24 часов.
Post-launch — мониторинг supply distribution через Dune, governance participation metrics, treasury management.
Сроки
- ERC-20 с permit и basic governance: 2–3 недели
- Vesting контракт с revocation и cliff: 2–4 недели
- Полный governance (Governor + Timelock + Token): 4–7 недель
- Токен + LBP + governance + vesting: 8–14 недель
