Ми розробляємо дашборди токенсейлів, які витримують пікові навантаження перших годин продажу, коли сотні тисяч користувачів одночасно підключають гаманці та відправляють транзакції. Помилка в 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: показуємо передбачуваний статус до підтвердження транзакції.
Детальніше про навантажувальне тестування
Моделюємо пік у 50 000 одночасних підключень за допомогою k6 і Artillery. Перевіряємо, що час відповіді API не перевищує 200 мс, а RPC-виклики не перевищують ліміт 10 000 за хвилину. Типова помилка — забути про rate limiting провайдера. Ми додаємо чергу запитів з пріоритетами.Порівняння методів оновлення даних
| Метод | Затримка | Навантаження на RPC | Вартість підтримки |
|---|---|---|---|
| WebSocket | ~100 мс | Низьке (push) | Середня |
| Polling (15 сек) | 15 с | Високе (часті запити) | Низька |
| Websocket + Polling | <100 мс | Низьке (з резервом) | Середня |
Ми рекомендуємо гібридну схему: WebSocket для real-time, polling як fallback при розриві з'єднання — це знижує навантаження на RPC на 80% порівняно з чистим polling.
Що входить у розробку дашборду під ключ?
| Компонент | Опис |
|---|---|
| Аналітика | Вивчення вашого смарт-контракту, складання схеми даних |
| Дизайн UI | Адаптивний інтерфейс з прогрес-баром, таймером, історією транзакцій |
| Інтеграція з контрактом | Real-time підписка, Merkle-верифікація, мультивалютність |
| Тестування | Load-тестування під піковим навантаженням, симуляція помилок |
| Деплой і документація | Розгортання на VPS/CDN, інструкція для команди |
Етапи розробки
- Аналітика та проєктування — 3-5 днів.
- Розробка frontend — 1-2 тижні.
- Інтеграція з контрактом — 3-5 днів.
- Тестування під навантаженням — 2-3 дні.
- Деплой і передача документації — 1-2 дні.
Підсумковий термін — від 2 до 4 тижнів залежно від складності.
Бажаєте обговорити ваш проєкт? Зв'яжіться з нами для оцінки обсягу робіт. Отримайте консультацію з архітектури дашборду вже сьогодні.