Разработка дашборда токенсейла: архитектура, real-time данные, UX

Мы разрабатываем дашборды токенсейлов, которые выдерживают пиковые нагрузки первых часов продажи, когда сотни тысяч пользователей одновременно подключают кошельки и отправляют транзакции. Ошибка в UI/UX в этот момент стоит потерянных продаж и репутационного ущерба. Наш опыт — более 5 лет в Web3 и свыше 30 успешных токенсейлов — гарантирует, что дашборд будет работать безотказно.

Дашборд токенсейла — это не просто страница с прогресс-баром. Это сложная система, объединяющая смарт-контракты, real-time данные и UX, рассчитанный на тысячи одновременных пользователей. Например, при продаже токенов проекта XYZ с хардкапом 10 млн USDC первые 5 минут обрабатывается до 15 000 транзакций — каждая требует проверки whitelist, симуляции и газ оценки.

Какие задачи решает дашборд токенсейла?

Дашборд — это фронтенд к sale-контракту. Он должен отображать прогресс сбора, состояние продажи, whitelist-статус пользователя и позволять совершать покупку в один клик. Ключевые задачи:

• Real-time мониторинг: прогресс-бар hardcap, количество участников, статус (Not Started → Active → Ended).
• Whitelist-верификация: проверка через Merkle proof без раскрытия всего списка.
• Мультивалютные платежи: поддержка USDC, USDT, ETH и других токенов с автоматической проверкой allowance.
• Симуляция транзакции: перед отправкой показываем ожидаемый результат (или ошибку) без траты газа.

Для сравнения: верификация через Merkle tree требует всего 32 байт корня в контракте, тогда как хранение полного whitelist (10 000 адресов) обошлось бы в ~1.5 млн газа при каждом обновлении. Merkle proof в 100 раз экономичнее.

Как мы строим архитектуру дашборда?

Состояние продажи как state machine

Sale-контракт проходит через фазы: not_started, whitelist_only, public, ended_success, ended_failed, distribution, refund_available. UI должен корректно отображать каждую фазу и блокировать кнопку покупки в неактивных фазах. Мы реализуем детектор фазы на основе временных меток и собранных средств.

Real-time обновление: WebSocket + резервный polling

Оптимальный способ — подписка на события контракта через WebSocket:

const provider = new ethers.WebSocketProvider(WS_RPC_URL);
const saleContract = new ethers.Contract(SALE_ADDRESS, SALE_ABI, provider);
saleContract.on('TokensPurchased', (buyer, paymentAmount, tokenAmount, event) => {
  setTotalRaised(prev => prev + paymentAmount);
  setParticipantCount(prev => prev + 1);
});

Для стабильности добавляем polling каждые 15 секунд как fallback. Критические данные (totalRaised, hardCap) получаем через Multicall, чтобы уменьшить количество RPC-вызовов. WebSocket в 10 раз быстрее polling — задержка обновления снижается с 15 секунд до 100 мс.

Whitelist-верификация через Merkle Tree

Дерево Меркла позволяет хранить корень хеша whitelist в контракте, а UI генерирует proof для каждого пользователя.

function buildMerkleTree(whitelist: string[]): MerkleTree {
  const leaves = whitelist.map(addr =>
    keccak256(Buffer.from(addr.toLowerCase().slice(2), 'hex'))
  );
  return new MerkleTree(leaves, keccak256, { sortPairs: true });
}

function getMerkleProof(tree: MerkleTree, address: string): string[] {
  const leaf = keccak256(Buffer.from(address.toLowerCase().slice(2), 'hex'));
  return tree.getHexProof(leaf);
}

Почему важна симуляция транзакции перед отправкой?

Симуляция (staticCall) позволяет отловить ошибки до отправки: пользователь не в whitelist, превышен индивидуальный лимит, недостаточно allowance. Это спасает от лишних газ-трат и негативного опыта. Мы показываем понятное сообщение об ошибке прямо в интерфейсе.

try {
  await saleContract.buy.staticCall(paymentAmount, proof, { value: ethValue });
} catch (err) {
  setError(parseContractError(err));
  return;
}

Gas estimation с буфером

Для EIP-1559 сетей оцениваем газ с запасом 20%:

async function estimateGasWithBuffer(tx: ContractTransaction) {
  const estimated = await provider.estimateGas(tx);
  return (estimated * 120n) / 100n;
}

По спецификации EIP-1559, оптимальная цена газа вычисляется на основе базовой комиссии и приоритетной наценки. Наш буфер в 20% гарантирует, что транзакция будет включена в блок в течение 30 секунд даже при резких скачках сетевой активности.

Производительность при пиковой нагрузке

Первые минуты продаж — максимальная нагрузка на RPC и frontend. Готовимся:

• Используем enterprise-ноды (Alchemy/QuickNode) с высокими лимитами.
• Кэшируем статику (токеномика, таблица распределения) через CDN.
• Оптимизируем RPC вызовы через Multicall.
• Внедряем Optimistic UI: показываем предполагаемый статус до подтверждения транзакции.

Сравнение методов обновления данных

We рекомендуем гибридную схему: WebSocket для real-time, polling как fallback при разрыве соединения — это снижает нагрузку на RPC на 80% по сравнению с чистым polling.

Что входит в разработку дашборда под ключ?

Этапы разработки

1. Аналитика и проектирование — 3-5 дней.
2. Разработка frontend — 1-2 недели.
3. Интеграция с контрактом — 3-5 дней.
4. Тестирование под нагрузкой — 2-3 дня.
5. Деплой и передача документации — 1-2 дня.

Итоговый срок — от 2 до 4 недель в зависимости от сложности.

Хотите обсудить ваш проект? Свяжитесь с нами для оценки объёма работ. Получите консультацию по архитектуре дашборда уже сегодня.

Разработка токенов: 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

Нет универсальной формулы. Есть принцип: никакой одной сущности не должно принадлежать >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 недель