Розробка системи автоматичного клейму airdrop

Ручний клейм токенів: вузькі місця та розробка airdrop

Аірдроп ламається не на етапі розрахунку нарахувань, а на видачі: отримувач відкриває сторінку, підключає гаманець і бачить нульовий баланс доступного до клейму.

Причини типові — розрахунок зроблено за знімком стану на одну дату, а право на виплату перевіряється за поточним балансом; дерево Меркла зібрано з помилкою в листках; підпис сервера прострочений або не збігається з адресою отримувача.

Кожен такий випадок перетворюється на окреме звернення до підтримки, де вручну звіряють адресу, суму й транзакцію.

Окремий клас поломок — мережевий. Транзакція не проходить через нестачу газу в отримувача, якщо комісію не компенсує сторона, що роздає, або йде в очікування й замінюється новою з тим самим порядковим номером; користувач бачить помилку, натискає клейм повторно й втрачає комісію.

Ручна видача тут не масштабується: що більше учасників, то вища частка тих, хто не забрав нарахування до закриття вікна.

Ціна питання — не лише навантаження на підтримку. Частина адрес втрачає право на виплату після закінчення строку, спірні випадки доводиться закривати з резерву вручну, а спільнота судить про проєкт за тим, як працює кнопка «Отримати».

Роздача токенів учасникам не повинна залежати від оператора: розробка airdrop починається з контракту клейму й черги виплат — розрахунок, знімок, докази, ідемпотентне надсилання та повторні спроби.

Автоматичний клейм токенів знімає основну частину проблем ручної видачі — розбираємо, як це закривається.

Що змінюється після впровадження автоматичного клейму

Перше, що змінюється — механіка нарахувань. Замість потоку одиночних транзакцій контракт-дистриб'ютор надсилає пачку адрес одним викликом: витрати газу на той самий список падають у 3–5 разів, а черга з десятків тисяч гаманців проходить за хвилини, а не години.

Пакетні нарахування прибирають і головний ризик ручного етапу — розсинхрон між базою учасників і станом контракту.

Частка успішних клеймів визначається не лише логікою контракту, а й обробкою відмов. Інженери розбирають причини реверту — нестача газу в користувача, ліміти, повторний виклик — і налаштовують повторні спроби з коректними параметрами плюс моніторинг за кожною адресою.

Успішність клейму піднімається до 95–98%, а решта випадків видна в журналі, а не з'ясовується з повідомлень учасників.

Навантаження на підтримку падає разом із цим: статус клейму доступний користувачеві за адресою гаманця, збої потрапляють у чергу на розбір, типові питання «де мої токени» закриваються без оператора. Обсяг звернень знижується на 60–70% уже першого тижня роздачі.

Прозорість залишається на боці мережі: кожен переказ перевіряється в Etherscan — гаманець, обсяг нарахування, хеш транзакції, час. Вивантаження по всій роздачі збирається у звіт: скільки адрес отримало нарахування, скільки пішло на повтор, де залишилися необроблені. Обговоримо параметри вашої роздачі — повернемося з оцінкою та планом робіт.

Розробка airdrop: формати автоматичного клейму

Формат роздачі — це не лише питання зручності отримувача. Від нього залежить, хто оплачує комісію мережі, коли токен опиняється на гаманці, скільки адрес витримає контракт і як потім звітувати перед аудитом.

На практиці формати роздачі токенів зводяться до чотирьох схем — від пулу, з якого учасник забирає сам, до прямого масового переказу.

Схеми комбінуються: базовий клейм за списком плюс стримінг на частину суми. Такий гібрид закриває і захист від повторів, і утримання, а перехід між форматами ми закладаємо в контракт заздалегідь — без переробки після запуску.

Етапи впровадження системи клейму: від аудиту до передачі

До старту роздачі в команди зазвичай є токеноміка та вивантаження адрес, але немає відтворюваної відповіді, хто і за яким правилом отримує право на клейм.

Етапи впровадження клейму вибудовуємо так, щоб це правило перевірялося до запуску, а не з'ясовувалося першого дня роздачі, коли помилкові нарахування вже пішли в мережу.

1. Аудит роздачі. Розбираємо джерела — знімок держателів, списки учасників, облік активностей. Звіряємо розрахунок на контрольній вибірці адрес, знаходимо дублі та розбіжності, отримуємо специфікацію, за якою рахується кожна сума.
2. Схема контрактів. Визначаємо, де зберігається право на клейм і хто ним керує: підписувач, дерево розподілу, казна. Окремо фіксуємо, які параметри змінюються без перевипуску контракту, а які потребують міграції.
3. Реалізація та налаштування. Контракт клейму, інтерфейс, службові скрипти: ліміт на адресу, вікно за часом, пауза, виведення невитраченого. Ролі розносимо за різними ключами, щоб один втрачений доступ не відкривав усю роздачу.
4. Перевірка на тестовій мережі. Проганяємо сценарії, які ламають такі системи в реальній експлуатації: повторний клейм, частковий список, пауза на середині, виклик з чужої адреси. На кожен сценарій — очікуваний результат і журнал.
5. Підготовка до запуску. Моніторинг нарахувань і виведень, ліміти на сплеск звернень, регламент дій під час інциденту та зрозумілий порядок зупинки роздачі.
6. Передача системи. Вихідні коди, схема контрактів, конфігурації, опис ролей і доступів, інструкція з повторного запуску та розбір уже знайдених помилок.

Що залишається у вас: конфігурації, схеми, регламенти

Ми не залишаємо систему в стані «обслуговує лише автор коду». Усе, що стосується автоматичного клейму, після здачі лежить у вашому репозиторії та вашій інфраструктурі — з описом того, як це працює і що робити, коли щось іде не так. Нижче перелік артефактів, які ви отримуєте на руки й можете використовувати без нашої участі.

• Документація з клейму. Життєвий цикл заявки: перевірка права на участь, розрахунок суми, підпис транзакції, підтвердження в мережі. Окремо — точки відмови та штатна поведінка системи за кожної з них.
• Схеми розгортання. Топологія сервісів, середовища (тестове й робоче), залежності між ними та порядок підняття з нуля на чистій інфраструктурі.
• Політики доступу. Хто і через яку роль ініціює виплати, хто змінює ліміти, як видаються, ротируються й відкликаються ключі підпису, що доступно лише для читання.
• Регламенти оновлення та відкату. Як викочується нова логіка розрахунку, як повернутися до попередньої версії, що відбувається з незавершеними заявками в момент перемикання.
• Конфігурації та параметри. Ліміти на обсяг і частоту виплат, налаштування комісій мережі, списки токенів і мереж — файлами, з коментарями до кожного значення.
• Моніторинг і оповіщення. Метрики: частка успішних клеймів, глибина черги заявок, час підтвердження. До кожної — поріг, за якого спрацьовує сигнал черговому.
• Інструкція для чергового інженера. Що робити при завислій транзакції, вичерпанні балансу підписувача, недоступності вузла: діагностика та порядок дій крок за кроком.

Кожен документ прив'язаний до конкретної версії конфігурації, тому при змінах ви правите один файл, а не відновлюєте логіку за листуванням. Якщо ваша команда захоче передати підтримку іншому підряднику, точка входу — цей самий комплект.

Кейс: роздача на 40 тисяч адрес без ручної видачі

Проєкт — airdrop на 40 000 адрес у мережі Solana. Список учасників збирався зі снапшоту, але сама видача була ручною: оператори звіряли адресу з таблицею, перевіряли право на клейм і надсилали транзакцію з гаманця. Роздача розтягнулася на три тижні, і черга зростала швидше, ніж її встигали розбирати.

До: вузьке місце на боці операторів

Вручну проходило близько 1 200 клеймів на добу — за 40 тисяч адрес це тижні безперервної роботи. Кожен оператор тримав відкритою таблицю й звіряв адресу очима; помилка в одній цифрі надсилала токени не тому отримувачу, а повторна видача потребувала окремого розбору.

Підтримка отримувала 700–800 звернень на тиждень, і майже всі зводилися до одного: «надіслав запит, токени не прийшли».

Після: автоматичний клейм за підписом

Ми зібрали контракт роздачі з деревом хешів за списком учасників і особистий кабінет, де людина підключає гаманець, підписує повідомлення й отримує токени однією транзакцією.

Право на клейм перевіряє контракт, тому оператор з ланцюжка зникає, а повторний виклик відсікається прапорцем. Без ручного втручання пройшло 97% успішних клеймів, пікове навантаження сягнуло 9 000 на добу, час від підпису до зарахування — секунди.

Звернення до підтримки знизилися більш ніж у шість разів: типові питання закрив статус клейму прямо в інтерфейсі та зрозуміла помилка при спробі повторної видачі. Залишилися поодинокі випадки з гаманцями на біржах — для них ми прописали окремий маршрут виведення.

Чим відрізняється клейм за списком від стримінгової роздачі

Клейм за списком будується навколо фіксованого набору адрес: перелік отримувачів зводиться в дерево хешів, а в контракті публікується лише кореневий хеш — сам список залишається поза мережею і не роздуває її стан.

Учасник пред'являє доказ включення, контракт перевіряє його й позначає адресу використаною. Одноразова видача приходить цілком, комісію мережі платить учасник, а не проєкт.

Стримінгова роздача влаштована інакше: право на токени виникає не в момент знімка, а за розкладом нарахувань. Доступний обсяг зростає лінійно або ступенями, учасник забирає накопичене в зручний йому момент.

У контракті фіксуються темп, точка старту, строк повного розкриття та правила пауз — токен входить в обіг плавно, а отримувач залишається в екосистемі довше.

Різниця проявляється в класах відмов. У списку найкрихкіше — актуальність: зміна права після публікації кореня потребує нового кореня й перенесення невикористаних прав, а повторний клейм закривається відміткою на адресу.

У стримінгу критичний розрахунок: помилка в темпі або в обробці пропущеного періоду дає занижене чи завищене нарахування, і виправляється вона окремою операцією заднім числом.

Навантаження теж лягає по-різному. Список дає гострий пік у перші години — безліч незалежних викликів, зростаюча комісія мережі та конкуренція за місце в блоці.

Стримінг розмазує звернення по всьому строку розкладу, але контракт має залишатися працездатним і оновлюваним до останнього нарахування.

Тому вибір рідко буває «або-або»: частіше список фіксує право, а розклад задає темп. Ми розбираємо сценарій за знімком прав, горизонтом розкриття та способами відкату — і лише після цього збираємо контракт роздачі.

Технічні сумніви перед запуском роздачі

Перед виведенням роздачі в продакшн інженер перевіряє не вітрину, а поведінку системи на межах: що буде при повторному клеймі, при недоступному вузлі, при зміні списку учасників уже після публікації.

Нижче — чотири сумніви, які найчастіше спливають на прийманні, і те, як вони закриваються на рівні контракту та бекенду.

Як система відсікає мультиакаунти?

Ознаки збираються до розрахунку: зв'язність адрес за джерелами фінансування, збіг поведінки при клеймі, кластери за виведенням коштів. Аномальні групи виносяться окремим списком і розбираються вручну — пороги та правила узгоджуємо з вами, а не ховаємо в коді.

Що робити, якщо умови роздачі змінюються після запуску?

Ліміти, вікно клейму й корінь списку учасників виносимо в параметри, які змінюються окремою роллю. Зміна проходить через затримку, щоб учасники бачили її заздалегідь, а попередні значення зберігаються в історії — відкат до колишніх умов залишається можливим.

Як перевіряти коректність нарахувань?

Для кожної адреси є доказ включення до списку та сума, яку можна перерахувати незалежно від нашого бекенду. Перед відкриттям клейму проганяємо звірку на тестовій мережі та в основній — розбіжність за сумою й за кількістю адрес видно до старту роздачі.

Обговоримо задачу та повернемося з оцінкою і планом робіт

Щоб повернутися зі схемою роздачі, оцінкою строків і планом робіт із клейму, нам потрібен не переказ ідеї, а конкретика по проєкту. Нижче — те, що знімає більшу частину невизначеності на вході та дозволяє рахувати трудовитрати, а не здогадуватися про них.

• Цільова мережа та модель обліку: де саме живе токен або право на клейм, чи розгорнуті контракти, хто тримає ключі адміністратора і як вони зберігаються.
• Схема роздачі: за якою подією фіксується зріз стану, як рахуються частки учасників, які умови роблять адресу недійсною.
• Механіка клейму: разовий він чи періодичний, фіксована сума чи перерахунок, чи є періоди очікування та обмеження на переказ отриманого.
• Ролі та права: хто формує список отримувачів, хто може призупинити роздачу і як права передаються при зміні відповідального.
• Захист від зловживань: які ознаки множинних акаунтів уже враховуються, чи потрібна ручна перевірка спірних адрес і черга розбору.
• Інтеграції: гаманці та інтерфейси, куди вбудовується клейм, доступ до вузлів мережі, очікуване навантаження в перші години після старту.
• Обмеження: юрисдикції, перевірка особи отримувачів, вимоги до звітності та аудиту перед запуском.

Опишіть задачу у вільній формі — що вже готово, де зараз вузьке місце, який результат вважаєте успішним. Ми повернемося з оцінкою строків, схемою роздачі та планом робіт із клейму, де в кожного етапу є перевірюваний результат.