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