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

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

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

Затем составьте карту вопросов аудитории. Разработчику может понадобиться архитектура, зависимости и статус реализации. Держателю токена — правила эмиссии, полезность и управление. Потенциальному партнёру — роль продукта в более широкой экосистеме. Один документ может обслуживать несколько групп читателей, но не должен заставлять их пробираться через не относящиеся к ним детали.

Используйте краткое описание, чтобы установить:

• Проблему и того, кто с ней сталкивается.
• Предлагаемое решение и то, что существует сегодня.
• Целевую аудиторию документа и следующее действие.
• Какие утверждения подтверждены, запланированы или ещё исследуются.

Если проект находится на ранней стадии и основная потребность — в кратком введении, перед составлением плана сравните вайтпейпер с крипто-питч-деком. Дек поддерживает презентацию; вайтпейпер даёт читателям более полное объяснение, на которое можно ссылаться.

Какая структура делает крипто-вайтпейпер удобным для оценки?

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

Практический план:

1. Краткое описание: проблема, предложение и текущий статус.
2. Проблема и контекст: кто затронут и какие существующие подходы оставляют нерешённым.
3. Продукт и система: пользовательский путь, ключевые компоненты и их взаимодействие.
4. Архитектура: соответствующие контракты, выбор сети, зависимости и соображения безопасности.
5. Дизайн токена (если применимо): назначение, эмиссия, распределение, правила выпуска и управление.
6. Дорожная карта и команда: разграничьте выполненную работу и запланированную, укажите ответственных.
7. Риски и ссылки: объясните ограничения и укажите на вспомогательные материалы.

Адаптируйте план под проект, а не заполняйте каждый заголовок по умолчанию. Документу протокола может потребоваться более глубокая архитектура; приложению — больше объяснений пользовательского пути. Добавляйте диаграммы, когда они проясняют взаимодействие, и подписывайте их так, чтобы основная мысль оставалась понятной без специальных знаний. Используйте один термин для каждого ключевого понятия, определяйте его при первом использовании и делайте названия разделов описательными. Читатель должен иметь возможность просмотреть заголовки и понять аргументацию документа.

Как следует объяснять токеномику и утверждения проекта?

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

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

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

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

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

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

Создайте цепочку рецензирования до завершения черновика:

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

Когда проект зависит от стороннего протокола, оракула, моста или сети, назовите эту зависимость и объясните её роль. Чёткое описание того, на что полагается система, полезнее, чем описание её как «не требующей доверия» без указания фактических допущений о доверии.

Какие ошибки в крипто-вайтпейпере стоит исправить до публикации?

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

Обратите внимание на типичные проблемы:

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

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

Что может установить вайтпейпер — а что остаётся вне его контроля?

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

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

Простой контрольный список перед публикацией:

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

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

Цены

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

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

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