Как читать техническое описание проекта

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

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

Порядок чтения задаёт не оглавление, а вопрос «кому предъявлять претензию». Сначала — лицо. Потом — обещание. Затем — техника. И только в конце — часть про рынок и партнёрства. К проверке она отношения почти не имеет.

Ориентир по полноте есть в праве. Он внешний. Регламент Европейского союза 2023/1114 (MiCA) от 31 мая 2023 года в статье 6, пункт 1, перечисляет десять групп сведений, которые документ о выпуске обязан содержать; приложение I расписывает их по частям от A до I — об оференте, об эмитенте, об операторе торговой площадки, о проекте, о предложении, о самом активе, о правах и обязанностях держателя, о применяемой технологии и о рисках. Список берут как сетку. По нему видно не то, что в документе есть, а то, чего в нём нет.

1. Ответственное лицо: название, организационная форма, адрес регистрации, состав органа управления.
2. Предложение: цена размещения, общее число выпускаемых единиц, фазы продаж и скидки для ранних покупателей.
3. Актив: тип, функции и сроки, когда эти функции начнут работать.
4. Технология: сеть, механизм консенсуса, итоги аудита кода, если аудит проводился.
5. Риски: по проекту, по активу, по технологии и по реализации — четырьмя отдельными описаниями.

Где взять документ и чем проверять каждое утверждение

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

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

Разбор на живом примере: абзац про токеномику

Возьмём типовой абзац. Он короткий. Заявлено фиксированное предложение, доля команды и доля продаж ранним участникам, срок блокировки. Числа ниже условные, они нужны для порядка счёта, а не для оценки какого-либо актива.

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

Красные флаги в техническом описании

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

• Обещание доходности, целевая цена или график роста стоимости.
• Нет ни одного имени с проверяемым профилем, вся команда под псевдонимами.
• Токеномика в процентах без абсолютных чисел и без дат разблокировок.
• Технический раздел пересказывает устройство блокчейна вообще, а не продукта.
• Раздел рисков из двух строк общего характера либо отсутствует.
• Документ без версии и даты правки, история изменений не публикуется.

Как собрать собственную сводку по документу

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

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

Сводка по одному проекту ценна умеренно. Она начинает работать, когда таких сводок несколько и строки у них одинаковые: сравнение двух проектов по одинаковым метрикам показывает разницу в качестве раскрытия быстрее, чем чтение обоих документов подряд.

Итог

Техническое описание — это не аргумент за актив и не аргумент против. Это набор заявлений с известным автором. Ценность чтения в том, какие из заявлений удалось подтвердить вне документа и какие обязательные блоки раскрытия автор пропустил. Пропуски информативнее формулировок. Их и собирают.

Частые вопросы

Первоисточники: страница европейского регулятора ESMA о регламенте MiCA — требования к раскрытию, промежуточный реестр и текст регламента по ссылке; документация метрик предложения Glassnode — определения показателей предложения. Формулировки сверены 17 октября 2026 года.