Статья Blind Dev

Как я оцениваю риск вложения в проекты

Центральная risk framework статья: идея, продукт, tokenomics, команда, рынок и личные лимиты.

Материал основан на личном опыте и исходных публикациях Blind Dev; перед применением проверьте актуальность деталей.

Не является инвестиционной рекомендацией. Материал описывает методику и риски.

Историческая публикация от 2026-01-19. Восстановлен текст исходной статьи Teletype. Численные пороги распределения и разлоков — личные эвристики автора, не общепринятые нормы и не гарантия движения цены. Формулировка «почти гарантированное падение» в оригинале не является установленным законом рынка. Отсутствие документации — сигнал неопределённости, а не доказательство обмана. Наличие инвестиций, подписчиков или аудита не гарантирует качество и поддержку цены. Не инвестиционная рекомендация.

Исходный материал

В крипте легко попасть в ловушку: кажется, что главное - найти “правильный” проект. А по факту главное - не пропустить риск, который потом проявится разлоками, уязвимостью, слабой коммуникацией команды или отсутствием спроса. Я незрячий web3-программист, поэтому не опираюсь на визуальные подсказки и “красивые” графики. Мой подход проще: разложить проект на несколько блоков и последовательно проверить, где именно он может сломаться. Ниже - схема, которой я пользуюсь, когда решаю, стоит ли вообще тратить время и деньги на проект. Это не “как выбрать монету” и не прогноз цены. Это чеклист рисков: команда, концепт, коин (токеномика и капитал), код и практика (как всё работает в реальности).

Тут всё важно:

• Команда - от её профессионализма (что можем обнаружить внешне), качества коммуникаций зависит долгосрочность проекта и реакция в случае ваших запросов
• Концепт - насколько проект хорошо описан в документации / FAQ / на сайте. Соответствует ли всем критериям, о которых далее расскажу
• Коин - насколько хороша токеномика, уровень инвестиций и качество инвесторов (не сливают ли большинство проектов на 90+%)
• Код - открыт ли, есть ли основные репозитории и какова активность. А главное: есть ли аудиты и исправлены ли ошибки / уязвимости
• Практика - насколько хорош функционал, работает ли он, полон ли.

Подробнее

Команда

• Сначала спрашиваю в Discord: есть ли информация о них в LinkedIn или подобном сервисе, токиномика будущего или существующего токена и открыт ли код. Ответом от них определяю качество коммуникации. После изучения концепта иногда задаю ещё вопрос. Например, в одном из последних проектов узнал так, что у них централизованный бекенд (напрямую об этом в документации не писали). Если реакция непрямая (увиливают), отсутствует или не по теме - риск плохих коммуникаций при плотном взаимодействии с проектом или его закрытия / отсутствия успеха
• Смотрю соцсети: X (активность и проверяю на ботов в Moni / Tweetscout, а также кто на них подписан: если есть крупные фонды или проекты - хорошо) В этом же разделе сообщаю, открыта ли команда: отвечает и насколько корректно. А то бывает отмалчиваются или пишут не по теме
• Изучаю другие соцсети: LinkedIn, блог, Telegram и так далее. Это не основное, но если там есть активное сообщество - лучше Если соцсети неактивные и на вопросы не отвечают, увеличивается риск приостановки работы проекта и слабой обратной связи на критических этапах”. Если много ботов в X - риск раздутых параметров = плохого качества (не гарантировано, так как накрутка может быть заданиями с наградами)

Концепт

Чаще всего это документация, white paper (реже) и FAQ.

• Есть ли в них анализ спроса: если нет - риск того, что проект не понимает рынок = не может сделать хороший продукт. Или вовсе делают продукт, на который не будет спроса.
• Анализ конкурентов: плюсы и минусы проектов или хотя бы их список. Позволяет понять, что основатели следят за рынком = снижается риск создания слабого продукта
• Техническая информация - если нет или мало, значит что-то скрывают (например, проект централизован = работает на одном сервере). Хотя бы архитектура с подробным описанием того, как всё устроено, должна быть
• Отсутствие пользовательской документации (инструкций) увеличивает риск слабого спроса и низкой удерживаемости пользователей, особенно в сложных продуктах
• Информация о комиссиях и прочих ценах - если нет, появляется риск неожиданных сборов.
• И в целом, насколько подробное описание проекта, всё ли понятно (хотя бы с пояяснениями нейронных сетей)

Коин

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

В аналитике:

• Есть ли токеномика?
• Нормальное ли распределение: максимум 10% команде (край - 15%), максимум 10% инвесторам (край - 15%)
• Сколько одномоментно выделяется сообществу и есть ли готовый продукт, который может сформировать спрос на токен / хорошие маркетмейкеры? Если нет - риск слабой цены (даже инвесторы могут недождаться нормальной фиксации на разлоках)
• Нет ли резких всплесков при разблокировках (разлоки 10% от всех токенов через год после TGE = почти гарантированное падение цены, если нет сильного спроса благодаря ютилити) Допустимый риск - < 0.9% от всех токенов в месяц
• Ютилити: прописаны ли они, и насколько хороши. Выкупы с хорошим продуктом, платные функции и другие утилиты могут поддержать токен. Если не прописаны или, например, есть только стейкинг с ДАО - риск слабой поддержки.
• Капитал: есть ли публичный капитал команды / инвестиции. Ими могут поддерживать цену.

Также изучаю инвестиции:

• Сумму
• И кто инвестировал. Есть некоторые фонды, у которых абсолютное большинство проектов упали на -90% и больше. Согласитесь, что это странно?

Код

• Открыт ли?
• Есть ли репозитории основных программ проекта? Например, ноды блокчейна, обработчика смарт-контракта…
• Активна ли разработка: есть ли периодические обновления?
• Опубликованы ли аудиты? Давно ли? Если обновления существенные были недавно, а аудиты давно - риск новых уязвимостей или ошибок. Если всё нормально, решены ли все описанные в аудитах проблемы?
• Чем больше ответов “нет” на эти вопросы, тем выше риск плохого качества проекта. Код может и хороший, но оценить его сложно.

Практика

• Работает ли функционал вообще?
• Насколько он полный и понятный? А то бывает, что в документации есть какой-то функционал, но в интерфейсе отсутствует.
• Соответствует ли он описанию в документации (концепт)? Например, нет ли доп. комиссий.

Если есть ответы “нет” - риск плохого качества проекта.

Итог

Эта схема не гарантирует, что проект “выстрелит”. Она решает другую задачу: помогает быстро отсеивать проекты, в которых риск заложен в фундамент. Если совсем кратко, я стараюсь ответить на 5 вопросов:

• Можно ли доверять команде по качеству коммуникации и прозрачности
• Понимают ли они рынок и конкурентов, и не прячут ли важные детали в концепте
• Есть ли у коина шанс не превратиться в источник постоянного давления цены из-за разлоков и слабой утилити
• Насколько прозрачен код, есть ли аудиты и закрыты ли найденные проблемы
• Совпадает ли реальность с описанием, работает ли продукт и нет ли скрытых комиссий и ограничений

В конкретных кейсах вес этих факторов разный, поэтому я всегда смотрю на проект в контексте. Но чем больше ответов “нет” на этих этапах, тем меньше смысла спорить с рынком и надеяться, что “на этот раз пронесёт”.

Источник

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