Результат:
Плюсы:
- Токены будут храниться на кошельке пользователя.
- Не будет проблем с отображением баланса.
- Изящное децентрализованное решение.
Минусы:
- Пользовательский опыт: покупатели должны понимать концепцию токена вестинга и процесс выкупа. Необходима хорошая документация, гайды и удобные интерфейсы.
- Используется подход выплат pull. Это значит, что бенефициару потребуется выполнить две транзакции: покупка и клейм.
- Несмотря на то, что покупатель будет владеть токенами-акциями, он не сможет ничего с ними сделать, кроме как обменять на целевой токен. Любая транзакция будет фейлиться.
- Самый главный минус - это высокая сложность реализации подобной системы, которая далеко не всегда необходима.
3. Вестинг на отдельном смарт-контракте
Самый популярный подход к реализации вестинга в криптовалютных проектах заключается в размещении логики вестинга в отдельном смарт-контракте. В этом подходе существует масса различных вариантов, но я опишу только один из них, который мы опробовали на реальном проекте. Основная идея взята из предыдущего варианта, но реализация сильно отличается.
Тут важно внедрить два понятия, чтобы не было путаницы:
- Базовый токен - это основной токен проекта или целевой токен, который покупает пользователь для которого собственно и нужен вестинг.
- Share токен - это токен-пустышка, который мы выдаем пользователю как ваучер, который ему нужно будет погасить чтобы забрать базовый токен по курсу 1:1.
Наша реализация вестинга представляет собой комбинацию нескольких смарт-контрактов:
- смарт-контракт приватных продаж базового токена
- смарт-контракт share-токена (с логикой вестинга)
- смарт-контракт для создания share-токенов с установкой расписания
Контракт приватных продаж. Его основная задача -- продажа токенов через вайтлист. Также, он отвечает за управление параметрами продажи и прием платежей. Но, самое важное для нас в данном случае -- он отвечает за чеканку share-токенов покупателям. Вся фишка в том, что в момент продажи мы переводим покупаемые токены не пользователю, а на смарт-контракт share-токена, где они блокируются. Пользователю в свою очередь чеканятся share-токены. Пример такого смарт-контракта я здесь приводить не буду, т.к. фактически это может быть даже обычный EOA, все, что от него потребуется - выдать апрув на базовый токен для share-токена, после чего можно будет его минтить.
В дальнейшем на этом контракте он сможет склеймить базовый токен, при этом ему нужно будет сжечь свои share-токены, но сделать это можно будет в соответствии с установленным расписанием вестинга.
Тут важно упомянуть, что устанавливается только время начала продаж, а временем окончания будет время начала вестинга, которое было установлено на контракте share-токена. Если время старта продаж еще можно поменять, как и некоторые другие параметры продажи, то время окончания поменять не выйдет. Это сделано для того чтобы пользователи были защищены от манипуляций. Их средства будут заблокированы, а вывести их сможет только сам пользователь, когда сожжет свои share-токены. При этом один и тот же share-токен может использоваться в нескольких раундах продаж, пока не начнется сам вестинг.
Контракт share-токена. Или вестинг-токен. Он может носить любое название. Главное -- понимать суть: это токен-пустышка. Его нельзя будет продать или перевести другому кошельку. Запрещены все переводы этого токена и у него нет никакого управления со стороны админов. У него четыре основные задачи:
- чеканить;
- сжигать;
- хранить базовый токен;
- рассчитывать количество заблокированных и разблокированных базовых токенов.
Минтером тут выступает контракт приватных продаж (напомню, что это может быть любой адрес у которого есть базовый токен). А сжигать эти токены будет сам пользователь, когда придет забирать свой базовый токен. Вывести токены с контракта просто так никто не сможет, это надежное хранилище.
Вот простой пример смарт-контракта VestingToken.
Такой подход позволяет создавать несколько share-токенов под разные раунды продаж. У каждого share-токена будет свое расписание вестинга. Плюс, он будет выступать пулом для базовых токенов с раунда продаж. Такой подход дал нам даже больше гибкости чем мы думали изначально, но об этом чуть позже.
На контракте реализована очень гибкая возможность установки расписания вестинга. Можно задавать дату и время обычным timestamp (т.е. с точностью до секунды), устанавливать сколько угодно периодов выплат с разными интервалами. Так же, можно очень гибко настраивать и проценты выплат в каждом интервале. Единственное условие - чтобы в сумме было 100%. Это дает возможность использовать самые разнообразные сценарии и графики наделения правами.
Вот к примеру расписание, которое можно установить. Здесь представлен вестинг на 2 года с периодом cliff 6 месяцев и меняющимся процентным соотношением выплат (последние два месяца выплачивается по 10%, а все предыдущие по 5%):