Чек-лист запуска токена: что подготовить от T-60 до T+30

T-60: что определить до объявления даты запуска

За T-60 команда должна согласовать цель запуска, параметры токена и публичную версию проекта. На этом этапе важнее закрыть зависимости между продуктом, юридической проверкой, токеномикой и коммуникациями, чем выбирать рекламные форматы.

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

Перед переходом к продвижению проверьте:

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

Для команды полезно сразу записать вопросы, на которые нельзя отвечать предположениями: например, сроки рассмотрения заявки платформой или доступность конкретного рынка. Проверьте критерии листинга заранее и планируйте подачу с запасом на уточнения. Подготовку можно дополнить руководством по листингу на CoinMarketCap и листингу на CoinGecko.

T-30: как проверить операционную готовность проекта

К T-30 у команды должны быть готовы материалы, каналы поддержки и согласованный сценарий запуска. Этот этап превращает стратегию в исполнимый план: для каждого публичного действия указаны время, владелец, нужный доступ и резервный вариант.

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

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

Если нужны публикации авторов или создателей контента, подтвердите тему, формат, сроки, маркировку и процесс проверки фактов. В плане KOL-кампании полезно отдельно сверить критерии отбора и согласование материалов. Для сообщества подготовьте правила модерации и дежурства, а не только расписание публикаций. Запишите, кто принимает решения, если сообщение приходится исправить или перенести.

Какие каналы выбрать для запуска токена?

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

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

Для торговых и аналитических площадок сначала определите, какую информацию пользователь там ищет. Запросы «DEXTools vs DEXScreener» и «CoinMarketCap vs CoinGecko» полезны как вопросы выбора, но не заменяют проверку требований и доступных форматов на самих платформах. В частности, не приравнивайте DEXTools Nitro к любому размещению с похожим названием: сверяйте условия в актуальном интерфейсе и описании конкретной опции.

T-7 и день TGE: что сверить перед публикацией

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

Перед стартом проведите короткую проверку по списку:

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

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

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

T+1—T+30: как организовать работу после запуска

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

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

По итогам периода разберите:

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

При работе с сообществом используйте понятные правила, а не только частоту публикаций. В руководстве по росту Telegram-сообщества можно сверить подход к структуре канала и взаимодействию с участниками. Если проект рассматривает размещения в разделах трендов, включайте их в общий календарь как отдельную активность: DEXTools и DEXScreener имеют собственные форматы, которые нужно изучать до подачи.

Что команда не контролирует при размещениях и листингах

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

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

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

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

Как превратить чек-лист запуска в рабочий документ

Рабочий чек-лист должен показывать не только задачу, но и условие её закрытия. Для каждого пункта запишите владельца, срок, ссылку на материал, подтверждение выполнения и зависимость от других команд. Формулируйте результат проверяемо: например, не «подготовить Telegram», а «опубликовать правила, закрепить официальные ссылки и подтвердить график дежурств».

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

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

Для дальнейшей подготовки используйте материалы по запуску мемкоина, листингам и кампаниям с авторами. Они помогают детализировать отдельные ветки плана, но не заменяют единого календаря T-60—T+30. Чек-лист становится полезным, когда команда регулярно пересматривает его при изменениях и сохраняет решения, а не просто отмечает пункты перед событием.

Цены

Стартовые цены в долларах США. Индивидуальные пакеты и скидки за объём — по запросу. Оплата в USDT, USDC, BTC, ETH, SOL, TON или токеном проекта.

Как мы работаем

1. T-60 — согласуйте основуЗафиксируйте параметры проекта, цель запуска, владельцев и условия подтверждения даты. Отметьте зависимости между продуктом, токеномикой и коммуникациями.
2. T-30 — соберите материалыПодготовьте официальные ссылки, описание, FAQ, контент и сценарии поддержки. Проверьте пользовательский маршрут и роли команды.
3. T-7 — подтвердите готовностьСверьте контрактные данные, доступы, тексты и план действий при переносе или инциденте. Убедитесь, что ответственные доступны.
4. TGE — ведите журнал событийФиксируйте публикации, изменения, обращения и решения в одном месте. Обновляйте аудиторию только подтверждённой информацией.
5. T+1—T+30 — разберите обратную связьОтслеживайте вопросы, статус обещанных действий и пробелы в документации. Передайте выводы в следующий план продукта и коммуникаций.