Claude × крипта — 5 фреймворков для разбора whitepaper (мощь 200K context)

1. Почему для whitepaper я беру именно Claude #

За последние полгода я прогнал один и тот же whitepaper L2-проекта (68 страниц) через 4 модели на одном и том же наборе задач. Результат:

У Gemini context больше, но крипто-контекст он понимает заметно поверхностнее. GPT-4o приходится резать на куски, и tokenomics-цифры между кусками регулярно расходятся. Сильная сторона Claude — не «самый большой context», а сохранение точности деталей при большом context. Это и есть главное.

2. Фреймворк №1 — разбор whitepaper по 6 осям #

Базовый каркас, с него стартует любой проект. PDF заливается в Claude напрямую (Sonnet 4.5 хватает с запасом).

Шаблон prompt:

В приложении — whitepaper проекта [НАЗВАНИЕ] в PDF. Разбери его по шести осям.
По каждой оси давай ответ в формате «цитата из whitepaper → твоя интерпретация».
Всё, чего нет в документе явно, помечай как «в whitepaper не упомянуто» — не додумывай.

1. Постановка проблемы: какую проблему проект заявляет? Перескажи одной фразой.
2. Технический путь: какой технологией решается, чем отличается от существующих проектов.
3. Tokenomics: назначение токена, общий supply, начальное распределение.
4. Кривая разлока: vesting schedule для команды / инвесторов / комьюнити.
5. Roadmap: ключевые точки на ближайшие 12 месяцев и уже выполненные пункты.
6. Раздел «Risks»: какие риски whitepaper признаёт сам.

В финале — список из 5 вопросов, которые в whitepaper «должны были быть, но их нет».

Последний пункт «должны были быть, но их нет» — это и есть основная добавочная ценность. На проектах, что я прогонял, в такой список обычно падает:

• Требования к железу и экономический порог входа для валидаторов (влияет на децентрализацию).
• Модель безопасности средств в кросс-чейн мостах (обычно отделываются размытым «аудит пройден»).
• Обязательства по раскрытию продаж токенов команды после разлока.
• Путь governance, если апгрейд mainnet провалится.

3. Фреймворк №2 — моделирование давления разлоков #

Vesting в whitepaper обычно описан текстом — на глаз понять, «какие месяцы дают максимальное давление на цену», почти нереально. Claude + Artifacts рисуют это напрямую.

Шаблон prompt:

На основе vesting schedule из whitepaper (страницы X–Y) собери таблицу
выпуска токенов на 36 месяцев. Колонки:

- Месяц (1–36)
- Разлок команды (% от общего supply)
- Разлок инвесторов
- Разлок экосистемного фонда
- Эмиссия наград комьюнити
- Суммарный прирост обращения за месяц
- Накопленная доля в обращении

Дальше по таблице ответь:

1. В какие 3 месяца давление максимально? Какая категория токенов отвечает за пик?
2. При условном неизменном курсе — эквивалент в USDT на каждый месяц (FDV считай X).
3. В какие месяцы объём разлока превышает средний дневной оборот в 5+ раз
   (явные месяцы со сбросом).

В конце — markdown-таблица плюс столбчатая диаграмма на 36 месяцев (через Artifacts).

В прошлом году я прогнал этот prompt по проекту ИИ-сектора, и Claude вытащил «в 13-й месяц единовременный разлок 6.2% команды». Такая cliff-схема (полная блокировка 12 месяцев, разовый выпуск на 13-й) в whitepaper упоминалась одной фразой, но именно столбец на графике сделал её очевидной катастрофой. Проект, как и предполагалось, просел на 38% именно в 13-й месяц.

4. Фреймворк №3 — аудит и сверка с контрактом #

Вот здесь 200K context раскрывается по-настоящему: одновременно скармливаем whitepaper, отчёт аудита и код контракта с Etherscan (файлы .sol можно перетаскивать в Claude напрямую).

Шаблон prompt:

Три материала:
- Приложение 1: whitepaper в PDF.
- Приложение 2: отчёт аудита Certik / OpenZeppelin / Halborn в PDF.
- Приложение 3: исходник .sol контракта, развёрнутого в mainnet.

Сделай трёхслойную сверку:

Слой 1: что про права контракта пишет whitepaper vs что проверял аудит vs что реально стоит как modifier в исходнике.
- Где совпадает, где расходится.

Слой 2: issues со статусом «Acknowledged but not fixed» в аудите.
- По каждому: суть + severity + ответ команды + остался ли в финальной mainnet-версии.

Слой 3: admin-функции в исходнике.
- Все onlyOwner / onlyAdmin / функции экстренной паузы.
- У каких есть timelock, у каких нет.
- Конфигурация multi-sig (N-of-M), если видно по коду.

Не нужно резюме в духе «проект безопасен / небезопасен». Нужен список фактов.

Последняя строка критична — запрет на резюме. Вердикт ИИ «проект в целом безопасный» бесполезен. Нужен список фактов, по которому решение принимаешь ты.

5. Фреймворк №4 — обратная проверка команды #

Сюда скармливаем скриншоты LinkedIn, страницы предыдущих проектов, истории Twitter, профили Crunchbase. Помним: Claude не выходит в сеть — весь материал собираешь сам.

Шаблон prompt:

Передаю публичную информацию по 5 ключевым участникам команды проекта
(сводки LinkedIn + история Twitter + страницы прошлых проектов).

Сделай:

1. Таймлайн по каждому участнику:
   - Заявленный публично опыт vs реально подтверждаемый опыт
     (явно указывай расхождения).

2. Финал прошлых проектов:
   - Работает? Куплен? Закрыт? Rug?
   - Сколько прошло от запуска до закрытия / поглощения.

3. Red flags:
   - Были ли в прошлых проектах иски SEC, жалобы комьюнити, эксплойты контрактов.
   - Числится ли участник одновременно в 2+ крипто-проектах.
   - Есть ли явные противоречия между LinkedIn и Twitter.

4. Какие ещё keyword стоит прогнать самому для перекрёстной проверки?

Не давай вердикт в духе «команда надёжная / ненадёжная».

Сила Claude — в горизонтальном сопоставлении: пять резюме лежат рядом, и модель замечает, что «трое утверждают, что работали в одной компании, но периоды не пересекаются». Человеческий глаз такую деталь почти всегда упускает.

6. Фреймворк №5 — матрица конкурентов #

Финальный, для горизонтального сравнения после индивидуальных разборов. В Claude разом загружаются whitepaper-ы 3–5 проектов.

Шаблон prompt (рекомендую Opus):

В приложении — whitepaper четырёх проектов одного сектора (A/B/C/D).
Собери сравнительную матрицу по осям:

- Механизм консенсуса
- Дата запуска mainnet
- Текущий TVL (данные с DefiLlama я добавлю отдельно)
- Доля токенов команды + дата окончания разлока
- Соотношение «инвесторы vs комьюнити»
- Активность разработки за последние 6 месяцев (частота коммитов в GitHub — приложу)
- Количество пройденных аудитов + аудиторы
- Объём whitepaper и аккуратность изложения (субъективная оценка)
- Уникальное позиционирование одной фразой

Дальше ответь:

1. Чья tokenomics из четырёх максимально «дружелюбна к мелкому держателю»?
2. У какого проекта расхождение «roadmap vs реальная поставка» максимально?
3. У какого whitepaper-а явный перекос «маркетинговые формулировки > технические детали»?

В финале честно перечисли, какие поля нельзя заполнить только из whitepaper —
нужны внешние источники.

Последний абзац — ключевой. По умолчанию ИИ заполняет все поля силой (даже если данных не хватает). Когда вы явно требуете «признать, что не заполнено», модель честно ставит «insufficient data».

7. Чего Claude не умеет #

За последние полгода крипто-due diligence на Claude я успел собрать несколько граблей — описываю, чтобы вы их обошли.

Ограничение 1: полное отсутствие сети. Любой «текущий TVL», «цена за 7 дней», «реальный баланс контракта», который модель отдаёт, — выдуман или взят из устаревших данных обучения. У Claude нет аналога Browse как у ChatGPT, так что все актуальные данные тянем сами и вставляем вручную.

Ограничение 2: в длинных документах изредка «рассинхрон цифр». Был случай: на странице 23 в таблице — «доля команды 22%», в деталях vesting на странице 47 — уже 18%. Claude отдал 22% (выбрал более ранний вариант) и не подсветил конфликт. Поэтому ключевые цифры перепроверяем по оригиналу, а лучше — отдельно просим Claude вывести «все страницы whitepaper, где встречается эта цифра».

Ограничение 3: тема плеча / структурных стратегий упирается в дисклеймеры. На вопрос «как собрать структурную стратегию с 3x плечом» Claude вываливает простыню «это не совет», и плотность информации проседает. Лечится переформулировкой: «допустим, у меня уже есть позиция X — разбери её экспозицию при просадке BTC на 10%». Модель переключается из режима «советчик» в режим «аналитик».

Ограничение 4: на Free-тарифе реальный context сильно меньше. У бесплатного Claude фактически доступный context гораздо меньше 200K (≈100K, и из них ещё часть уходит на историю диалога). Целый whitepaper грузим только на Pro, иначе уже на 5–6 ходу модель начинает «забывать» начало.

Открыть данные Binance → Вся prompt-библиотека →

8. FAQ #

Q1: Claude подходит для разбора крипто-проектов лучше, чем ChatGPT?

На разборе длинных документов преимущество Claude очевидно — 200K context за один проход вмещает whitepaper, аудит и твиты команды. Но он не выходит в сеть: все актуальные данные нужно вставлять самому. В обычном диалоге разница уже не такая заметная.

Q2: Что выбрать для whitepaper: Sonnet или Opus?

80% повседневных задач закрывает Sonnet 4.5, цена — 1/5 от Opus. Opus имеет смысл только на сложных многомерных задачах (например, параллельное сравнение 5 проектов с оценкой риска по tokenomics) — там берём Opus 4.5.

Q3: Claude отказывается обсуждать крипто-проекты?

Обсуждение структуры проекта, tokenomics, технических деталей — без проблем. Claude отказывает на запросах «скажи, вырастет ли монета X» или «посоветуй плечо» — и это к лучшему, иначе он сам бы генерил шум.

Q4: Можно ли через Claude API автоматизировать разбор?

Да. Anthropic API тарифицируется по token: вход у Sonnet 4.5 — около $3 за миллион token, один прогон 200K входа — примерно $0.6. Батчевый прогон due diligence по 50 проектам за ночь обходится меньше $50.

Q5: Как собрать крипто-workflow в Claude Project?

Создаём Project в Claude.ai и закидываем в Project Instructions три блока: «фреймворки крипто-due diligence», «чёрный список маркетинговых формулировок», «ваш профиль риска». Для нового проекта просто загружаем whitepaper — фреймворки применяются автоматически.

PromptDeck · 2026-05-15