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

Начните с решения, которое должен поддержать ваш вайтпейпер

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

Напишите одно предложение, описывающее цель документа, затем ответьте на эти вопросы:

• Какую проблему решает проект и для кого?
• Какова роль предлагаемой системы в ее решении?
• Что читатель может проверить или использовать сегодня, а что еще запланировано?
• Какие решения объясняет документ, которые не очевидны из продукта или контракта?

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

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

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

Крипто-вайтпейперу нужна последовательность, которая ведет читателя от проблемы к дизайну и его последствиям. Порядок ниже — это стартовая рамка, а не обязательное оглавление; оставляйте раздел только тогда, когда он отвечает на реальный вопрос читателя.

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

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

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

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

Ревью утверждений может использовать три метки:

• Текущее: подтверждено работающим продуктом, опубликованным кодом, документированным процессом или принятым решением.
• Запланированное: предполагаемая возможность или этап, которые еще не реализованы; описывайте это как план.
• Допущение: условие, на которое опирается дизайн, но которое команда не установила как факт.

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

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

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

Что команда должна подготовить перед написанием?

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

Включите, если доступно:

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

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

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

Какие ошибки в вайтпейпере подрывают доверие читателя?

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

Распространенные проблемы включают:

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

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

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

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

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

Используйте эту последовательность ревью:

1. Технический проход: Проверьте архитектуру, терминологию, границы системы и диаграммы с техническим владельцем.
2. Проход по токену и операциям: Подтвердите описания токена, язык управления, роли и операционные детали с соответствующими владельцами проекта.
3. Читательский проход: Попросите кого-то вне группы авторов резюмировать проблему, механизм, роль токена и текущий статус после прочтения.
4. Проход на согласованность: Сравните утверждения с сайтом, документацией, деком и другими публичными материалами; устраните расхождения в источнике.
5. Копирайтерский и верстальный проход: Проверьте заголовки, определения, ссылки, таблицы, версионность и то, остается ли документ читаемым на экране.

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

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

Цены

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

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

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