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