Вестинг токенів: де ламається логіка розблокування
Вестинг токенів розкладає частку учасника на інтервали: частина доступна одразу, решта відкривається за графіком розблокування. Логіка живе в смарт-контракті розблокування, але реальні збої частіше приходять не з коду, а з процесів навколо нього.
Перше місце відмови — ручні правки. Графік правлять скриптом або прямо в базі, коли потрібно посунути дату під домовленість: транзакція проходить, а стан у контракті та облік часток учасників розходяться.
Після цього будь-яка звірка показує різні доступні залишки, і повернути вихідні умови вдається лише за слідами операцій.
Друге — обхід графіка адміністратором. Якщо в ролі є право вивести або відкрити актив поза розкладом, вестинг перестає бути зобов'язанням: один підпис обнуляє весь задум. Закривається це не забороною, а розділенням прав і затримкою на виконання такої дії.
Третє — розмиття частки. Під час додаткового випуску або переведення в інший номінал частки перераховують вручну, і накопичені помилки округлення з'їдають частину відкритого балансу. Облік часток учасників має вестися від загальної емісії, а не від поточного балансу гаманця.
Кожна з цих точок перевіряється окремим сценарієм на тестовій мережі — розбираємо, як це закривається в контракті та в правах доступу.
Розблокування за графіком: частки, строки, зняття ручних операцій
Коректно зібрана схема вестингу — це не лише календар виплат, а набір правил розподілу, зафіксованих у контракті до першої операції.
Частки рахуються від незмінної бази алокації, тому додавання нового траншу не розмиває раніше видані зобов'язання: відсоток кожного учасника залишається тим самим, яким був на вході.
Розблокування прив'язане до часових точок відліку від старту, а не до дати підписання документа. Нарахування проходять автоматично: учасник сам забирає доступну частину, контракт звіряє її зі своїм графіком і відхиляє спробу зняти більше належного. Окремо задається період очікування та крок вивільнення — лінійний або ступінчастий.
Прозорість алокації — наслідок того самого: у будь-який момент видно розмір частки, обсяг уже отриманого та залишок до наступної точки. Звірка з таблицею або вивантаженням більше не потрібна, бо джерело істини одне й воно ж виконує правила.
Ручні операції зникають з процесу повністю — не потрібно готувати списки, звіряти адреси, підписувати перекази й вести журнал. Разом із ними знімається цілий клас помилок: подвійне нарахування, пропущений учасник, неправильна дата старту.
Передбачуваність розблокування стає вимірюваною — частка операцій, що пройшли без втручання людини, прямує до ста відсотків.
Перед запуском проганяємо сценарії на тестовій мережі: сума всіх часток зобов'язана точно збігтися з пулом, межі періодів — з календарем, а повторний виклик того самого дня не дає другого нарахування. Це й перетворює графік із наміру на набір перевірок, які можна перерахувати в будь-який момент.
Формати вестингу токенів: порівняння режимів і обмежень
Режим розблокування обирають не за смаком, а за тим, кого він утримує в проєкті та що відбувається при достроковому виході учасника.
Контракт фіксує правила один раз: після публікації в мережі графік не можна переписати без нового контракту та перенесення залишків, тому ціна помилки тут вища, ніж здається на етапі планування.
Нижче — живі альтернативи, між якими обирають на старті. Поєднувати режими в одному контракті можна, але кожна додаткова гілка логіки — окремий сценарій для перевірки й потенційна точка відмови.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Лінійне розблокування | Команда та інвестори з рівним горизонтом | Немає прив'язки до результату: частка доступна кожен блок, продажі розподіляються за весь строк |
| Лінійне з початковою паузою | Найм, радники, підрядники | Пауза довша за строк роботи демотивує; потрібен пункт про дострокове припинення |
| Схема з правом відкликання | Ранні раунди та гранти з поверненням нерозподіленого | Право відкликання — точка централізації; за слабких перевірок адреси можливий вивід пулу |
| Кастодіальне зберігання | Вимога інвестора тримати токени поза проєктом | Залежність від третьої сторони: її недоступність блокує видачу |
| Кілька бенефіціарів в одному контракті | Масові виплати за списком | Помилка в одному аркуші б'є по всіх одразу, а оновлення списку — нова публікація та перерахунок |
Схема з правом відкликання потребує дисципліни: право відкликання вішаємо на адресу засновника, а повернені токени йдуть на окреме сховище — інакше одним викликом можна повернути й одразу вивести весь пул.
У кастодіальній схемі ключі від гаманця-утримувача не повинні бути в тієї самої сторони, що керує проєктом, інакше конструкція втрачає сенс.
Розрахунок ведемо до коду: сума, строк, наявність паузи, кількість бенефіціарів і допустимість відкликання. Якщо після публікації правила потрібно змінювати, це завжди міграція залишків у новий контракт.
Порядок робіт: від розбору задачі до передачі контракту
Маршрут будуємо так, щоб на кожному етапі було зрозуміло, що саме перевіряємо й який артефакт залишається в замовника. Код не пишемо, доки не зафіксовано правила емісії, тривалість блокувань і те, хто має право змінювати розклад після запуску.
- Розбір задачі. Фіксуємо категорії отримувачів, період очікування, крок нарахувань і умови дострокового виходу. На виході — узгоджена модель вестингу токенів і перелік ролей із правами.
- Схема розподілу часток. Рахуємо частки адрес і пулів на реальних числах емісії, перевіряємо, що сума сходиться й залишок не зависає на контракті.
- Реалізація та модульні тести. Збираємо контракт на перевірених бібліотеках: за основу беремо OpenZeppelin з його готовими механізмами доступу та пауз.
- Перевірка сценаріїв. Проганяємо дострокове отримання, повторний запит виплати, зміну прав, паузу та екстрену зупинку. Окремо — межі: нульова адреса, нульова сума, звернення після закінчення строку.
- Зовнішній аудит коду. Незалежна команда перевіряє логіку до викладення в основну мережу; зауваження розбираємо, правки вносимо, звіт залишається публічним артефактом.
- Передача прав адміністратора. Ролі переходять замовнику через мультипідпис і затримку виконання, ключі залишаються в нього. Показуємо, як змінювати параметри розкладу й як відкликати роль.
На виході — не просто працюючий контракт, а зрозумілий власник, відтворювані перевірки та підтверджена стійкість до сценаріїв, які легко пропустити під час першого проєктування.
Що передаємо на руки: конфігурації, схеми, регламенти
Передаємо не «код і пояснення на словах», а комплект, за яким ваша команда працює без нас: випускає алокацію, проводить розблокування, розбирає інцидент. Кожен артефакт прив'язаний до конкретної дії, а не лежить «на всякий випадок».
- Документація щодо контракту: ролі, параметри, події нарахування, блокування та розблокування — з прикладами читання журналу, щоб розбір операцій не вимагав звернення до авторів коду.
- Схема алокації: частки за категоріями держателів, період очікування, крок і календар розблокування — таблицею, що сходиться з параметрами контракту до останнього запису.
- Правила доступу: хто якою роллю випускає частки, змінює отримувача та призупиняє виплати; ключі зібрані за схемою мультипідпису, єдиної точки відмови немає.
- Регламент нарахувань: порядок узгодження нових отримувачів і зміни часток, ліміти на одну операцію, хто підтверджує і в який строк.
- Інструкція для команди: покрокові дії з розблокування, звірки балансів і відкликання помилкової адреси — з очікуваним результатом кожного кроку.
- Політики відкату та безпеки: відкликання ролі, порядок дій у разі компрометації ключа, призупинення виплат без втрати вже нарахованого.
- Звіт про аудит: перелік знахідок, що виправлено, що свідомо прийнято — як аргумент для внутрішнього контролю та розмови з інвесторами.
Кейс: розсинхрон розблокування та розмиття частки засновника
Що було до
Вестинг жив у двох місцях: розклад розблокування — у модулі розподілу, баланс учасника — у токен-контракті. Між оновленням графіка та переказом проходила окрема транзакція, і в цьому вікні засновник виводив більше, ніж допускала його частка.
Звірка звітів розходилася на одиниці обліку під час кожної докапіталізації пулу, а знаходили це вже на стороні учасників.
Що змінили
Розклад і баланс звели в один контракт: зміна частки та переказ застосовуються однією транзакцією, проміжного стану не існує. Розрахунки винесли в Vesting Ledger — модуль, який обчислює доступний обсяг із незмінного графіка й віддає його контракту.
| Показник | До | Після |
|---|---|---|
| Розходження у звірці балансів | одиниці обліку на кожній виплаті | 0 |
| Вікно виведення понад частку | окрема транзакція | відсутнє |
| Відхилення частки засновника | до 6% під час докапіталізації | у межах кроку обліку |
| Перевірка після впровадження | ручна звірка звітів | сценарії з перерахунком сум, сходяться всі |
Прибрали не окрему помилку, а клас: стан вестингу або застосовано повністю, або не застосовано. Сценарії з частковим виведенням, докапіталізацією та скасуванням більше не дають розсинхрону — раніше на них припадала основна частина звернень.
Чим відрізняється кастодіальна схема зберігання від некастодіальної?
Різниця між кастодіальною та некастодіальною схемами вестингу — у тому, у кого лежать ключі доступу до токенів. У кастодіальній ними розпоряджається майданчик або сервіс-зберігач, а контракт лише фіксує графік розблокування.
У некастодіальній ключі залишаються в отримувача або всередині контракту під мультипідписом і таймлоком.
Звідси різний рівень контролю. Кастодіальна дозволяє оператору призупинити виплати, зсунути кліф або відкликати нерозподілену частину — зручно для внутрішніх програм, але отримувач залежить від чужого рішення.
Некастодіальна прибирає посередника: умови зашиті в код і однакові для всіх, зате правка графіка після запуску потребує нового контракту.
Ризики зберігання зміщуються разом із контролем. У кастодіальній схемі вузька точка — рахунок зберігача: компрометація його ключа або блокування на стороні майданчика зупиняють весь пул.
У некастодіальній втрата ключа зачіпає частку одного отримувача, а відновлення доступу проєктують заздалегідь — мультипідпис і резервні держателі.
Обсяг робіт теж різниться. У кастодіальному варіанті більше інтеграції: ролі оператора, обмеження на достроковий переказ, журнал подій і звірка залишків зі зберігачем.
У некастодіальному центр ваги — ключова інфраструктура та аудит коду: графік не можна обійти, випуск не перевищить зарезервований пул.
Вибір диктують вимоги: потрібен ручний контроль і корпоративний контур — беруть кастодіальну схему, важлива незалежність отримувачів — некастодіальну. Ми проєктуємо обидві та на аудиті показуємо, де саме у вашому графіку вестингу проходить межа довіри.
Технічні сумніви: аудит, оновлення, права доступу
Перед запуском вестингу сумніви зазвичай ті самі: скільки триває аудит, що буде, якщо умови доведеться змінювати, і в кого залишаться права після передачі управління. Нижче — короткі відповіді; повний розбір іде вже за вашою схемою.
Який обсяг аудиту потрібен і що до нього входить?
Обсяг задає не кількість рядків, а кількість розвилок: затримка перед першою виплатою, дострокове виведення, кілька категорій отримувачів, пауза. Перевіряємо арифметику часток і округлень, межі часових вікон, доступ до нарахування та сценарії, де кошти може отримати не та адреса.
На виході — звіт із знахідками за критичністю та виправленнями, плюс повторна перевірка правок. Спираємося на перевірені бібліотеки на кшталт OpenZeppelin: менше власного коду — менше поверхня для помилок.
Що буде, якщо умови зміняться або управління передадуть?
Графік, розмір порцій і список отримувачів виносимо в параметри, а не в тіло логіки. Зміна проходить окремою операцією із затримкою та подією в журналі, щоб отримувачі дізнавалися про неї заздалегідь; уже нараховані частки не переписуємо — лише майбутні періоди.
Після запуску права адміністратора звужуються: зміна параметрів і випуск залишаються за мультипідписом із кількох ключів. Передача управління відбувається у два кроки — призначення нового розпорядника та його підтвердження, тому доступ не втрачається через одруківку в адресі.
Обговоримо задачу: склад робіт і що потрібно з вашого боку
Щоб оцінка строків спиралася на факти, а не на припущення, зберімо ввідні щодо токеноміки та прав доступу. Чим конкретніші вихідні дані, тим менше уточнювальних ітерацій до старту робіт — зазвичай це економить один-два тижні на листуванні.
Що потрібно з вашого боку:
- Графік вестингу токенів: кому й які частки розблоковуються, чи є період очікування, крок і періодичність виплат, поведінка при пропущеному зрізі.
- Параметри токена: стандарт, загальний обсяг випуску, подільність, чи потрібно переносити вже випущені баланси.
- Ролі та права: хто адмініструє контракт, які параметри допускають зміну, чи потрібен мультипідпис і затримка виконання.
- Середовища та мережі: де проходить перевірка, де буде бойове розгортання, вимоги до підтверджень транзакцій.
- Облік і моніторинг: які події мають потрапляти у звітність, чи потрібні вивантаження для бухгалтерії та аналітики.
- Обмеження: регуляторні вимоги, юрисдикції держателів, заборона на передачу прав третім особам.
- Строки: дата, до якої контракт має бути готовий, прив'язка до продажу або виходу на біржу.
На основі цих даних збираємо склад робіт, фіксуємо етапи та обсяг аудиту. Опишіть задачу — повернемося з оцінкою строків і планом впровадження, включно з порядком розгортання та приймання.
