График разблокировки показывает, когда токены команды, инвесторов, казначейства и программ экосистемы могут перейти в обращение. Красивого календаря на аналитическом сайте недостаточно: он может опираться на старую документацию, не учитывать изменение контракта или объединять разные категории в одну дату.
Надёжная проверка связывает четыре уровня: официальный адрес токена, опубликованную токеномику, конкретные vesting-контракты и фактические onchain-переводы. Цель не в том, чтобы угадать давление на цену, а в том, чтобы понять, кто получает право распоряжаться каким объёмом и когда.
Vesting, lockup и unlock – не одно и то же
Lockup запрещает перемещение актива до определённого момента. Vesting постепенно формирует право получателя на токены по заданной кривой. Unlock – момент, когда заблокированная часть становится доступной для release или уже поступает на обычный кошелёк.
После cliff может разблокироваться крупный первый транш, а остаток – выходить линейно. В другой модели токены начисляются линейно с первого дня, но получить их можно только после cliff. В третьей модели казначейство просто хранит токены на multisig без программного vesting. Одинаковая диаграмма способна скрывать разные права.
Шаг 1. Проверьте адрес токена и сеть
Начните с канонического контракта токена. Сверьте сеть, адрес и decimals с официальными материалами проекта и несколькими внутренними страницами экосистемы. Одинаковый ticker не доказывает подлинность: злоумышленник может выпустить токен с тем же именем.
В обозревателе изучите total supply, minting rights, proxy и список крупных holders. Если token contract обновляемый, текущая логика может находиться в implementation, а права изменения – у proxy admin. Методика такой проверки описана в материале о proxy admin и implementation.
Шаг 2. Разложите аллокации по категориям
Выпишите total supply и доли команды, инвесторов, community, treasury, incentives, airdrop и liquidity. Для каждой категории нужны старт, cliff, продолжительность, форма выхода и получатель. Проценты без абсолютного количества могут вводить в заблуждение, если токен допускает mint или burn.
Отдельно отметьте circulating supply на момент запуска. Он не равен сумме всех unlocked allocation: часть токенов может лежать в treasury, быть выделена для market making или технически доступна, но не переведена. И наоборот, wrapped-версии и межсетевые представления нельзя повторно прибавлять к основному supply.
Базовый порядок чтения распределения разобран в статье как читать токеномику до покупки токена.
Шаг 3. Найдите vesting-контракты и кошельки
Адреса можно искать в документации token generation event, governance proposals, deployment manifests и транзакциях первоначального распределения. В holders list отметьте контракты с крупными балансами. Затем проверьте их bytecode, verified source, creator и первую транзакцию пополнения.
Не каждый крупный контракт является vesting. Это может быть bridge, staking pool, exchange custody, liquidity pool или treasury. Название метки в обозревателе – подсказка, а не доказательство. Функции контракта и поток средств важнее подписи сервиса.
Часть проектов создаёт отдельный контракт на каждого beneficiary. Другие используют один distributor с Merkle proofs или общим расписанием. Если токены остаются на multisig и переводятся вручную, нужно изучать signers, threshold, spending modules и историю исполнения.
Шаг 4. Прочитайте параметры onchain
У типового VestingWallet полезны методы owner, start, duration, end, released, releasable и vestedAmount. Owner обычно является beneficiary и может вызвать release уже начисленной части. В расширенной реализации появятся cliff, список токенов, отмена или несколько получателей.
Преобразуйте Unix timestamp в UTC и локальное время, но храните исходное значение. Уточните, считается ли duration от start или от окончания cliff. Проверьте формулу в source code: одинаковые имена функций не гарантируют одинаковую кривую.
Стандартная линейная модель возвращает ноль до start, затем долю пропорционально прошедшему времени и весь объём после end. Cliff-расширение может возвращать ноль до cliff, после чего показать сразу накопленную с start часть. Поэтому первый release после cliff иногда заметно больше обычного дневного начисления.
Как рассчитать объём разблокировки
Для линейного vesting сначала определите историческую allocation: текущий баланс контракта плюс уже released amount. Затем вычислите долю времени между start и end. Из vested amount вычтите released – получится доступный сейчас releasable объём.
Пример без привязки к конкретному токену: контракт получил 12 млн единиц, годовой cliff закончился, а линейный период длится ещё три года. Через шесть месяцев после cliff могло начислиться либо 2 млн, если линейная часть начинается после cliff, либо 6 млн, если начисление считается с первоначального start. Ответ определяется кодом, а не словом «годовой cliff».
Для ступенчатого графика составьте таблицу каждого tranche: timestamp, объём, beneficiary и транзакция исполнения. Не округляйте месяцы до 30 дней, пока контракт использует секунды или конкретные календарные даты.
Шаг 5. Проверьте уже выпущенные токены
Сопоставьте released с событиями release и переводами ERC-20. Проследите, куда ушли токены: на личный кошелёк, multisig, exchange deposit, staking или другой vesting contract. Разблокировка не означает немедленную продажу, но после неё меняется право распоряжения.
Если release event есть, а обычного transfer не видно, проверьте нестандартную реализацию или внутренний учёт. Если баланс уменьшился без ожидаемого события, изучите upgrade, rescue function, migration и token mechanics. Для rebase-токена изменение баланса вообще может происходить без обычного перевода.
Концентрацию связанных адресов стоит анализировать вместе, а не по одному holder. Практический чек-лист есть в материале о проверке крупнейших держателей.
Шаг 6. Проверьте права администратора
Vesting contract может быть immutable, pausable, revocable или upgradeable. Найдите owner, admin, multisig, timelock и роли. Особенно важны функции изменения beneficiary, start, duration, schedule, token address, implementation и emergency withdrawal.
Если контракт можно отменить, уточните судьбу уже vested и ещё locked части. Если owner transferable, beneficiary способен продать право на будущие токены вместе с контролем над vesting wallet. Это значит, что формально locked allocation не всегда экономически непередаваема.
Проверьте, может ли проект пополнить vesting после начала. В распространённой реализации новые активы следуют расписанию так, словно лежали с самого start, и часть свежего депозита становится доступна немедленно. Простое сравнение текущего баланса с первоначальной allocation тогда даст ошибку.
Особые случаи, которые ломают простую диаграмму
- Rebase. Баланс меняется автоматически, поэтому фиксированная кривая может дать другой экономический результат.
- Transferable beneficiary. Право на будущий release можно передать новому owner.
- Proxy upgrade. Администратор способен заменить формулу после публикации исходного графика.
- Multichain supply. Locked tokens и их wrapped-представления легко посчитать дважды.
- Manual treasury. Публичная дата является обещанием, а не ограничением смарт-контракта.
- Market maker loan. Токены находятся в обращении на условиях займа, хотя формально относятся к treasury.
- Claim window. Unlock создаёт право получить токены, но фактический supply растёт по мере claim.
Как собрать собственный календарь
- Зафиксируйте token contract, chain, total supply и дату проверки.
- Составьте список категорий и всех известных vesting addresses.
- Для каждого адреса запишите beneficiary, allocation, start, cliff, end и формулу.
- Добавьте released, releasable, текущий balance и destination последних переводов.
- Отдельно отметьте proxy, admin, multisig threshold, timelock и право отмены.
- Рассчитайте будущие дневные или месячные изменения без двойного учёта.
- Перед значимой датой повторите onchain-проверку: график и владельцы могли измениться.
Сохраняйте transaction hashes и block numbers, а не только скриншоты. Тогда расчёт можно воспроизвести на конкретном состоянии цепочки. Если данные аналитического сервиса расходятся с контрактом, сначала проверьте сеть, decimals и methodology, а затем опирайтесь на исполняемое onchain-правило.
Что unlock говорит о цене
Крупный unlock увеличивает потенциальное предложение, но не предсказывает автоматическую продажу. Команда может продолжить держать токены, инвестор – застейкать их, а treasury – направить в incentives. На цену одновременно влияют ликвидность, спрос, market maker, деривативы и ожидания рынка.
Полезнее оценивать отношение разблокируемого объёма к circulating supply и реальному объёму торгов, а также концентрацию получателей. Даже небольшой процент total supply может быть существенным для тонкого рынка. И наоборот, большой формальный unlock может почти не выйти из treasury.
Красные флаги
- опубликованы проценты, но нет адресов и исполняемых ограничений;
- vesting contract не верифицирован и не объяснён deployment;
- admin может немедленно менять implementation или выводить locked tokens;
- несколько категорий контролирует один multisig без timelock;
- circulating supply не согласуется с holder balances и bridge reserves;
- график показывает месяцы, а контракт содержит один крупный cliff release;
- после «продления vesting» onchain-параметры остались прежними.
Итог
Проверка vesting начинается не с календаря, а с контракта токена и адресов распределения. Нужно прочитать start, cliff, duration, формулу, released и releasable, затем проследить фактические переводы и полномочия администратора.
Документ проекта объясняет намерение, а onchain-код показывает исполнимое ограничение. Только их совместная проверка позволяет отличить реальную блокировку от обещания, не посчитать supply дважды и понять, когда именно получатель приобретает возможность распоряжаться токенами.
