Веб3 лендинг токенсейлу: де ламається облік квот і допуску
Публічний етап продажу токена ламається не на самій сторінці — вона статична й передбачувана. Збої приходять з іншого боку: учасники заходять гуртом у перші хвилини, і веб3 лендинг токенсейлу починає перевіряти квоти та допуск у режимі, до якого інтерфейс не готовий. Що саме тут рветься, видно за трьома вузлами.
Перший — облік квот. Користувач відкриває дві вкладки, гаманець підписує дві транзакції з однаковим номером, одна з них замінює іншу. Інтерфейс уже намалював успіх за фактом підпису, а в мережі зараховано одну покупку.
Той самий ефект дає повтор при таймауті: вузол мережі не відповів, клієнт надіслав запит знову — і ліміт на адресу списано двічі або не списано взагалі.
Другий — список допуску. Поки він живе в таблиці, його правлять руками: дописують адреси, змінюють рівень квоти, ловлять дублікати в різному регістрі.
Ручна модерація не витримує потоку, а правка після публікації кореня Merkle-дерева обнуляє доказ — учасник отримує «вас немає у списку» за формально правильної адреси. Помилка тиха: ні листа, ні рядка в журналі.
Третій — одночасні звернення до спільного пулу квот. Залишок читають з кількох джерел, кеш живе своїм життям, і цифра в інтерфейсі розходиться зі станом контракту. Нижче розбираємо, як це закривається на рівні перевірок, а не косметики.
Що змінюється після впровадження: терміни, навантаження, клас відмов
Поки список учасників живе в таблиці, запуск токенсейлу — це ручне звіряння адрес і нічний деплой у момент відкриття.
Після переходу на Merkle-дерево достатньо зафіксувати корінь у контракті: лендинг віддає кожному гаманцю доказ включення, а правки у списку більше не потребують перезбирання й повторного деплою.
Підготовка до запуску стискається з тижнів до кількох днів, і старт перестає залежати від того, чи встиг хтось вивантажити актуальну версію файлу.
Пік — тисячі гаманців у перші хвилини. Підпис транзакції відбувається на стороні клієнта, лендинг лише формує дані та стежить за підтвердженням у мережі Ethereum через підписку на події.
Профіль навантаження змінюється: інфраструктура обслуговує читання й потік статусів, а не масові записи, тому сторінка не деградує на піку, а ліміт на адресу й часове вікно перевіряє сам контракт.
Головне — зникає цілий клас відмов: подвійне нарахування, правка вже відкритого списку, втрата заявки при обриві зв'язку, гонка за лімітом. Атомарна перевірка відхиляє некоректну транзакцію цілком, не залишаючи частково виконаного стану.
Якщо конфігурацію потрібно повернути, відкат займає хвилини: змінюється параметр або вказівник, без відновлення з резервних копій.
Для команди це передбачуваність: зрозумілі метрики за етапами, оповіщення на події контракту, однаковий сценарій на тестовій і робочій мережі.
Варіанти реалізації лендингу: що беремо готовим, що пишемо
Сторінка токенсейлу — це дві частини: сам лендинг (гаманець, заявка, статус) і логіка допуску. Допуск найчастіше будується на Merkle-дереві: повний список адрес фіксується одним коренем, учасник пред'являє гілку — перевірка в контракті не дорожчає зі зростанням списку. Наскільки вільно цю логіку можна переписати, залежить від підходу до збирання.
Готовий конструктор закриває типові розпродажі швидко, але диктує і форму перевірки допуску, і момент оновлення статусу. Власне збирання знімає ці рамки — ціною підтримки, моніторингу та повторних перевірок контракту за кожної зміни правил.
Три шляхи та їхня ціна
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готовий конструктор | Розпродаж за стандартною схемою, фіксований список допуску, запуск у стислі терміни | Перевірка допуску й ліміти — як у шаблоні; статус оновлюється із затримкою; інтерфейс не переписати; підтримка лише через вендора |
| Відкритий шаблон із доопрацюванням | Потрібен власний дизайн, нестандартних правил розподілу немає | Форк ведемо самі: оновлення безпеки приходять рідко, частину перевірок допуску переписуємо вручну |
| Власне збирання сторінки й контракту | Нестандартні раунди, динамічні ліміти, живий статус, кілька джерел допуску | Довше до запуску; потрібні аудит контракту, моніторинг і регресійні тести на кожну зміну |
Змішаний варіант — частий компроміс: сторінка своя, розподіл на перевіреному контракті.
Етапи робіт: від розбору моделі розподілу до передачі
Порядок робіт тут важливіший за швидкість: вітрина лендингу і смарт-контракт виходять одним релізом, і якщо спершу зібрати інтерфейс, а потім міняти модель розподілу, переписувати доведеться обидва шари. Тому йдемо від економіки розміщення до коду, фіксуючи на кожному кроці, що саме перевіряємо.
- Розбір моделі розподілу. Зводимо раунди, ліміти на гаманець, вестинг і правила повернення в одну таблицю станів — вона стає джерелом правди і для контракту, і для вітрини.
- Схема допуску. Визначаємо, хто і на яких умовах купує: Merkle-дерево для списків, підпис сервера для відкритих вікон, роздільні фази для різних груп.
- Налаштування контракту. Переносимо таблицю в параметри: тривалість фаз, стелі, пауза, події, на які підписується фронтенд. Кожна подія має рівно одного споживача в інтерфейсі.
- Збирання вітрини в реальному часі. Підписка на події мережі, обробка проміжних станів транзакції та рідкісних відкатів блоків — лічильник проданого не «смикається» і не відкочується назад на очах покупця.
- Перевірка на навантаженні. Проганяємо сценарій одночасного викупу: сотні адрес в одному вікні, конкуренція за ліміт, поведінка при переповненні раунду. Дивимося, де черга зростає і що бачить людина в цей момент.
- Передача керування. Роздаємо ролі за мультипідписом, відкликаємо зайві права, віддаємо доступи, схему деплою та інструкцію з аварійних дій — команда замовника може змінювати параметри без нас.
Такий порядок прибирає головний ризик старту: розходження між тим, що показує лендинг, і тим, що реально лежить у мережі.
Комплект передачі: схеми допуску, правила, регламенти
Після здачі в команди замовника залишається не архів з вихідним кодом, а робочий комплект: за ним лендинг токенсейлу можна вести самостійно — змінювати умови раунду, додавати учасників, оновлювати контракт і розуміти, що відбувається в момент пікового навантаження. Нижче — що саме входить у передачу і навіщо кожен артефакт потрібен на практиці.
- Схема допуску — як формується список адрес, хто і на якій підставі включає учасника, де зберігається підтвердження права на покупку і як воно перевіряється за кожного звернення.
- Правила розподілу — ліміти на учасника й на етап, черговість видачі при перевантаженні мережі, поведінка при частковому заповненні та при достроковому закритті раунду.
- Конфігурація середовищ — параметри мереж, адреси розгорнутих контрактів, ключі доступу до вузлів і сервісів спостереження, розділені на тестовий і робочий контури.
- Регламент оновлень — порядок правок: хто готує, хто підтверджує, як перевіряється на тестовому контурі, як виконується відкат, якщо перевірка не пройшла.
- Документація щодо контракту — призначення методів, перелік подій, відомі обмеження та припущення, щоб новий розробник входив у проєкт без звернень до нас.
- Інструкція щодо інцидентів — ознаки типових збоїв, точки контролю, порядок дій за кожним сценарієм і межа, за якою підключається наш інженер.
- Відомість доступів — облікові записи, ролі й права із зазначенням власника кожного пункту, щоб при зміні співробітника доступи не губилися.
Окремо передаємо журнали навантажувальних прогонів: вони показують, за якої кількості одночасних звернень лендинг починає гальмувати і де спрацьовують запобіжники.
Кейс: пікове навантаження без ручної модерації учасників
На проєкті Aurum Launchpad до запуску допуск у білий список тримався на ручній модерації.
Координатор звіряв адреси гаманців із таблицею і вносив їх у контракт окремими викликами — на піку потік заявок сягав кількох тисяч звернень за хвилину, обробка не встигала, черга на допуск росла, частина учасників бачила помилку і просто закривала сторінку.
Кожна правка вимагала втручання людини: ризик занести чужу адресу, залишити дубль або пропустити бота, а розгляд спірних заявок займав до доби.
Що саме змінили
Допуск перевели на автоматичну перевірку. Гаманець підписує повідомлення і підтверджує володіння адресою, сервіс у відповідь видає підписаний дозвіл, а контракт перевіряє його під час випуску токенів — людина в ланцюжку більше не бере участі.
Список допущених збирається заздалегідь у дерево, і в мережу йде лише його корінь, тому масові правки перестали вимагати транзакцій. Черга обмежує швидкість обробки на піку, повторні запити гасяться за ключем запиту, а адреси без історії в мережі відсікаються фільтром на вході.
Метрики до і після
Пік в одинадцять тисяч звернень за перші десять хвилин минув без відмов: усі коректні заявки підтвердилися автоматично, ручних правок — нуль.
Медіанний час від підпису до допуску скоротився з чотирьох хвилин до трьох секунд, звернень у підтримку з формулюванням «не можу потрапити до списку» — у шість разів менше. Помилки допуску (чужа адреса, дубль, бот, що пройшов фільтр) зникли як клас.
Контракт залишається незмінним після старту, а ключ видачі дозволів винесено в окремий сервіс із журналом: при інциденті допуск перевипускається без правок коду.
Той самий контур ми розгортаємо під збір заявок, розподіл часток і графік розблокування токенів — опишіть задачу, повернемося з оцінкою та планом.
Що робити, якщо контракт уже розгорнуто і змінити його не можна
Змінити код за розгорнутою адресою не можна: байткод у мережі незмінний, і якщо проксі-шар не заклали при деплої, правити нічого. Обмеження стосується лише адреси, а не системи — логіку можна винести в окремий контракт, залишивши старий сховищем стану і точкою входу. Тоді оновлення логіки стає новим деплоєм і перемиканням викликів, а не переписуванням історії.
Головний ризик тут — сумісність сховища. Порядок і типи полів зафіксовані на момент розгортання: вставите змінну в середину структури — старі значення прочитаються як чужі, і облік поїде.
Тому нові поля додаємо лише в кінець, а до наявних звертаємося через явні геттери: так правка не зачіпає вже записані баланси й статуси.
Міграція даних починається зі снапшота: знімаємо стан за подіями контракту, звіряємо з прямим читанням сховища і фіксуємо контрольні суми.
Для whitelist це окремий крок — права переносимо в Merkle-корінь, публікуємо його і даємо учасникам перевірити свої докази до старту продажу, а не в момент покупки.
Далі порядок дій такий: аудит поточного стану, перенесення логіки, повторний прогін сценаріїв на форку мережі, потім перемикання лендингу та індексатора.
На час переходу рахуємо операції в обох контрактах і звіряємо підсумки порядково — розходження видно відразу, а не після емісії. Відкат на попередню схему залишається можливим, поки старий контракт не вивели з експлуатації.
Часті технічні питання: допуск, навантаження, оновлення
Допуск учасника, стійкість до навантаження й оновлення правил — три питання, через які лендинг токенсейлу найчастіше переробляють уже після старту продажів. Нижче — як кожне з них закривається на рівні контракту й конфігурації, а не ручними діями в момент напливу.
Як перевіряється допуск, якщо білий список зібрано вручну?
Список допущених адрес зберігається у файлі, з нього рахується дерево хешів, а на контракті залишається лише корінь. Учасник пред'являє короткий доказ, контракт звіряє його з коренем — перевірка коштує однаково і для сотні адрес, і для десятків тисяч. Доповнити список — означає перерахувати корінь і оновити одну змінну.
Чи витримає сторінка одночасний захід тисяч учасників?
Старт продажів — це сплеск: сторінка відкривається в усіх за одну хвилину, а покупку роблять одиниці. Статика віддається з кешу на периферії, запис іде лише в момент покупки, тому заходи не перетворюються на чергу транзакцій.
Прогрес збору та статус учасника підтягуються з індексатора, при відмові вузла запит іде на резервний.
Чи зможемо ми самі змінювати правила продажів?
Так, якщо параметри винесені в конструктор контракту: тривалість етапів, діапазони розподілу, ліміти й паузи змінюються адміністративною роллю без перезбирання. Межі правок прописуються заздалегідь — що змінюється, до якого моменту і що фіксується після першої покупки. Роль адміністратора можна тримати на мультисизі або під таймлоком.
Обговоримо задачу: повернемося з оцінкою та планом робіт
Щоб повернутися з оцінкою та планом, а не з уточнювальними питаннями, нам потрібні вихідні дані щодо задачі. Нижче — те, що зазвичай визначає обсяг робіт із веб3-лендингу токенсейлу: від моделі розподілу до поведінки смарт-контракту в перші хвилини після відкриття раунду. Якщо частину пунктів ще не вирішено — це нормально, пройдемо ними разом і зафіксуємо в плані.
- Мета збору та модель розподілу: частки, ліміти на один гаманець, кому і в якому порядку відкривається доступ.
- Правила раунду: фіксована ціна або діапазон, час старту й закриття, що відбувається при недоборі.
- Список допущених адрес: скільки їх, звідки приходять, чи потрібен Merkle-корінь і як часто він оновлюється.
- Мережа й активи: де випускається токен, приймаєте нативний актив чи стейблкоїн, чи потрібне повернення коштів.
- Що показуємо в реальному часі: прогрес збору, лічильник учасників, таймер, статус підключеного гаманця.
- Доступи та керування: хто підписує розгортання, чи потрібен мультипідпис і пауза на випадок інциденту.
- Очікуване навантаження: скільки людей зайде в перші хвилини, чи потрібні обмеження частоти запитів до контракту.
- Що вже готово: макети, домен, аналітика, юридичні формулювання на сторінці.
Надішліть те, що є, — чернетку правил, вивантаження адрес, посилання на макети. Обговоримо задачу, повернемося з оцінкою та планом робіт за етапами і відразу назвемо наступний крок.
