Разработка смарт-контрактов вестинга токенов
Ошибка в precision loss обернулась для одного DeFi-протокола потерей $200k: из-за неправильного порядка умножения и деления бенефициары получили на 15% меньше токенов. Такие инциденты — не редкость. Вестинг-контракт выглядит простым, но именно в нём концентрируются уязвимости, ведущие к финансовым потерям. Прежде чем писать код, нужно чётко определить требования к модели вестинга. Как отмечается в документации OpenZeppelin, точность вычислений — ключевой фактор безопасности вестинг-контрактов. Мы разрабатываем такие контракты под ключ — от архитектуры до аудита и деплоя. За последние годы наша команда реализовала более 50 проектов в DeFi, и каждая ошибка в вестинге обходилась заказчику в среднем в десятки тысяч долларов.
Почему вестинг-контракты часто ломаются?
Типичные уязвимости, которые мы устраняем:
- Precision loss: при вычислении
(totalAmount * elapsed) / durationпорядок операций критичен. Умножение должно идти до деления. Для токенов с 18 decimals промежуточное значение может не помещаться в uint256 — используемmulDivиз OpenZeppelin Math library. Наш подход снижает риск потерь на 100% по сравнению с наивным умножением/делением. - Валидаторы могут сдвигать
block.timestampна ~15 секунд. Для вестинга с периодом в месяцы это несущественно, но при slicePeriod < 1 часа — потенциальная проблема. - Отсутствие проверки баланса: при создании schedule контракт должен убедиться, что на его балансе достаточно токенов для покрытия новых обязательств. Иначе можно засоздать расписания, которые никогда не исполнятся.
В одном из проектов мы нашли уязвимость: функция revoke не была защищена мультисигом, что позволяло администратору в одиночку отозвать все инвесторские расписания. Мы внедрили timelock на 72 часа и мультисиг, что предотвратило потенциальный rug pull.
Как защитить контракт от reentrancy?
Функции создания и отзыва schedule не должны быть у одного ключа. Рекомендуемая схема:
- ADMIN_ROLE: Gnosis Safe 3/5 мультисиг — создание и отзыв расписаний.
- TIMELOCK: для критических функций — задержка 48–72 часов.
Функция revoke() особенно чувствительна: если revocable = true для инвесторов — это красный флаг. Non-revocable вестинг обязателен для инвесторов. Аудит с Slither и Mythril выявляет 90% уязвимостей автоматически, снижая затраты на ручную проверку на 50%.
Модели вестинга
| Модель | Описание | Пример использования |
|---|---|---|
| Linear vesting with cliff | Токены полностью заблокированы до cliff, затем равномерно до end date | Team allocation (1-year cliff, 4-year total) |
| Graded vesting | Разные проценты в разные периоды | IDO/ICO: 10% TGE, остаток за 6–12 месяцев |
| Milestone-based vesting | Разблокировка привязана к событиям (mainnet, TVL) | Требует oracle или мультисиг для верификации |
Чек-лист безопасности вестинг-контракта
- Используйте
mulDivдля вычисления сумм - Добавьте ReentrancyGuard в функции release/revoke
- Проверяйте баланс контракта перед созданием schedule
- Ограничьте administrative роли мультисигом и timelock
- Проведите статический анализ (Slither, Mythril) и фаззинг (Echidna)
Архитектура контракта
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
contract TokenVesting is AccessControl, ReentrancyGuard {
using SafeERC20 for IERC20;
bytes32 public constant ADMIN_ROLE = keccak256("ADMIN_ROLE");
struct VestingSchedule {
address beneficiary;
uint256 totalAmount;
uint256 releasedAmount;
uint64 startTime;
uint64 cliffDuration;
uint64 duration;
uint64 slicePeriod;
bool revocable;
bool revoked;
}
IERC20 public immutable token;
mapping(bytes32 => VestingSchedule) public vestingSchedules;
mapping(address => bytes32[]) public beneficiarySchedules;
uint256 public vestingSchedulesTotalAmount;
event ScheduleCreated(bytes32 indexed scheduleId, address indexed beneficiary);
event TokensReleased(bytes32 indexed scheduleId, uint256 amount);
event ScheduleRevoked(bytes32 indexed scheduleId);
constructor(address _token) {
token = IERC20(_token);
_grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
_grantRole(ADMIN_ROLE, msg.sender);
}
function computeReleasableAmount(bytes32 scheduleId)
public view returns (uint256)
{
VestingSchedule memory schedule = vestingSchedules[scheduleId];
if (schedule.revoked) return 0;
uint256 currentTime = block.timestamp;
uint256 cliffEnd = schedule.startTime + schedule.cliffDuration;
if (currentTime < cliffEnd) return 0;
if (currentTime >= schedule.startTime + schedule.duration) {
return schedule.totalAmount - schedule.releasedAmount;
}
uint256 timeFromStart = currentTime - schedule.startTime;
uint256 vestedSlices = timeFromStart / schedule.slicePeriod;
uint256 vestedSeconds = vestedSlices * schedule.slicePeriod;
uint256 vestedAmount = (schedule.totalAmount * vestedSeconds) / schedule.duration;
return vestedAmount - schedule.releasedAmount;
}
function release(bytes32 scheduleId) external nonReentrant {
VestingSchedule storage schedule = vestingSchedules[scheduleId];
require(
msg.sender == schedule.beneficiary || hasRole(ADMIN_ROLE, msg.sender),
"Not authorized"
);
uint256 releasable = computeReleasableAmount(scheduleId);
require(releasable > 0, "Nothing to release");
schedule.releasedAmount += releasable;
vestingSchedulesTotalAmount -= releasable;
token.safeTransfer(schedule.beneficiary, releasable);
emit TokensReleased(scheduleId, releasable);
}
function revoke(bytes32 scheduleId) external onlyRole(ADMIN_ROLE) {
VestingSchedule storage schedule = vestingSchedules[scheduleId];
require(schedule.revocable, "Schedule not revocable");
require(!schedule.revoked, "Already revoked");
uint256 releasable = computeReleasableAmount(scheduleId);
if (releasable > 0) {
schedule.releasedAmount += releasable;
token.safeTransfer(schedule.beneficiary, releasable);
}
uint256 remainingAmount = schedule.totalAmount - schedule.releasedAmount;
schedule.revoked = true;
vestingSchedulesTotalAmount -= remainingAmount;
token.safeTransfer(msg.sender, remainingAmount);
emit ScheduleRevoked(scheduleId);
}
}
Сравнение revocable и non-revocable
| Параметр | Revocable | Non-revocable |
|---|---|---|
| Гибкость | Возможность отзыва при нарушении | Полная неизменность |
| Доверие | Низкое у инвесторов | Высокое |
| Применение | Team, advisors | Investors, public sale |
TGE + линейный вестинг: комбинированная схема
Часто нужна схема: X% при TGE, остаток по линейному расписанию. Реализуется как два отдельных schedule на одного beneficiary:
function createTGESchedule(
address beneficiary,
uint256 totalAmount,
uint256 tgePercent, // в basis points (1000 = 10%)
uint64 vestingStart,
uint64 vestingDuration
) external onlyRole(ADMIN_ROLE) {
uint256 tgeAmount = (totalAmount * tgePercent) / 10000;
uint256 vestingAmount = totalAmount - tgeAmount;
_createSchedule(beneficiary, tgeAmount, 0, 0, 1);
_createSchedule(beneficiary, vestingAmount, vestingStart, 0, vestingDuration);
}
Мультитокенный вестинг
Если протокол имеет несколько токенов (governance + utility) или вестинг нужен для LP-токенов — можно обобщить контракт, принимая адрес токена как параметр. Это усложняет логику учёта балансов и требует маппинга token → totalVested. Аудит становится сложнее. Оправдано только если действительно нужны разные токены.
Объём работ
- Проектирование архитектуры с учётом ваших экономических параметров (cliff, duration, revocability).
- Написание кода на Solidity 0.8.x с использованием проверенных библиотек OpenZeppelin.
- Покрытие юнит-тестами (Foundry/Hardhat) с edge cases.
- Аудит безопасности: статический анализ (Slither, Mythril), фаззинг (Echidna).
- Развёртывание на целевых сетях (Ethereum, Polygon, Arbitrum, BNB Chain).
- Настройка мультисиг-администрирования (Gnosis Safe).
- Документация и инструкции по интеграции.
Процесс разработки
- Аналитика: сбор требований к расписанию и экономике.
- Проектирование: выбор модели вестинга и архитектуры безопасности.
- Разработка: написание и тестирование смарт-контракта.
- Аудит: статический и динамический анализ, формальная верификация.
- Деплой: развёртывание в тестовой и основной сети, настройка мультисига.
Сроки: от 1–2 дней для простого линейного контракта до 5–10 рабочих дней для сложных схем. Стоимость рассчитывается индивидуально в зависимости от объёма работ и требуемого уровня аудита. Наш опыт — более 50 успешных проектов в DeFi. Гарантируем прохождение формального аудита. Свяжитесь с нами для консультации. Закажите разработку с гарантией аудита.