Подготовка к листингу на Bithumb: чеклист для проекта

Что должно быть в файле для проверки листинга на Bithumb?

Файл для проверки — это набор фактов и подтверждающих документов проекта, по которому можно легко ориентироваться, а не утверждение, что Bithumb требует каждый пункт из этой таблицы. Начните с текущих инструкций биржи по подаче заявки и сопоставьте каждый запрошенный пункт с файлом, ответственным и источником. Добавляйте полезный контекст только тогда, когда он точен и его легко проверить.

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

Как подготовить факты о проекте для Bithumb?

Напишите краткое описание проекта на основе проверяемых фактов. Укажите, что делает продукт, что уже работает, а что остается запланированным. Избегайте широких утверждений, которые нельзя привязать к источнику. Используйте одинаковое написание, символ токена, сеть и адрес во всех материалах заявки, на сайте и в связанных ресурсах проекта.

Используйте этот рабочий чеклист перед рассылкой файла:

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

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

Какие записи проекта нужно организовать перед отправкой?

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

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

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

Как проверить согласованность документов для листинга на Bithumb?

1. Извлеките каждое фактическое утверждение из черновика заявки.
2. Сопоставьте каждое утверждение с записью-источником или публичной страницей проекта.
3. Сравните названия, даты, данные токена и статус проекта в разных файлах.
4. Назначьте неразрешенные противоречия конкретному ответственному.
5. Перепроверьте исправленные файлы перед отправкой финального пакета.

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

Используйте простую таблицу подтверждающих документов с четырьмя колонками: утверждение, источник, ответственный и статус. Указывайте источник конкретно. «Данные токена» — недостаточно; укажите на соответствующую запись или страницу. Для утверждения о функции продукта дайте ссылку на фактическую страницу продукта или утвержденную документацию. Если подтверждающие документы не являются публичными, отметьте, кто может их предоставить через соответствующий канал.

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

Как вашей команде контролировать передачу документов для Bithumb?

Перед отправкой проведите Spec Review: сверьте текущие инструкции с подготовленным файлом, подтвердите, что каждый включенный документ одобрен для передачи, и перечислите все нерешенные вопросы. Это внутренняя проверка качества, а не указание на критерии рассмотрения Bithumb. Ведите журнал выполнения (Run Log) отправленных версий, внесенных исправлений и последующих пунктов, чтобы команда могла отвечать согласованно.

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

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

Какая поддержка может помочь после прохождения чеклиста подготовки?

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

AEOTech может провести Spec Review на основе ваших текущих инструкций и подготовленных материалов, а затем вернуть краткий отчет (Readout) о несоответствиях и открытых пунктах. Для начала отправьте сайт проекта, текущие инструкции по подаче заявки, с которыми вы работаете, и черновик индекса документов. Мы подтвердим объем проверки и необходимые материалы перед изучением файла.