TGE в криптовалюте: что это, как проходит запуск токена и что проверить

TGE в криптовалюте — это Token Generation Event, то есть событие, вокруг которого проект переводит будущий токен из описания в документах в реально существующий цифровой актив и начинает первоначальное распределение. На практике термин не закреплён единым блокчейн-протоколом, поэтому два проекта могут вкладывать в TGE немного разный набор действий. У одного контракт создаётся в тот же день, у другого он развёрнут заранее и TGE означает начало claim и выдачу первых доступных токенов, у третьего к этой дате привязаны старт обращения и отсчёт графиков разблокировки. Поэтому полезнее воспринимать TGE не как одну кнопку, а как контрольную точку запуска, которую нужно разложить на проверяемые события.

Для читателя важна именно эта проверяемость. Красивый анонс «TGE сегодня» ещё не отвечает на вопросы, какой контракт является официальным, сколько единиц уже создано, сохраняется ли право дополнительного выпуска, кому принадлежат крупные адреса, какая доля реально доступна участникам, что остаётся заблокированным и какой механизм используется для claim. Часть ответов находится в документации проекта, часть — в публичном блокчейне, а часть требует сопоставить эти два слоя. Если цифры в презентации и наблюдаемое on-chain состояние расходятся, разбираться нужно до любых действий с токеном.

Эта статья посвящена жизненному циклу запуска токена: от подготовки контракта и allocation до initial unlock, circulating supply, FDV, claim, проверки mint authority и первых дней после TGE. Вестинг рассматривается только там, где он связан с запуском; подробная механика cliff и последующих разблокировок остаётся отдельной темой. Здесь также не будет советов по выбору торговых площадок или маршрутов покупки. Задача практичнее: научиться читать TGE как набор фактов, отличать токен от его рекламы и понимать, что именно изменилось в сети в заявленный день запуска.

Что такое TGE и почему одного определения недостаточно

Token Generation Event — отраслевой термин, а не команда блокчейна

Расшифровка TGE проста: Token Generation Event. Сложность начинается после расшифровки, потому что ни Ethereum, ни Solana, ни большинство других сетей не имеют универсальной транзакции с названием TGE. Блокчейн видит конкретные действия: развёртывание контракта, создание mint account, выпуск единиц, перевод на адреса, изменение authority, блокировку в специальных контрактах. Слово TGE объединяет эти действия на уровне проекта и коммуникации. Отсюда первое правило: не искать в обозревателе кнопку «TGE», а выяснять, какие on-chain события проект связывает с этой датой.

Такой подход защищает от ложной точности. Если токен был технически создан за неделю до публичного запуска, неверно утверждать, что TGE обязательно равен deployment transaction. Если контракт появился сегодня, но распределение начнётся завтра, одного deployment тоже недостаточно, чтобы считать экономический запуск завершённым. Рабочее определение должно учитывать контекст: TGE — объявленная точка перехода к существующему и распределяемому токену, а доказательства этого перехода состоят из нескольких независимых объектов.

TGE может состоять из нескольких дат

У проекта нередко есть целая цепочка дат: deployment, mint, snapshot, claim start, initial unlock, начало передачи между пользователями, публикация адреса контракта, запуск governance. В маркетинговом календаре всё это может быть сведено к одному дню, но для проверки полезно записать каждую дату отдельно. Например, snapshot определяет право на будущий airdrop, но сам по себе не создаёт токен. Claim start делает распределение доступным, но общий supply мог существовать заранее. Начало передачи показывает, что токен технически движется между адресами, но не объясняет, какая часть предложения заблокирована.

Если проект переносит TGE, важно понять, что именно перенесено. Иногда меняется только публичный claim, а контракт уже существует. Иногда откладывается само создание mint. Иногда токен уже создан, но transfer ограничен до отдельного момента. Формулировка «TGE перенесён» без расшифровки недостаточна для анализа. Нужен список состояний: что уже произошло, что осталось неизменным и какой следующий проверяемый шаг заявлен командой.

Почему TGE не равно просто появлению цены

Первая видимая цена — рыночный сигнал, а не доказательство устройства токена. Цена может появиться после того, как токен был создан и распределён, или почти одновременно с запуском. Она ничего не говорит сама по себе о mint authority, скрытых ограничениях transfer, доступном float или доле, которая станет доступна позже. Техническая идентичность токена определяется сетью и адресом контракта либо mint, а не тикером, логотипом и числом на ценовом графике.

Поэтому полезно разделять два вопроса. Первый: «Какой токен действительно запустил проект?» — на него отвечают официальный идентификатор и on-chain данные. Второй: «Как рынок оценивает доступную часть?» — это уже цена, ликвидность и объём доступного предложения. Смешение этих вопросов порождает типичную ошибку: человек видит цену и предполагает, что весь заявленный total supply уже свободно обращается. На TGE это особенно часто неверно.

TGE не гарантирует качество проекта

Факт генерации токена доказывает только существование определённого on-chain объекта и связанных операций. Он не подтверждает, что код прошёл независимую проверку, продукт работает, права владельцев понятны, команда не может менять критические параметры, обещанные utility-функции реализованы, а распределение соответствует заявленному. Даже полностью корректный ERC‑20 или SPL-токен может быть экономически неудачным или управляться чрезмерно централизованно.

Поэтому TGE удобно использовать как момент усиленной проверки, а не как знак готовности. До запуска многие параметры существуют в виде обещаний; после появления токена часть из них становится наблюдаемой. Именно в этот момент можно сравнить обещанную эмиссию с фактическим supply, список allocation — с крупными адресами, правила mint — с authority, график распределения — с vesting-контрактами и первые claim — с реальными событиями в сети.

Что технически происходит с токеном вокруг TGE

На Ethereum токен обычно представлен смарт-контрактом

Для взаимозаменяемого токена в Ethereum и совместимых сетях часто используется интерфейс ERC‑20. Такой контракт хранит или предоставляет данные о balances и total supply, поддерживает transfers и allowances и создаёт события, по которым можно восстанавливать движение токена. Стандарт не определяет бизнес-модель проекта: один контракт может иметь фиксированный выпуск, другой — функцию дополнительного mint, третий — расширения с pause, blacklist или ролями администраторов. Поэтому одинаковый стандарт не означает одинаковый риск.

Во время проверки TGE важно смотреть дальше имени и символа. Два контракта способны использовать одинаковый тикер, одинаковое название и даже одинаковые decimals. Уникальным идентификатором остаётся адрес контракта в конкретной сети. Если проект публикует адрес, именно его нужно сопоставлять с on-chain кодом, supply и событиями. Копия с тем же названием не становится официальным токеном из-за похожего интерфейса.

Mint показывает создание единиц, но не их экономический статус

В ERC‑20 реализациях создание новых единиц обычно отражается увеличением total supply и событием Transfer от нулевого адреса. Это удобный технический след: можно увидеть, когда и сколько токенов появилось. Но слово «создано» не равно «циркулирует». Миллиард единиц может быть выпущен заранее и лежать на treasury, vesting или distribution contracts. Для рынка критичнее не общий созданный объём, а та часть, которая реально доступна публичным держателям и может двигаться без ограничений.

При фиксированном supply важно подтвердить, что право дополнительного выпуска действительно отсутствует или технически недоступно. При изменяемом supply нужно понять, кто контролирует mint и при каких условиях он может использоваться. Само наличие mint authority не делает токен автоматически плохим: некоторые модели предполагают регулярные emissions. Риск возникает, когда права администратора расходятся с заявленной экономикой либо не раскрыты пользователю.

В Solana идентификатором служит mint account

В Solana токен идентифицируется mint account. В нём хранятся общие параметры выпуска, включая supply, decimals и authority. Балансы пользователей находятся в отдельных token accounts, связанных с конкретным mint. Поэтому проверка запуска строится иначе по интерфейсу, но логика остаётся той же: установить официальный mint, проверить его параметры, понять, существует ли право нового выпуска, и только затем анализировать распределение по token accounts.

Если mint authority отсутствует, дополнительный выпуск средствами обычной mint-инструкции больше невозможен — это сильный технический факт о supply. Если authority сохранена, нужно определить контролирующий адрес или программу и сопоставить это с документацией. Отдельно может существовать freeze authority, позволяющая замораживать token accounts в рамках возможностей программы токенов. Такие полномочия нельзя выводить из логотипа или названия: они проверяются в состоянии mint.

Metadata и логотип не являются доказательством подлинности

Кошелёк может красиво отобразить название, символ и картинку, но визуальные данные легко скопировать. У поддельного токена может быть тот же тикер и даже текстовое описание. Надёжная проверка начинается с идентификатора сети: contract address для соответствующего EVM-токена или mint address для Solana. После этого уже можно использовать metadata как удобное представление, а не наоборот.

Это особенно важно в день TGE, когда поисковый спрос резко растёт и появляются копии. Если официальный адрес ещё не опубликован, отсутствие адреса — основание ничего не угадывать. Не нужно выбирать «самый похожий» контракт по названию, дате создания или числу держателей. Подлинность определяется связью с первичным источником проекта и согласованностью on-chain параметров, а не популярностью копии.

Tokenomics до TGE: какие числа нужно привести к одной системе

Max supply, total supply и circulating supply — разные множества

До запуска проекты часто показывают круговую диаграмму tokenomics, но она имеет смысл только вместе с определениями. Max supply — предполагаемый предельный объём, если такой предел вообще установлен. Total supply — количество уже существующих единиц за вычетом корректно учтённого burn по методике конкретного источника. Circulating supply — оценка той части, которая реально находится в публичном обращении. Эти множества могут сильно различаться в день TGE.

Например, проект может заявлять max supply один миллиард и сразу технически создать весь миллиард. Это ещё не означает миллиард в circulation. Если 600 миллионов находятся в долгом блокировании, 200 миллионов выделены treasury, 100 миллионов зарезервированы для программы будущих вознаграждений и только 100 миллионов доступны публичным держателям, стартовый float намного меньше total supply. Для понимания давления предложения нужно смотреть на распределение, а не на одну большую цифру.

Allocation отвечает на вопрос «кому предназначено», а не «кому уже доступно»

Allocation обычно делит supply по категориям: команда, разработчики, фонд, сообщество, ранние участники, treasury, incentives, ликвидность, grants и другие направления. Это бухгалтерская карта назначения. Она не сообщает автоматически, сколько токенов уже переведено, сколько можно перемещать и какие адреса контролируют allocation. Одна категория может быть разбита между десятками кошельков и контрактов с разными условиями.

Полезная проверка переводит проценты в абсолютные числа. Если категории указаны только процентами, умножьте их на выбранную базу и убедитесь, что сумма сходится. Затем отдельно отметьте initial unlock для каждой категории. Такая таблица быстро показывает, что «20% команде» и «20% команды доступно на TGE» — принципиально разные утверждения.

Initial unlock определяет доступность в стартовой точке

Initial unlock — доля allocation, которую можно использовать сразу в момент запуска или в близко определённую дату. Допустим, участнику выделено 1 000 000 токенов, а at TGE доступно 10%. Тогда стартово доступно 100 000 единиц, а остальные 900 000 подчиняются отдельному графику. Для каждой категории процент нужно применять к её allocation, а не автоматически к total supply.

Ошибки часто возникают из-за сокращённой записи вроде «10% TGE, 6m cliff, 18m linear». Неясно, 10% относится ко всему supply или к конкретной allocation, включается ли initial unlock в последующий linear schedule и с какой даты считается cliff. Хорошая документация даёт формулу или таблицу; плохую нельзя «додумывать» по привычному шаблону.

Treasury и reserves требуют отдельного статуса

Токены treasury могут быть технически разблокированы, но не считаться публичным float по методике аналитического сервиса. И наоборот, токены могут находиться на обычном адресе без on-chain timelock, хотя проект обещает использовать их только по governance-решениям. Это показывает разницу между техническим ограничением и организационным обещанием. Для анализа нужно записывать оба слоя.

Если крупная доля хранится на адресе, контролируемом несколькими администраторами, полезно выяснить модель управления: обычный ключ, multisig, timelock, DAO-execution или специализированный custody. Чем больше влияние адреса на supply, тем важнее прозрачность полномочий. TGE — удобная точка для фиксации стартового состояния, чтобы последующие движения можно было сравнивать с исходной картой.

Initial distribution: как токены попадают к первым держателям

Прямой transfer и claim создают разный on-chain след

Первоначальное распределение может происходить прямыми переводами на заранее известные адреса или через claim contract, где пользователь сам инициирует получение. В первом случае distribution wallet отправляет токены адресатам, и Transfer events появляются без действий получателя. Во втором случае право может быть записано в Merkle tree, контракте или иной структуре, а фактический баланс возникает только после успешного claim. Эти модели нельзя сравнивать только по размеру allocation.

Для claim важно различать eligible, claimable и claimed. Eligible означает право участвовать по правилам snapshot. Claimable — объём, который уже разрешено получить сейчас. Claimed — то, что пользователь действительно забрал. Если 100 миллионов предназначены airdrop, но к текущему моменту claimed только 40 миллионов, реальный распределённый объём отличается от headline allocation.

Claim не должен требовать секретов кошелька

Нормальный on-chain claim может потребовать подключить кошелёк и подписать понятную транзакцию, но ему не нужна seed-фраза или private key в веб-форме. Эти секреты используются кошельком локально для подписи и не передаются проекту. Просьба ввести recovery words для «активации TGE», «синхронизации allocation» или «разблокировки claim» — критический признак мошенничества.

Перед подписью нужно проверить домен, сеть, contract address, вызываемую функцию и ожидаемое изменение состояния. Если интерфейс просит unlimited approval для постороннего токена, вызывает неизвестный контракт или предлагает подписать непрозрачный пакет действий, безопаснее прекратить операцию. Claim токена не является оправданием для передачи неограниченного контроля над другими активами кошелька.

Vesting contract может хранить токены заранее

Заблокированная allocation не обязательно создаётся позже. Проект может выпустить токены на TGE и сразу отправить их в vesting contract. Тогда total supply уже включает эти единицы, но beneficiary не может забрать их раньше schedule. В другом проекте новые единицы могут mint постепенно по мере emission. Экономический эффект похож — supply становится доступнее со временем, — но on-chain архитектура совершенно разная.

Чтобы понять конкретную модель, проверьте баланс vesting contract, условия release и authority. Если токены лежат на обычном адресе команды и блокировка существует только в PDF, техническая гарантия слабее. Если есть audited timelock или vesting contract с публичными параметрами, ограничение можно проверить независимо. Ни один вариант не оценивается по названию контракта: важны код и фактическое управление.

Несостоявшийся claim не означает исчезновение токенов

После окончания claim period невостребованные токены могут быть возвращены treasury, сожжены, перенесены в следующую программу или оставаться в контракте — всё зависит от правил. Поэтому по одному балансу claim contract нельзя автоматически считать эти единицы циркулирующими или потерянными. Нужна логика завершения программы и адрес назначения остатка.

Если проект меняет сроки claim после запуска, сохраните исходную публикацию и сравните новую. Изменение operational schedule не всегда злоупотребление, но оно влияет на фактическое распределение. Для анализа supply особенно важно, когда изменение затрагивает крупную долю и способно резко увеличить или уменьшить доступный float.

Circulating supply, market cap и FDV в день TGE

Низкий float может сильно искажать первое впечатление от цены

В день запуска на рынке может находиться лишь небольшая доля total supply. Тогда даже относительно малый денежный поток способен заметно двигать цену доступных токенов. Если эту цену механически умножить на весь max supply, получится высокий FDV, который не означает, что весь проект можно было бы немедленно реализовать по такой оценке. Это сценарная оценка полной базы, а не сумма реально вложенных денег.

Поэтому стартовый анализ требует сразу двух долей: circulating supply / total supply и circulating supply / max supply. Чем меньше публичный float и чем больше будущие unlock, тем внимательнее нужно относиться к первой цене. Высокая цена одной единицы при очень маленьком float может сосуществовать с огромным будущим предложением.

Circulating supply — методологическая, а не только контрактная величина

On-chain можно увидеть balances и total supply, но circulating supply требует классифицировать адреса. Аналитические сервисы исключают различные locked, team, foundation, treasury и другие нециркулирующие holdings по собственной методике. Поэтому два источника иногда показывают разные значения, хотя читают один блокчейн. Разница не обязательно означает ошибку; сначала сравните определения и список исключаемых адресов.

Для читателя это означает, что фраза «в контракте totalSupply 1 млрд, значит в обращении 1 млрд» неверна. Контракт не знает экономическую категорию каждого адреса так, как её определяет аналитическая методика. С другой стороны, self-reported circulating supply тоже нельзя принимать без проверки: полезно видеть воспроизводимые адреса и правила исключения.

Market cap и FDV отвечают на разные вопросы

Market capitalization обычно считается как цена × circulating supply. FDV пытается оценить более широкую базу — часто price × max supply или иной полностью разводнённый supply по методике источника. Если в обращении 50 миллионов токенов из будущего миллиарда, разрыв между market cap и FDV будет примерно двадцатикратным при одной цене. Этот разрыв показывает потенциальный масштаб будущего предложения, но не говорит, когда оно появится.

Чтобы превратить разрыв в полезную информацию, нужен unlock schedule. Миллиард max supply, который будет выпускаться десятилетиями, и миллиард, половина которого разблокируется через три месяца, создают совершенно разный профиль. Поэтому TGE-анализ связывает три объекта: текущий float, будущую кривую supply и механизм, который делает токены доступными.

Пример расчёта стартового float

Представим total supply 1 000 000 000. Community allocation — 30%, team — 20%, early contributors — 15%, treasury — 25%, liquidity/incentives — 10%. На TGE community получает 20% своей allocation, team — 0%, contributors — 10%, treasury — 0%, incentives — 50%. Механически unlocked amount составит 60 млн + 0 + 15 млн + 0 + 50 млн = 125 млн токенов. Но даже эти 125 млн не обязательно полностью войдут в circulating supply в первый день.

Часть community allocation может оставаться невостребованной в claim contract, incentives — находиться под программными условиями, а выделенный объём для операционной ликвидности учитываться по особой методике. Поэтому расчёт 125 млн — верхнеуровневая проверка tokenomics, а не финальное число circulation. Его нужно сопоставить с фактическими адресами и методикой выбранного источника.

Как проверить TGE по блокчейну, а не по анонсу

Шаг 1. Найдите официальный идентификатор токена

Начинайте не с поисковой строки в кошельке, а с первичного канала проекта, где опубликован contract address или mint address. Скопируйте идентификатор полностью и сохраните вместе с датой источника. Затем откройте его в обозревателе правильной сети. Проверьте, что сеть совпадает с документацией, а имя и символ являются лишь дополнительными признаками.

Если проект использует несколько сетей, составьте отдельную строку для каждой версии. Нельзя считать одинаковый тикер доказательством того, что токены взаимозаменяемы один к одному без bridge или официальной multichain-механики. У каждой сети будет собственный технический идентификатор и собственная история supply.

Шаг 2. Зафиксируйте deployment и первые mint-события

Для EVM-контракта найдите creation transaction и creator. Затем изучите события, связанные с выпуском. Если весь supply создан одним mint при deployment, это один тип архитектуры. Если mint продолжается после TGE, выясните правила. Для Solana зафиксируйте mint account, supply и authorities. В обоих случаях задача одинаковая: понять, какие единицы уже существуют и кто способен изменить это состояние.

Не делайте вывод только по времени создания. Контракт мог быть подготовлен заранее для аудита и интеграций. Важнее сопоставить timestamp с публичным календарём и subsequent distribution. Если TGE заявлен 15 августа, а контракт развёрнут 10 августа, это может быть нормальным. Но если адрес существовал давно и уже имел большое неописанное движение, нужны дополнительные объяснения.

Шаг 3. Постройте карту крупных адресов

Посмотрите крупнейшие balances и попытайтесь классифицировать их: treasury, vesting, claim, ecosystem, liquidity, team, burn, bridge. Необозначенный крупный адрес — не автоматическое доказательство проблемы, но это вопрос, который должен получить ответ. Сумма классифицированных адресов помогает проверить allocation и увидеть, где реально находится supply.

Особое внимание уделяйте адресам, которые могут быстро переместить существенную долю. Если документация обещает блокировку, а адрес обычный и токены свободно движутся, техническая реализация не подтверждает обещание. Если баланс находится в timelock/vesting contract, изучите его release conditions. Название метки обозревателя полезно, но окончательный вывод лучше опирать на код и транзакции.

Шаг 4. Проверьте административные полномочия

У токена могут существовать права mint, pause, freeze, blacklist, upgrade или изменение отдельных параметров. Набор зависит от сети и реализации. Эти возможности иногда необходимы бизнес-модели, но они меняют профиль доверия. Пользователь должен знать не только «контракт verified», но и кто может вызвать критические функции и защищён ли этот контроль multisig или timelock.

Verified source code означает, что опубликованный код сопоставлен с байткодом, но не обещает безопасность и не отменяет администраторские права. Аналогично аудит не делает каждое будущее управленческое решение безопасным. TGE-проверка должна отвечать: какие полномочия существуют сегодня, кем они контролируются и согласуются ли они с публичной моделью проекта.

Шаг 5. Сверьте on-chain числа с tokenomics

Создайте простую таблицу «обещано / наблюдается / объяснение». Для total supply сравните число из документации с сетью. Для allocation — balances известных адресов. Для initial unlock — фактические transfer/claim. Для vesting — balances и release parameters. Расхождение не всегда ошибка: часть distribution может идти партиями, а decimals создавать визуальные различия. Но каждое существенное расхождение должно быть объяснимо.

Именно такая сверка превращает TGE из новостного события в проверяемый объект. Вы перестаёте зависеть от одного скриншота и можете позже восстановить, как менялась структура supply. Сохранённый стартовый снимок особенно полезен перед крупными unlock или миграцией контракта.

TGE, ICO, airdrop, listing и mainnet: не смешивайте разные события

TGE и fundraising — не одно и то же

Проект способен собрать финансирование до существования публичного токена, а затем провести TGE позже. Поэтому событие генерации описывает создание и первичное распределение токена, а fundraising — способ привлечения ресурсов. Они могут быть связаны, но логически это разные процессы. Участник раннего раунда получает право на будущую allocation, а не обязательно готовый on-chain asset в день подписания условий.

Если документы используют слова sale, round, valuation и TGE рядом, нарисуйте временную шкалу. Сначала может быть соглашение или запись allocation, затем snapshot, затем TGE, initial unlock и дальнейший schedule. Такой график лучше маркетинговых терминов показывает, когда возникает реальный токен и когда возникает возможность им распоряжаться.

TGE и airdrop — событие и один из способов распределения

Airdrop — это механизм распределения токенов выбранной группе, а TGE — более широкая контрольная точка запуска. Airdrop может совпасть с TGE, начаться позже или проходить несколькими сезонами. Некоторые проекты вообще не используют airdrop. Поэтому фраза «airdrop будет на TGE» означает только то, что конкретное распределение привязано к дате запуска.

Для проверки airdrop нужны snapshot rules, eligibility, allocation formula, claim contract и deadline. Для проверки TGE дополнительно нужны supply, token identity, authorities и общая структура distribution. Один успешный airdrop не подтверждает корректность всей tokenomics.

TGE и начало торговли могут не совпасть

Токен способен существовать и быть распределённым раньше появления публичного рынка. Также проект может разрешить transfers, но отложить полноценное price discovery. Поэтому нельзя восстанавливать TGE только по первой свече графика. Надёжнее использовать официальное определение проекта и on-chain timestamps.

Обратная ситуация тоже встречается в сложных миграциях: экономический актив известен рынку, но технический контракт меняется или проходит redenomination. Тогда событие deployment новой версии не обязательно является первым TGE проекта. Контекст жизненного цикла важнее одного timestamp.

TGE и mainnet launch относятся к разным сущностям

Mainnet launch — запуск собственной основной блокчейн-сети. TGE — запуск токена. Проект может выпустить токен в существующей сети задолго до собственного mainnet, а позже мигрировать актив. Или наоборот, сеть уже работает, а отдельный governance/utility token появляется позднее. Слова «запуск сети» и «запуск токена» нельзя использовать как синонимы.

При миграции особенно важны ratio, snapshot, old/new contract, сроки и судьба старого актива. Если проект называет миграцию новым TGE, в анализе всё равно нужно сохранить связь с предыдущим supply, чтобы не воспринимать техническое переиздание как создание экономической ценности с нуля.

Первый рынок после TGE: как читать цену без самообмана

Первая цена формируется на доступном float

Если в день запуска доступно 5% supply, первая цена относится к торговле небольшой частью общего выпуска. Остальные 95% не участвуют в текущем price discovery напрямую, хотя ожидание будущих unlock влияет на решения участников. Поэтому стартовая капитализация и FDV могут расходиться на порядок. Это не математическая ошибка, а следствие разных множителей supply.

Чем меньше float, тем сильнее одна крупная операция может сдвинуть цену. Поэтому первые часы дают слабую базу для выводов о долгосрочной справедливой стоимости. Лучше оценивать не только цену, но и глубину доступной ликвидности, распределение держателей и календарь ближайшего увеличения supply.

Ликвидность важнее красивой стартовой оценки

Номинальная оценка не показывает, какой объём можно переместить без значительного price impact. Если доступный рынок тонкий, даже небольшой объём вызывает сильное проскальзывание. Для пользователя это означает, что «market cap 100 млн» не равно возможности превратить 10 млн токенов в эквивалент по текущей цене. Market cap — оценка запаса, а не обещание ликвидности.

На TGE полезно отдельно фиксировать размер основных pools/market depth, концентрацию liquidity providers и устойчивость цены при небольших изменениях объёма. В дальнейшем эти показатели нужно сравнивать с ростом circulating supply. Если float увеличивается быстрее ликвидности, рыночная структура может становиться уязвимее к крупным перемещениям.

Высокий FDV при низком float требует календаря, а не паники

Высокое отношение FDV к market cap не является автоматическим приговором. Оно сообщает, что текущая цена, применённая к полной базе, даёт намного большую оценку, чем к circulation. Дальше нужно выяснить скорость разблокировки. Если большая часть supply открывается далеко в будущем и проект растёт, профиль один; если крупные allocations становятся доступными через недели, профиль другой.

Поэтому полезный вопрос звучит не «FDV высокий — это плохо?», а «какая доля и кому станет доступна до следующей контрольной даты, и какой объём уже свободен сейчас?». Такая формулировка связывает valuation с реальными holders и schedule.

Первый день не отменяет фундаментальную проверку токена

Сильное движение цены не меняет contract address, mint authority, holder concentration и vesting rules. Если эти параметры были рискованными до первого рынка, рост цены не устраняет риск. Аналогично падение цены не доказывает техническую проблему. Рыночные и технические сигналы нужно держать раздельно.

Это дисциплинирует анализ TGE: сначала идентичность и права, затем supply и distribution, затем liquidity и valuation. Если начинать с цены, остальные данные легко интерпретировать в пользу уже возникшей эмоции.

Риски TGE: где чаще всего теряют контроль над кошельком или понимание токена

Поддельный contract появляется быстрее, чем подробная документация

Вокруг заметных запусков злоумышленники заранее создают токены с похожим названием и тикером. Иногда копия появляется раньше официального TGE, чтобы человек решил, что нашёл «ранний контракт». Единственная безопасная отправная точка — подтверждённый официальный идентификатор. Число holders, красивый логотип и похожая дата не заменяют эту связь.

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

Фальшивый claim превращает интерес к airdrop в кражу

Claim-сайты особенно удобны для фишинга, потому что пользователь ожидает необходимость подключить кошелёк и подписать действие. Мошенник использует эту привычку, предлагая malicious approval, permit или прямой transfer. Иногда сайт показывает правильное название проекта и даже реальный размер allocation, полученный из публичных данных, но подпись направляет активы не туда.

Перед claim полезно использовать отдельный рабочий кошелёк без значимых посторонних активов, если модель проекта это допускает, и внимательно читать simulation. После взаимодействия проверьте approvals и фактический transaction result. Любая просьба «подтвердить кошелёк» вводом seed-фразы означает немедленный отказ.

Неограниченный mint меняет смысл tokenomics

Если проект обещает фиксированный supply, но admin способен в любой момент mint произвольное количество, техническая архитектура противоречит обещанию. Если дополнительный выпуск предусмотрен emissions, право mint может быть нормальным, но тогда нужны лимиты, governance и прозрачные правила. Ключевой риск — не наличие функции само по себе, а несоответствие между полномочием и заявленной моделью.

То же относится к pause/freeze/blacklist. Эти функции могут использоваться для compliance или аварийного реагирования, но дают контролирующей стороне власть над transfer. Пользователь должен понимать этот слой до того, как называет токен «полностью децентрализованным».

Миграция контракта после TGE требует новой проверки

Проект может обнаружить ошибку и выпустить новую версию токена. В таком случае нельзя продолжать использовать старый contract по привычке. Нужно подтвердить официальный migration plan, ratio, snapshot, сроки, новую authority-модель и судьбу старых единиц. Мошенники часто создают «migration» страницы параллельно с реальными обновлениями.

После миграции полезно сохранить оба идентификатора и transaction proof. Если old token остаётся технически transferable, это не значит, что он сохраняет экономический статус. Подлинность новой версии определяется официальной связью и on-chain процессом.

Как проверить проект до TGE: практический порядок без лишних действий

Сначала соберите первичные документы в один набор

До TGE сохраните официальную tokenomics, дату и определение TGE, список сетей, contract/mint если он уже опубликован, правила claim, allocation, vesting и описание административных ролей. Не полагайтесь на пересказ в одном посте. Удобно сделать локальную таблицу с колонками «утверждение», «источник», «дата», «как проверить после запуска». Тогда после TGE вы сможете быстро заменить обещания фактами.

Если документы противоречат друг другу, зафиксируйте более новую версию и историю изменения. Например, blog может говорить 10% initial unlock, а поздняя документация — 15%. Не выбирайте удобное число. Найдите официальный change log или объяснение и используйте актуальную версию с датой.

Переведите проценты allocation в числа

Проценты трудно сравнивать между категориями. Пересчитайте их в токены, затем отдельно рассчитайте initial unlock. Сложите все категории и проверьте 100%. Если сумма не сходится из-за rounding, разница должна быть мала и объяснима. Если не хватает заметной доли, tokenomics неполна.

После этого посчитайте стартово доступный объём по категориям. Такая таблица выявляет концентрацию лучше, чем общий процент. Например, 5% total supply у одной категории может быть полностью unlocked, тогда как 20% другой категории заблокировано на год. В первые недели первая категория влияет на float сильнее.

Проверьте, что проект объясняет mint и admin права

Хорошая документация не ограничивается supply chart. Она объясняет, может ли supply увеличиваться, кто контролирует mint, можно ли pause/freeze transfers, есть ли upgradeability и как защищены administrative keys. Если таких сведений нет, составьте вопросы заранее и после deployment проверьте код самостоятельно или через независимый разбор.

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

Подготовьте безопасный сценарий claim

Если вы ожидаете allocation, заранее определите официальный домен, нужную сеть, адрес кошелька и допустимый тип транзакции. Проверьте, потребуется ли gas native asset, а не сам новый токен. Избегайте импровизации в день запуска, когда множество сообщений и копий создаёт давление времени.

Сохраните адрес кошелька, который должен получить токены, но храните seed отдельно от любых заметок о claim. Если сервис поддержки просит секрет, прекращайте общение. После claim сохраните transaction hash и проверьте token balance по официальному contract/mint.

Определите критерий, при котором вы ничего не делаете

Полезно заранее решить, какие факты блокируют действие: нет официального contract address, tokenomics менялась без объяснения, claim ведёт на неизвестный домен, admin rights не раскрыты, supply расходится, simulation показывает неожиданный transfer. Такой stop-list защищает лучше попытки оценивать риск уже под давлением таймера.

TGE почти всегда сопровождается информационным шумом. Предварительное правило «нет идентификатора — нет действия» или «непонятная подпись — не подписываю» снимает необходимость принимать решение за секунды.

Что происходит после TGE: запуск не заканчивается первым днём

Claimed supply растёт по мере действий пользователей

Если distribution построен через claim, фактическое число получивших токены меняется час за часом. Поэтому snapshot в первые минуты и через неделю даст разные holder counts и balances claim contract. Для анализа полезно различать planned allocation и executed distribution. Это особенно важно, когда большая часть получателей может вообще не забрать токены.

Если unclaimed остаток возвращается treasury после deadline, circulating profile может измениться ещё раз. Поэтому календарь claim — часть supply analysis, а не просто инструкция для пользователя.

Circulating supply может пересчитываться не мгновенно

Аналитический сервис может обновить circulating supply после получения дополнительных адресов от проекта или собственной проверки. Поэтому в первые дни цифры разных источников могут заметно различаться. Это не повод выбирать максимальное или минимальное число. Сравните методику и дождитесь воспроизводимой классификации.

Сохранение стартовых balances помогает понять, что именно изменилось: новые unlock, перемещение treasury, claims или просто новая маркировка адресов. Без исторической точки отсчёта любое изменение выглядит как «выпустили новые токены», хотя total supply мог не меняться.

Unlock schedule начинает влиять сильнее после стартового шума

После TGE внимание постепенно смещается от события запуска к календарю предложения. Первые weekly/monthly unlock, окончание cliff, emissions и treasury distributions становятся важнее самой даты TGE. Поэтому новая статья о запуске должна вести читателя к отдельному разбору вестинга и unlock schedule, а не пытаться заменить его.

Практическое правило: TGE создаёт начальную точку, vesting описывает последующую кривую доступности. Если смешать эти задачи, легко дважды посчитать один и тот же unlock или ошибиться с базовой датой.

Contract может менять административное состояние

После запуска проект иногда renounce mint authority, переносит управление на multisig или timelock, меняет owner, обновляет proxy implementation. Эти действия могут уменьшать или, наоборот, менять риск. Поэтому проверка admin model не одноразовая. Сохраните стартовое состояние и следите за governance событиями.

Если проект обещал отказаться от mint после initial distribution, проверьте, произошло ли это в сети. Обещание «после TGE mint будет disabled» превращается в проверяемый факт только после соответствующего on-chain изменения.

Первые инциденты показывают качество операционного контроля

Ошибки claim, неверные metadata, задержка distribution, несовпадение supply и emergency pause могут случиться даже у серьёзного проекта. Важно, как команда реагирует: публикует ли техническое объяснение, указывает ли transaction IDs, сохраняет ли старые сообщения, не требует ли от пользователей небезопасных действий. Прозрачность инцидента важнее попытки сделать вид, что ничего не произошло.

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

Практические ситуации вокруг TGE

В документации написано «10% at TGE»

Сначала определите базу. Если фраза стоит внутри строки Team allocation, 10% обычно относится к этой allocation, а не ко всему supply. Затем выясните, выдаётся ли 10% прямым transfer или становится claimable. После запуска проверьте фактический баланс beneficiary/vesting contract. Только после этого переводите процент в circulating impact.

Если документация не объясняет базу, не подставляйте total supply автоматически. Запросите или найдите allocation table, где TGE unlock показан по каждой категории. Неоднозначность в 10% может означать разницу в десятки миллионов токенов.

Токен уже создан, но TGE объявлен через неделю

Это не противоречие само по себе. Contract deployment и initial mint могут выполняться заранее для проверки, интеграций и распределения. Зафиксируйте, какие действия уже совершены и почему проект считает TGE будущую дату. Возможно, именно тогда откроется claim или transfers. Главное — чтобы календарь был прозрачен и on-chain history согласовывалась с ним.

Если до объявленного TGE токены уже активно движутся между неизвестными адресами, ситуация требует более глубокого разбора. Это может быть подготовка liquidity и custody, но назначения крупных transfer должны быть объяснимы.

После TGE токен не отображается в кошельке

Отсутствие автоматического отображения не означает, что balance равен нулю. Сначала проверьте официальный contract/mint и свой адрес через обозреватель. Если токены есть on-chain, проблема может быть в token list, metadata, выбранной сети или интерфейсе. Добавляйте custom token только по официальному идентификатору, а не по случайному результату поиска.

Если on-chain balance отсутствует, проверьте transaction/claim status. Не повторяйте claim вслепую и не вводите seed в «сервис восстановления». Ошибка интерфейса и отсутствие фактической distribution — разные проблемы.

Проект изменил tokenomics за день до TGE

Сравните старую и новую версии по конкретным числам: total/max supply, allocation, initial unlock, vesting, treasury и admin model. Сохраните обе версии. Сам факт изменения не доказывает злоупотребление, но снижает ценность старых расчётов и требует пересчитать float и будущую кривую.

Особенно критично увеличение initial unlock или перенос крупной доли из locked в available. Такое изменение влияет на стартовую доступность предложения даже при неизменном total supply.

Mint authority остаётся после запуска

Уточните, предусмотрено ли это моделью. Если tokenomics включает emissions, mint authority может быть частью протокола. Проверьте ограничения, owner/multisig и процедуру governance. Если проект обещает fixed supply и не объясняет сохранённое право mint, это существенное несоответствие.

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

Ошибки чтения TGE, которые повторяются чаще всего

Ошибка: считать TGE одной транзакцией

Иногда одна transaction действительно создаёт весь initial supply, но термин шире. Если человек ищет единственный hash «TGE transaction», он может пропустить deployment, mint, distribution и claim, которые разделены. Правильнее составить набор доказательств и временную шкалу.

Эта привычка особенно полезна при нескольких сетях или migration. Один hash не способен описать весь launch lifecycle.

Ошибка: считать total supply циркулирующим

Total supply отвечает на вопрос о существующих единицах, а circulation — о публично доступной части по методике. Locked team tokens могут входить в total, но исключаться из circulation. Поэтому market cap нельзя корректно восстанавливать простым умножением цены на total supply, если вы хотите сопоставить его с обычной circulating market cap.

Перед расчётом всегда подпишите колонку supply. Это простое действие предотвращает путаницу между market cap, minted valuation и FDV.

Ошибка: считать любой unlocked токен циркулирующим

Unlocked означает отсутствие конкретной блокировки, но токен может оставаться у treasury или инсайдера и исключаться аналитической методикой из public float. Обратная формулировка тоже важна: circulating supply — не всегда чисто техническая функция контракта. Она требует классификации.

Поэтому спор между двумя сайтами о circulation нужно решать сравнением адресов и правил, а не авторитетом бренда.

Ошибка: доверять тикеру вместо contract/mint

Тикер не глобально уникален. Любой разработчик может создать токен с похожим символом. На TGE эта проблема усиливается копиями. Всегда сохраняйте сеть + полный идентификатор. Если кошелёк показывает два одинаковых названия, contract/mint решает, какой объект вы наблюдаете.

Даже официальный токен после migration может иметь старую и новую версии с одним symbol. Поэтому идентификатор важнее визуального совпадения.

Ошибка: смешивать TGE и vesting

TGE — стартовая контрольная точка, vesting — правило доступности allocation во времени. Они связаны, но не взаимозаменяемы. Если статья о TGE превращается в длинный календарь cliff и linear unlock, она теряет собственный предмет. Для подробного расчёта графиков используйте отдельный материал о vesting в крипте.

В рамках TGE достаточно установить initial unlock и точку отсчёта последующих schedules. Это сохраняет ясную границу интента и делает анализ запуска практичнее.

Итоговый алгоритм проверки TGE

До запуска: подготовьте карту обещаний

Запишите official date, network, будущий contract/mint, total/max supply, allocations, initial unlock, claim rules, admin model и источники. Отдельно отметьте, какие параметры ещё нельзя проверить on-chain. Это превращает ожидание запуска в конкретный список будущих проверок.

Если у проекта нет ясной tokenomics или определения TGE, это само по себе информация. Нельзя качественно оценить launch, когда базовые параметры постоянно меняются или опубликованы только в пересказах.

В день запуска: подтвердите идентичность и supply

Сначала contract/mint, затем supply и authorities, потом distribution. Не начинайте с цены. Сопоставьте deployment/mint timestamps с календарём и проверьте крупные holders. Если ожидаете claim, используйте только подтверждённый contract и сохраните transaction hash.

Если любой критический элемент не сходится, остановите действие и дождитесь объяснения. TGE не создаёт обязанности успеть в первые минуты.

После запуска: обновите стартовый снимок

Через несколько часов или дней зафиксируйте claimed amount, holder distribution, circulating supply по выбранной методике и изменения admin roles. Сравните их с первоначальной моделью. Так вы увидите не только обещанный launch, но и фактическое исполнение.

Дальше внимание переносится на vesting, emissions, liquidity и governance. TGE остаётся базовой точкой истории, к которой удобно возвращаться при каждом крупном изменении supply.

Что считать достаточным результатом проверки

Не требуется знать каждую строку смарт-контракта. Для практического уровня достаточно доказать идентичность токена, понять supply model, классифицировать основные allocations, увидеть права дополнительного выпуска и ограничения, проверить initial distribution и не подписывать непонятные действия. Если эти элементы понятны, TGE перестаёт быть абстрактным рекламным термином.

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