Разработка смарт-контрактов вестинга токенов с аудитом

Вестинг токенов: где ломается логика разблокировки

Вестинг токенов раскладывает долю участника на интервалы: часть доступна сразу, остальное открывается по графику разблокировки. Логика живёт в смарт-контракте разблокировки, но реальные сбои чаще приходят не из кода, а из процессов вокруг него.

Первое место отказа — ручные правки. График правят скриптом или прямо в базе, когда нужно подвинуть дату под договорённость: транзакция проходит, а состояние в контракте и учёт долей участников расходятся. После этого любая сверка показывает разные доступные остатки, и вернуть исходные условия удаётся только по следам операций.

Второе — обход графика администратором. Если у роли есть право вывести или открыть актив вне расписания, вестинг перестаёт быть обязательством: одна подпись обнуляет весь замысел. Закрывается это не запретом, а разделением прав и задержкой на исполнение такого действия.

Третье — размытие доли. При дополнительном выпуске или переводе в другой номинал доли пересчитывают вручную, и накопленные ошибки округления съедают часть открытого баланса. Учёт долей участников должен вестись от общей эмиссии, а не от текущего баланса кошелька.

Каждая из этих точек проверяется отдельным сценарием на тестовой сети — разбираем, как это закрывается в контракте и в правах доступа.

Разблокировка по графику: доли, сроки, снятие ручных операций

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

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

Прозрачность аллокации — следствие того же: в любой момент видно размер доли, объём уже полученного и остаток до следующей точки. Сверка с таблицей или выгрузкой больше не нужна, потому что источник истины один и он же исполняет правила.

Ручные операции уходят из процесса целиком — не нужно готовить списки, сверять адреса, подписывать переводы и вести журнал. Вместе с ними снимается целый класс ошибок: двойное начисление, пропущенный участник, неверная дата старта. Предсказуемость разблокировки становится измеримой — доля операций, прошедших без вмешательства человека, стремится к ста процентам.

Перед запуском прогоняем сценарии на тестовой сети: сумма всех долей обязана точно совпасть с пулом, границы периодов — с календарём, а повторный вызов в тот же день не даёт второго начисления. Это и превращает график из намерения в набор проверок, которые можно пересчитать в любой момент.

Форматы вестинга токенов: сравнение режимов и ограничений

Режим разблокировки выбирают не по вкусу, а по тому, кого он удерживает в проекте и что происходит при досрочном выходе участника. Контракт фиксирует правила один раз: после публикации в сети график нельзя переписать без нового контракта и переноса остатков, поэтому цена ошибки здесь выше, чем кажется на этапе планирования.

Ниже — живые альтернативы, между которыми выбирают на старте. Совмещать режимы в одном контракте можно, но каждая дополнительная ветка логики — отдельный сценарий для проверки и потенциальная точка отказа.

Ревоцируемая схема требует дисциплины: право отзыва вешаем на адрес основателя, а возвращённые токены уходят на отдельное хранилище — иначе одним вызовом можно вернуть и сразу вывести весь пул. В кастодиальной схеме ключи от кошелька-держателя не должны быть у той же стороны, что управляет проектом, иначе конструкция теряет смысл.

Расчёт ведём до кода: сумма, срок, наличие паузы, число бенефициаров и допустимость отзыва. Если после публикации правила нужно менять, это всегда миграция остатков в новый контракт.

Порядок работ: от разбора задачи до передачи контракта

Маршрут строим так, чтобы на каждом этапе было ясно, что именно проверяем и какой артефакт остаётся у заказчика. Код не пишем, пока не зафиксированы правила эмиссии, длительность блокировок и то, кто вправе менять расписание после запуска.

1. Разбор задачи. Фиксируем категории получателей, период ожидания, шаг начислений и условия досрочного выхода. На выходе — согласованная модель вестинга токенов и перечень ролей с правами.
2. Схема распределения долей. Считаем доли адресов и пулов на реальных числах эмиссии, проверяем, что сумма сходится и остаток не зависает на контракте.
3. Реализация и модульные тесты. Собираем контракт на проверенных библиотеках: за основу берём OpenZeppelin с его готовыми механизмами доступа и пауз.
4. Проверка сценариев. Прогоняем досрочное получение, повторный запрос выплаты, смену прав, паузу и экстренную остановку. Отдельно — границы: нулевой адрес, нулевая сумма, обращение после истечения срока.
5. Внешний аудит кода. Независимая команда проверяет логику до выкладки в основную сеть; замечания разбираем, правки вносим, отчёт остаётся публичным артефактом.
6. Передача прав администратора. Роли уходят заказчику через мультиподпись и задержку исполнения, ключи остаются у него. Показываем, как менять параметры расписания и как отозвать роль.

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

Что передаём на руки: конфигурации, схемы, регламенты

Передаём не «код и объяснения на словах», а комплект, по которому ваша команда работает без нас: выпускает аллокацию, проводит разблокировку, разбирает инцидент. Каждый артефакт привязан к конкретному действию, а не лежит «на всякий случай».

• Документация по контракту: роли, параметры, события начисления, блокировки и разблокировки — с примерами чтения журнала, чтобы разбор операций не требовал обращения к авторам кода.
• Схема аллокации: доли по категориям держателей, период ожидания, шаг и календарь разблокировки — таблицей, сходящейся с параметрами контракта до последней записи.
• Правила доступа: кто какой ролью выпускает доли, меняет получателя и приостанавливает выплаты; ключи собраны по схеме мультиподписи, единой точки отказа нет.
• Регламент начислений: порядок согласования новых получателей и изменения долей, лимиты на одну операцию, кто подтверждает и в какой срок.
• Инструкция для команды: пошаговые действия по разблокировке, сверке балансов и отзыву ошибочного адреса — с ожидаемым результатом каждого шага.
• Политики отката и безопасности: отзыв роли, порядок действий при компрометации ключа, приостановка выплат без потери уже начисленного.
• Отчёт об аудите: перечень находок, что исправлено, что осознанно принято — как аргумент для внутреннего контроля и разговора с инвесторами.

Кейс: рассинхрон разблокировки и размытие доли основателя

Что было до

Вестинг жил в двух местах: расписание разблокировки — в модуле распределения, баланс участника — в токен-контракте. Между обновлением графика и переводом проходила отдельная транзакция, и в этом окне основатель выводил больше, чем допускала его доля. Сверка отчётов расходилась на единицы учёта при каждой докапитализации пула, а находили это уже на стороне участников.

Что изменили

Расписание и баланс свели в один контракт: изменение доли и перевод применяются одной транзакцией, промежуточного состояния не существует. Расчёты вынесли в Vesting Ledger — модуль, который вычисляет доступный объём из неизменяемого графика и отдаёт его контракту.

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

Чем отличается кастодиальная схема хранения от некастодиальной?

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

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

Риски хранения смещаются вместе с контролем. В кастодиальной схеме узкая точка — счёт хранителя: компромисс его ключа или блокировка на стороне площадки останавливают весь пул. В некастодиальной потеря ключа затрагивает долю одного получателя, а восстановление доступа проектируют заранее — мультиподпись и резервные держатели.

Объём работ тоже различается. В кастодиальном варианте больше интеграции: роли оператора, ограничения на досрочный перевод, журнал событий и сверка остатков с хранителем. В некастодиальном центр тяжести — ключевая инфраструктура и аудит кода: график нельзя обойти, выпуск не превысит зарезервированный пул.

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

Технические сомнения: аудит, обновления, права доступа

Перед запуском вестинга сомнения обычно одни и те же: сколько занимает аудит, что будет, если условия придётся менять, и у кого останутся права после передачи управления. Ниже — короткие ответы; полный разбор идёт уже по вашей схеме.

Что будет, если условия изменятся или управление передадут?

График, размер порций и список получателей выносим в параметры, а не в тело логики. Изменение проходит отдельной операцией с задержкой и событием в журнале, чтобы получатели узнавали о нём заранее; уже начисленные доли не переписываем — только будущие периоды. После запуска права администратора сужаются: изменение параметров и выпуск остаются за мультиподписью из нескольких ключей. Передача управления идёт в два шага — назначение нового распорядителя и его подтверждение, поэтому доступ не теряется из-за опечатки в адресе.

Обсудим задачу: состав работ и что нужно с вашей стороны

Чтобы оценка сроков опиралась на факты, а не на допущения, соберём вводные по токеномике и правам доступа. Чем конкретнее исходные данные, тем меньше уточняющих итераций до старта работ — обычно это экономит неделю-две на переписке.

Что нужно с вашей стороны:

• График вестинга токенов: кому и какие доли разблокируются, есть ли период ожидания, шаг и периодичность выплат, поведение при пропущенном срезе.
• Параметры токена: стандарт, общий объём выпуска, делимость, нужно ли переносить уже выпущенные балансы.
• Роли и права: кто администрирует контракт, какие параметры допускают изменение, нужна ли мультиподпись и задержка исполнения.
• Среды и сети: где проходит проверка, где будет боевое развёртывание, требования к подтверждениям транзакций.
• Учёт и мониторинг: какие события должны попадать в отчётность, нужны ли выгрузки для бухгалтерии и аналитики.
• Ограничения: регуляторные требования, юрисдикции держателей, запрет на передачу прав третьим лицам.
• Сроки: дата, к которой контракт должен быть готов, привязка к продаже или выходу на биржу.

На основе этих данных собираем состав работ, фиксируем этапы и объём аудита. Опишите задачу — вернёмся с оценкой сроков и планом внедрения, включая порядок развёртывания и приёмки.