Розробка токен-трекера: чому розблокування ламають моніторинг
Розблокування токенів ламає не сам смарт-контракт, а облік. Графік вивільнення живе в документації проєкту, таблиці в аналітика й нотатках у чаті, а мережа виконує закладену логіку за своїми подіями. Команда дізнається про кліф, коли токени вже на адресах отримувачів, а ціна відреагувала.
Ручний моніторинг розблокувань тримається на людині: хтось звіряє дату з таблиці з транзакцією, перераховує залишок заблокованого обсягу й переносить цифру у звіт.
На двох-трьох адресах це працює, на десятках розсипається: частина вивільнень іде внутрішнім викликом контракту, частина — через проміжні адреси, і в поле зору не потрапляє ні те, ні інше.
Звідси розбіжність даних щодо емісії: у звітності один обіговий обсяг, у мережі інший, і розрив накопичується з кожним розблокуванням. Від цієї цифри рахують частку ринку, тиск на ціну й звіт перед власниками, а помилку помічають не в момент події, а через тиждень під час звірки.
Розробка токен-трекера закриває це в джерелі: сервіс читає події контракту, веде облік розблокувань токенів за кожною адресою й графіком та звіряє розрахунковий календар із фактичними транзакціями. Розбіжність видно в момент події — нижче розбираємо, як це влаштовано.
Що дає власний трекер розблокувань: ефект у вимірюваних величинах
Єдине джерело даних. Календар вивільнення токенів зазвичай живе в таблиці в одного аналітика, параметри вестингу — в контрактах, а фактичний рух — у публічному оглядачі мережі.
Трекер зводить розклад, адреси отримувачів і фактичні рухи в одну базу, тому розбіжність між планом і мережею видно одразу, а не випливає під час ручного зведення трьох вивантажень.
Раннє сповіщення про розблокування. Подія потрапляє в чергу заздалегідь: правило відстежує виклики функцій вивільнення та зміну балансів цільових адрес, а сповіщення надходить за добу-дві до фактичного надходження токенів в обіг.
У команди залишається час підготувати тези й зустріти питання «чому зросли доступні обсяги» з готовою відповіддю, а не постфактум.
Знята ручна звірка. До трекера звірка плану з фактом забирала в аналітика кілька годин на тиждень і все одно пропускала крайові випадки: часткові вивільнення, перенесення дат, зміну адреси отримувача. Автоматична звірка скорочує це до хвилин і фіксує кожну розбіжність із посиланням на транзакцію.
Прозорість емісії та передбачуваний звіт. На виході — частка розблокованого від загального обсягу, графік за місяцями й список майбутніх подій із точністю до адреси.
Звіт перед власниками збирається з тих самих даних, що й операційні рішення, тому цифри в публікації та внутрішній таблиці збігаються.
Способи відстеження розблокувань: порівняння підходів
Розблокування токенів видно в публічній мережі — але видимість не дорівнює готовому графіку. Потрібно розпізнати подію, зіставити адресу з проєктом і категорією власників (команда, інвестори, казначейство) і перетворити це на календар розблокувань.
Звідси три робочі схеми: готові оглядачі мережі, власний трекер розблокувань під конкретний список проєктів і гібридна схема моніторингу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готові оглядачі мережі | Швидкий старт за великими проєктами, власної інфраструктури немає | Каталог проєктів чужий, оновлення із затримкою, не можна додати свої адреси й пороги, дані доступні лише всередині панелі |
| Власний трекер під проєкт | Свій список контрактів вестингу, потрібні сповіщення, історія та вивантаження, важлива прив’язка до категорії власників | Потрібні вузли або власна індексація, супровід і обробка змін у контрактах |
| Гібридна схема моніторингу | Проєктів багато, за ключовими потрібна глибина, за рештою достатньо огляду | Стикування двох джерел: звірка, розбіжності, дублі записів |
Вибір зводиться до трьох питань: скільки проєктів у спостереженні, чи потрібне розбиття за категоріями власників і чи мають дані надходити у ваші системи самі. Якщо хоча б дві відповіді вимагають власної логіки, оглядача як єдиного джерела не досить.
Етапи розробки: від аудиту джерел до передачі в роботу
Трекер розблокувань точний рівно настільки, наскільки повні його джерела. Частина розбіжностей у таких сервісах — не помилка розрахунку, а пропущений контракт казни або ручний переказ, не врахований у графіку вестингу. Тому починаємо не з коду, а з аудиту джерел даних.
- Аудит джерел даних. Обходимо вестингові контракти, адреси казни та мультисигів, таблиці розподілу з документів токеноміки. Заявлені графіки звіряємо з фактичними переказами в мережі, розбіжності виносимо окремим списком.
- Схема оновлення даних. Модель: токен, категорія власників, тип вестингу (cliff, лінійний, гібридний), дата й обсяг розблокування, адреса-отримувач, джерело. Для кожного джерела — своя частота опитування та правило перерахунку.
- Налаштування збору. Індексуємо події контрактів і баланси адрес: підписка на нові блоки плюс регулярне перезбирання історії. Запис ідемпотентний — повторна обробка блоку не подвоює обсяги.
- Перевірка збіжності. Порівнюємо розрахунковий графік із фактичними рухами токенів. Розбіжність вище допуску — сигнал на ручний розбір, а не відкладене завдання.
- Налаштування сповіщень. Поріг за обсягом, вікно до події, канали доставки й дедуплікація — щоб велике розблокування не тонуло в шумі дрібних транзакцій.
- Передача в експлуатацію. Регламент поповнення джерел, інструкція на збій збору, розмежування доступів і моніторинг свіжості даних: видно не лише подію, а й те, що збір живий.
Що передаємо замовнику: конфігурації, схеми, регламенти
Передача закінчується не демонстрацією працюючого екрана, а набором, з якого ваша команда сама розгортає трекер у своєму середовищі, підключає нові токени й реагує на події без нас. Інакше рішення залишається прив’язаним до одного виконавця й живе рівно до першого збою.
- Конфігурація трекера — файли з адресами контрактів і вестингу, списком відстежуваних токенів, інтервалами опитування, порогами сповіщень; розгортається у вашому середовищі без ручного редагування коду.
- Схема потоків даних — звідки надходить подія розблокування, де нормалізується, як зберігається, як іде в сповіщення та в інтерфейс; окремо позначені точки відмови й що станеться при пропуску блоку.
- Правила доступу до даних — ролі з різними правами на читання й зміну налаштувань, прив’язка до ваших облікових записів, порядок видавання та відкликання ключів.
- Регламент експлуатації — що робити при недоступності вузла, при розбіжності даних із мережею, при хибному спрацюванні; глибина зберігання історії та порядок переіндексації.
- Документація моніторингу — опис кожної метрики й сповіщення: поріг, сенс, типові причини спрацювання та спосіб придушення шуму.
- Інструкція з відновлення — резервні копії стану, точки відновлення за часом, порядок підняття трекера з нуля.
- Приймальні сценарії — набір перевірок на реальних розблокуваннях, включно зі зміною параметрів вестингу й перезапуском із втратою зв’язку.
- Передавальна сесія — розбір схем і регламентів із вашими інженерами, відповіді щодо кожного вузла й запис зустрічі.
Обсяг кожного документа узгоджуємо заздалегідь — щоб ви отримали робочий комплект, а не стос файлів, які ніхто не відкриває.
Кейс: моніторинг розблокувань для мультимережевого проєкту
Проєкт із власним токеном у чотирьох мережах і вестингом на кілька років: перші великі розблокування, лінійні графіки та окремі умови для команди, інвесторів і екосистемного фонду.
Розблокування напряму впливали на планування ліквідності, але збиралися вручну — таблиця плюс щотижнева звірка з оглядачами мереж.
Що було до
На звірку йшло 6–9 годин на тиждень, і це була робота аналітика, а не автоматика.
Класи помилок: пропущене перенесення дати першого розблокування, подвійний облік токенів, що вивільнилися одразу у двох мережах, і розбіжність між графіком у документації та фактичним станом контракту.
Що змінили
Зібрали трекер розблокувань: слухаємо події контрактів у всіх мережах, нормалізуємо їх в єдину схему «мережа — пул — дата — обсяг — отримувач» і звіряємо з публічними панелями аналітики, включно з Dune.
Графіки вестингу зберігаються як дані, а не як таблиця в документі: зміна умов — це правка запису з історією версій. Сповіщення надходять за добу до події та в момент виконання.
Що стало
Ручна звірка скоротилася до 20–30 хвилин на тиждень — це перевірка сповіщень і розбір винятків. Клас помилок «пропущений анлок» зник: усі майбутні розблокування видно заздалегідь окремо по кожній мережі.
Контроль емісії став безперервним — розбіжність між графіком і фактом фіксується в момент появи, а не через тиждень.
Що робити, якщо розблокування вже йдуть, а обліку немає?
Якщо розблокування вже йдуть, а обліку не було, завдання розпадається на дві частини: відновлення історії вивільнень заднім числом і побудова достовірного календаря на майбутнє.
Відновити можна майже все — питання в тому, до якої глибини дані залишаються доказовими, а не припущеннями.
Технічно історія збирається не з новин і не з таблиць у спільноті, а з первинних джерел.
Ми розбираємо вестинг-контракти й кастоді-адреси, читаємо логи переказів за всіма діапазонами блоків від моменту деплою, відновлюємо знімки розподілу на архівних станах і звіряємо рухи з депозитами на біржах. Так кожне розблокування отримує підтвердження в мережі, а не оцінку «приблизно тоді».
Далі починається робота з межами точності.
Якщо частина періодів закривалася через мультисиг, кастомні контракти або міграцію на нову адресу токена, прямого зв’язку між планом і переказом немає — такі події позначаються як реконструйовані з діапазоном дати та явним рівнем упевненості.
Ми не видаємо здогад за факт: у Etherscan підтверджується лише те, що справді підтверджується, решта йде окремою категорією.
Коли точку відліку зафіксовано, починається облік графіків вивільнення в автоматичному режимі: розклади фондів, командних і екосистемних часток, кліфи та лінійні ділянки зводяться в єдиний календар, який оновлюється з джерела, а не правиться руками.
Саме з цього моменту календар стає достовірним — у кожної майбутньої дати є посилання на умову контракту, а розбіжність із фактом ловиться звіркою й уходить у сповіщення.
Технічні сумніви: точність даних і оновлення контрактів
Сумніви щодо трекера розблокувань зазвичай технічні: звідки беруться цифри й чи не розваляться розрахунки при оновленні контрактів. Нижче — питання, які найчастіше задають на розборі.
Наскільки точні дані трекера?
Обсяг рахуємо з журналу транзакцій — події випуску, спалювання та переказів із вестингових адрес, а не з публічних таблиць. Суму звіряємо з фактичним залишком на адресі: не сходиться — розблокування позначається неперевіреним і в календар не потрапляє. Якщо пулів кілька, кожен ведемо за міткою адреси й виводимо сумарний обсяг за день.
Що робити при оновленні контракту або зміні адреси?
Проксі-контракт змінює реалізацію без зміни адреси: ловимо цю подію й перечитуємо опис методів за новою версією. Переїзд на нову адресу закриваємо картою відповідності — історія не рветься, графік розблокувань залишається безперервним.
Сповіщення надійде до розблокування?
Час виплати рахуємо за номером блоку, а не за серверним годинником, і тримаємо запас на підтвердження — сигнал надходить помітно раніше за подію, а не в момент відкриття. Пороги налаштовуються: за добу, за годину й при перетині заданої частки від обсягу в обігу.
Обговоримо завдання: що потрібно для оцінки та плану робіт
Оцінка трекера розблокувань тримається не на числі екранів, а на джерелах даних: звідки беремо події, як перевіряємо їхню достовірність і з якою частотою оновлюємо. Чим конкретніші вхідні дані, тим точніші строки й склад робіт — без запасів «на всяк випадок».
Щоб повернутися з оцінкою та планом, а не з уточнювальними питаннями, нам потрібен один комплект вхідних даних. Нижче — мінімум, з якого збирається оцінка етапів і запуск моніторингу.
- Перелік мереж і адрес токен-контрактів для відстеження, із зазначенням, де лежать їхні описи.
- Графіки розблокувань: частки, періоди, кліфи, адреси отримувачів — команда, інвестори, казначейство.
- Джерела даних: власні вузли доступу або сторонні, чи є ключі та ліміти на запити.
- Куди йдуть сповіщення: месенджер, пошта, вебхук у внутрішню систему, і хто отримувач.
- Вимоги до інтерфейсу: панель моніторингу, історія подій, вивантаження, ролі доступу.
- Очікуване навантаження: скільки адрес і подій на добу, яка глибина історії потрібна при первинному завантаженні.
- Обмеження щодо розміщення: свій контур або хмара, правила безпеки й доступу.
Надішліть те, що вже є, — решту уточнимо на розмові по суті. У відповідь ви отримаєте оцінку за етапами, план робіт із порядком запуску моніторингу та склад команди під кожну ділянку.
