DYOR в криптовалюте — это принцип Do Your Own Research, то есть «проведи собственное исследование». В практическом смысле DYOR означает не чтение нескольких постов и не поиск мнения популярного автора, а самостоятельную проверку того, что именно представляет собой проект, кто им управляет, как устроен токен, где находятся риски, какие утверждения можно подтвердить по первичным данным и какие факты способны опровергнуть инвестиционную гипотезу.

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

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

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

На OneMagic уже есть отдельная практическая инструкция о том, как проверить токен перед покупкой. Здесь задача шире: построить полноценную систему DYOR для проекта, протокола или криптоактива — от источников и продукта до on-chain данных, governance, токеномики и итогового инвестиционного решения.

Хороший DYOR не должен доказывать, что вы правы. Его задача — дать достаточный шанс обнаружить, что вы ошибаетесь, до того как ошибка станет убытком.

Что такое DYOR в криптовалюте и чего этот принцип не означает

Что показывает схемаЦель — отделить утверждение от доказательства и от своего вывода.
Что запомнитьDYOR заканчивается не ссылкой, а проверяемым выводом с уровнем уверенности и условиями пересмотра.

DYOR расшифровывается как Do Your Own Research

Фраза Do Your Own Research стала универсальным напоминанием: не принимайте инвестиционное решение только потому, что кто-то другой уверен в активе. В криптовалютной среде она особенно полезна из-за высокой скорости распространения нарративов. Пост, ролик или чат способны создать ощущение общественного консенсуса задолго до того, как продукт доказал полезность.

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

DYOR не равен поиску положительных мнений

Confirmation bias заставляет человека замечать аргументы в пользу уже понравившейся идеи и игнорировать противоположные. В результате исследование превращается в коллекцию подтверждений. Правильная методика специально ищет отрицательные факты: проблемы в governance, будущие unlock, спорные права администратора, отток пользователей, зависимость от incentives и слабую ликвидность.

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

DYOR не равен чтению whitepaper

Whitepaper — документ самого проекта. Он помогает понять заявленную архитектуру, но не подтверждает фактическое исполнение. Команда может изменить roadmap, код может отличаться от описания, а экономика — работать не так, как предполагалось.

Поэтому whitepaper считается первичным источником намерений, но не доказательством результата. Его нужно сопоставлять с кодом, on-chain данными, governance и фактическим использованием.

DYOR не означает доверять аудиту как гарантии

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

Кроме того, технический аудит обычно не оценивает, выгодна ли токеномика или существует ли устойчивый спрос. Безопасный код способен реализовывать экономически слабую модель.

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

DYOR не является способом точно предсказать цену

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

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

DYOR заканчивается решением, а не бесконечным чтением

Исследование без критерия остановки легко превращается в прокрастинацию. Нужно заранее определить, какие вопросы обязательны для ответа и какие факты являются stop-signal. Когда набор заполнен, принимается одно из трёх решений: не участвовать, наблюдать или выделить заранее ограниченный риск-бюджет.

Если решение принято, следующим этапом становится мониторинг гипотезы, а не постоянный поиск новых подтверждений.

Не является DYOR Почему недостаточно Что делать вместо этого
Посмотреть несколько обзоров Источники могут копировать друг друга Проверять первичные данные
Прочитать whitepaper Это заявление проекта Сопоставить с кодом и фактом
Увидеть аудит Scope ограничен Проверить версию и admin risk
Посмотреть цену Цена не объясняет фундамент Изучить спрос и supply
Найти известного инвестора Имя не даёт гарантий Проверить права и условия
Собрать только позитив Confirmation bias Искать опровержения

Иерархия источников DYOR: чему доверять в первую очередь

Первичный источник сильнее пересказа

Первичные источники создаются самим объектом исследования или системой, где он работает: документация, репозиторий, контракт, blockchain explorer, governance proposals, официальные отчёты и юридические документы. Вторичные источники интерпретируют эти данные: исследования, обзоры, интервью и аналитические панели.

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

Документация показывает заявленную модель

В документации ищите не маркетинговое описание, а технические параметры: contract addresses, chain deployments, governance, oracle, fees, token utility, mint и burn, upgradeability и emergency controls.

Если важный параметр невозможно найти в документации, это само по себе сигнал прозрачности. Хороший проект обычно облегчает проверку критических компонентов.

Block explorer показывает фактическое состояние

Blockchain explorer позволяет увидеть адрес контракта, supply, holders, transfers, treasury, multisig и события. Это помогает отличить слова от действий. Например, обещанный burn подтверждается транзакцией, а заявленный treasury — конкретными адресами.

Для работы с транзакциями полезен отдельный материал OneMagic о том, как проверять операцию по TxID.

Исходный код должен соответствовать deployed bytecode

На Ethereum source-code verification позволяет проверить, что опубликованный исходный код компилируется в тот же bytecode, который работает по адресу контракта. Это не доказывает отсутствие ошибок, но позволяет исследователю понимать логику реального контракта, а не красивый файл в репозитории.

Неверифицированный критический контракт повышает неопределённость. Особенно если проект просит пользователей вносить значительные суммы.

Governance history важнее декларации децентрализации

Проект может называть себя DAO, но реальные изменения могут контролироваться небольшой группой. Посмотрите историю proposals: кто предлагает, кто голосует, какой quorum, сколько адресов определяет результат, есть ли timelock.

Фактическая governance activity показывает больше, чем схема на презентации.

GitHub activity нельзя читать по числу commits

Большое количество commits не равно качеству разработки. Автоматические обновления, merge и форматирование могут искусственно увеличивать счётчик. Смотрите содержательность изменений, число независимых contributors, issue history, release cadence и наличие тестов.

Также важно, совпадает ли публичный репозиторий с кодом, который реально используется в production.

Социальные сети — источник сигналов, а не доказательств

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

Любое существенное утверждение из соцсетей нужно переводить в проверяемый источник.

Независимый источник должен быть действительно независимым

Многие «обзоры» публикуются по партнёрской модели. Если автор получает деньги, токены или referral benefit, существует конфликт интересов. Это не делает материал автоматически ложным, но снижает его вес.

Ищите раскрытие sponsorship и сравнивайте несколько источников с разными экономическими интересами.

Источник Что подтверждает Основное ограничение
Документация Заявленную модель Проект пишет о себе сам
Explorer On-chain факты Не объясняет off-chain контекст
Verified source Совпадение кода и bytecode Не гарантирует безопасность
Governance Реальные правила управления Может быть сложна интерпретация
GitHub Разработку Commits можно неправильно читать
Аудит Проверенный scope Не гарантия и не экономика
Соцсети Коммуникацию и нарратив Манипулируемость

Проверка продукта: существует ли реальная причина пользоваться проектом

Сначала сформулируйте проблему одним предложением

Если невозможно объяснить, какую проблему решает продукт, токен анализировать рано. Формулировка должна быть конкретной: не «революционизирует финансы», а, например, «позволяет использовать определённый collateral без централизованного посредника».

Слишком широкие обещания обычно скрывают отсутствие измеримой задачи.

Пользователь должен получать ценность без роста токена

Сильный тест: будет ли продукт полезен, если цена собственного токена год не растёт? Если ценность для пользователя исчезает без постоянного роста цены, модель может зависеть от спекулятивного притока.

Экономически устойчивый сервис должен создавать полезность отдельно от инвестиционного нарратива.

Проверяйте рабочий продукт, а не только roadmap

Roadmap описывает будущее. Для оценки текущего состояния посмотрите mainnet, active contracts, API, интерфейс, документацию разработчика и реальные транзакции.

Если проект существует несколько лет и основные функции всё ещё остаются будущими, это должно влиять на оценку.

Активность пользователей нужно очищать от incentives

Высокое число адресов может возникнуть из-за airdrop, фарминга или sybil activity. Полезнее смотреть repeat users, платящих пользователей, retention и активность после уменьшения наград.

Если usage исчезает сразу после окончания incentives, продукт мог покупать активность эмиссией.

Fees показывают готовность платить

Комиссионный поток полезен как признак того, что пользователь готов отдавать ценность за сервис. Но важно понять, кому идут fees и не субсидируются ли они дополнительным token emission.

Gross fees нельзя автоматически приравнивать к protocol revenue.

Revenue и token value capture — разные вещи

Протокол способен иметь большую выручку, но токен может не получать экономической выгоды. Нужно проверить, участвует ли токен в fee payment, staking, buyback, burn, collateral или governance с реальными правами.

Если value capture отсутствует, успех продукта не обязательно превращается в спрос на токен.

Конкурентное преимущество должно быть проверяемым

Низкая комиссия, более быстрый settlement, уникальная ликвидность, особая безопасность или сетевой эффект можно измерить. Слова «лучший», «инновационный» и «первый» сами по себе не аргументы.

Сравните продукт минимум с тремя альтернативами по одинаковым метрикам.

Зависимость от одного внешнего поставщика повышает риск

Проект может выглядеть децентрализованным на уровне смарт-контракта, но зависеть от одного oracle, bridge, RPC, custodian или front-end. Нарисуйте dependency map.

Критический компонент, который может остановить систему одним решением, должен быть отдельным risk factor.

RWA требует проверки off-chain прав

Если проект токенизирует реальные активы, blockchain не заменяет юридическую цепочку. Нужно понимать issuer, SPV, custodian, underlying и redemption. Отдельная статья OneMagic о RWA разбирает эту часть подробно.

Для DYOR важно: красивый on-chain token не делает off-chain право автоматически исполнимым.

Вопрос о продукте Хороший признак Красный флаг
Что решает? Конкретная проблема Абстрактная революция
Есть ли продукт? Mainnet и usage Только roadmap
Кто пользуется? Repeat/paid users Только airdrop addresses
Есть ли fees? Органический спрос Полная субсидия emissions
Зачем token? Обязательная функция Можно удалить без последствий
Dependencies Распределены Один критичный посредник

Токеномика DYOR: supply, FDV, unlock, эмиссия и концентрация

Начните с total, circulating и max supply

Один и тот же токен может иметь 10% общего supply в обращении и 90% в будущих allocations. Цена текущего маленького free float масштабируется на ограниченное количество единиц, поэтому market cap выглядит умеренным, а FDV — огромным.

Понимание supply structure обязательно до оценки цены.

Market cap не показывает будущую разводнённость

Market cap использует circulating supply. FDV пытается масштабировать цену на более полный supply. Оба показателя условны, но их разрыв помогает увидеть потенциальное dilution.

Подробнее формулы разобраны в статье OneMagic о капитализации и FDV.

Allocation показывает экономические интересы

Разделите supply на команду, ранних инвесторов, treasury, community, staking incentives, liquidity и публичное распределение. Большая инсайдерская доля не всегда плоха, но создаёт governance и sell-pressure risk.

Особенно важно, на каких условиях эти доли приобретались и когда становятся ликвидными.

Vesting нельзя смотреть только по ближайшему unlock

Один крупный unlock может привлечь внимание, но долгосрочный график важнее. Постройте выпуск на 12–24 месяца и сравните его с текущим circulating supply.

Материал OneMagic про vesting, cliff и unlock помогает читать график корректно.

Emission может финансировать рост, но размывает holder

Staking rewards и liquidity incentives не бесплатны. Если они создаются новыми токенами, existing holders получают dilution, если не участвуют пропорционально.

Сравните gross emission с burn и реальным спросом на новые единицы.

Burn важен только вместе с mint

Проект может активно рекламировать сжигание, одновременно создавая больше токенов, чем уничтожает. Смотрите net supply change.

Headline «сожжено 10 млн» без denominator и emission schedule почти ничего не говорит.

Treasury — ресурс проекта, но не актив holders автоматически

Большой treasury может финансировать разработку и поддерживать систему. Но governance token holder не обязательно имеет прямое право на долю treasury.

Проверяйте governance powers и реальные правила расходования.

Concentration требует классификации адресов

Top holders могут включать bridge, staking contract, treasury, custodian и реальные whale wallets. Простой список крупнейших адресов без labels вводит в заблуждение.

После классификации оцените, сколько supply контролируют независимые лица и сколько может выйти на рынок.

Low float создаёт риск искусственно высокой цены

Если торгуется малая часть supply, небольшой спрос способен поднять цену и FDV. Позже unlock увеличивает доступное предложение и меняет баланс рынка.

Low-float/high-FDV структура требует особенно осторожного position sizing.

Token utility должна создавать спрос, а не только распределять награды

Если token нужен только для получения новых token rewards, возникает циклическая экономика. Сильнее модель, где единица нужна для доступа, collateral, gas, security или другого независимого действия.

Запишите source of demand отдельно от source of emission.

Метрика Что проверить Типичная ошибка
Circulating supply Что реально ликвидно Верить одному агрегатору
FDV Будущий supply Считать прогнозом капитализации
Allocation Кому принадлежат токены Игнорировать insider share
Vesting Когда supply разблокируется Смотреть один unlock
Emission Сколько создаётся Называть rewards доходом без dilution
Burn Net effect Игнорировать mint
Concentration Кто контролирует supply Не классифицировать system wallets

On-chain DYOR: как проверить контракт, права администратора и реальные адреса

Contract address берут только из первичного источника

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

Никогда не основывайте DYOR на одном скопированном адресе из чата.

Verified source code позволяет изучить реальную логику

Source-code verification подтверждает соответствие опубликованного исходного кода deployed bytecode. Это позволяет исследовать функции контракта и сравнивать обещания проекта с фактической реализацией.

Неверифицированный критический контракт требует повышенного дисконта риска.

Mint privilege способен изменить supply

Проверьте, кто может создавать новые токены и существуют ли ограничения. Неограниченный mint у одного EOA — принципиально иной риск, чем capped issuance под multisig и timelock.

Даже если сейчас mint не используется, полномочие остаётся потенциальным.

Pause и blacklist могут быть полезными и опасными

Emergency pause помогает остановить exploit, но одновременно даёт администратору возможность блокировать операции. Blacklist необходим некоторым регулируемым активам, но делает систему менее permissionless.

DYOR не обязан считать эти функции плохими; он должен понимать, кто ими управляет и по каким правилам.

Proxy и upgradeability означают, что код может измениться

Verified implementation сегодня не гарантирует ту же логику завтра, если proxy admin способен обновить контракт. Проверьте upgrade authority, timelock и governance process.

Сильная процедура обновления снижает риск внезапной смены правил.

Multisig лучше одного ключа, но состав подписантов важен

Схема 3-of-5 выглядит надёжнее single-key, но если все пять ключей контролирует одна организация, реальная независимость ограничена. Ищите identity и role signers и организационное распределение.

Также важно, есть ли задержка перед критическим действием.

Holder distribution показывает концентрацию

После исключения системных адресов посмотрите крупнейших независимых holders. Сильная концентрация повышает market и governance risk.

Для нового токена несколько адресов способны контролировать почти весь free float.

Treasury movements нужно смотреть во времени

Один snapshot treasury недостаточен. Посмотрите историю переводов: регулярные выплаты, продажи, grants, market-maker allocations.

Необъяснимые крупные движения перед важным событием требуют дополнительного расследования.

Bridges добавляют внешний trust surface

Bridged token зависит не только от собственного контракта, но и от lock/mint logic моста. Компрометация bridge способна создать необеспеченные representations.

Проверяйте canonical asset и путь mint/burn между сетями.

Oracle risk особенно важен для lending и derivatives

Если протокол принимает collateral или рассчитывает liquidation по внешней цене, oracle становится критическим компонентом. Узнайте source, delay, fallback и manipulation resistance.

Плохой oracle способен разрушить безопасный на первый взгляд контракт.

On-chain элемент Что спросить
Contract Адрес подтверждён?
Source Совпадает с bytecode?
Mint Кто и сколько может создать?
Pause/blacklist Кто способен остановить операции?
Proxy Можно ли менять код?
Multisig Кто подписанты и threshold?
Holders Насколько концентрирован free float?
Treasury Как движутся средства?
Bridge/oracle Какие внешние зависимости?

Команда, инвесторы и governance: как проверить, кто реально контролирует проект

Псевдонимная команда не автоматически плохая

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

Если команда контролирует treasury, mint и upgrade, accountability становится важнее.

Проверяйте прошлые проекты и роль человека

Не ограничивайтесь биографией на сайте. Ищите предыдущие репозитории, публикации, governance activity, компании, продукты и реальные технические contributions.

Громкое название работодателя не означает, что человек занимал ключевую роль.

Инвестор не гарантирует качество токена

Известный фонд мог получить токены по низкой цене и иметь совсем другой risk/reward, чем публичный покупатель. Поэтому presence of VC — факт финансирования, а не инвестиционная рекомендация.

Проверяйте allocation, vesting и возможные конфликты интересов.

Market maker тоже имеет экономический интерес

Если проект распределил значительную долю market maker, узнайте срок, условия займа токенов и права на продажу. Такая структура способна влиять на free float и цену.

Без условий одна цифра allocation малоинформативна.

Governance token не всегда означает децентрализацию

Если quorum низкий, делегаты концентрированы, а foundation может veto proposal, governance может оставаться фактически централизованным.

Смотрите историю решений, а не название DAO.

Timelock даёт рынку время реагировать

Критическое изменение, которое вступает в силу через 48 часов, позволяет пользователю увидеть proposal и вывести средства. Мгновенный admin action лишает этого окна.

Поэтому timelock — важный operational risk control.

Emergency council — компромисс

Совет безопасности способен быстро остановить exploit, но концентрирует власть. Оцените threshold, публичность участников, scope полномочий и возможность отмены решения governance.

Цель DYOR — понять компромисс, а не объявить любую централизацию мошенничеством.

Community governance нужно проверять по turnout

Миллион holders не означает миллион активных участников. Реальный turnout может быть менее 1%. Это повышает влияние крупных делегатов.

Сравнивайте количество voters, voting power и распределение delegation.

Конфликт интересов должен быть записан

Founder может владеть токенами, фонд — финансировать проект, исследователь — получать grant. Эти связи не делают вывод ложным, но должны влиять на вес источника.

DYOR становится сильнее, когда economic incentives каждого источника явно учтены.

Участник Что проверять Почему важно
Founder Репутация и права Контроль и execution
VC Цена входа и vesting Sell pressure
Foundation Treasury и veto Governance
Market maker Allocation и договор Free float
Delegates Voting concentration Реальный контроль
Security council Threshold и scope Emergency powers

Рыночные метрики DYOR: ликвидность, volume, TVL, fees и valuation

Цена — последнее, с чего стоит начинать

Высокая или низкая цена одной монеты ничего не говорит без supply. Актив по 0,01 доллара способен иметь FDV выше актива по 10 000 долларов.

Сравнивайте рыночную оценку, а не номинал одной unit.

Market cap — контекст масштаба

Market cap полезен для сравнения размера, но не показывает сумму вложенных денег и не гарантирует ликвидность. Особенно осторожно относитесь к low-float assets.

Используйте его вместе с circulating supply и FDV.

Liquidity отвечает на вопрос выхода

DYOR должен включать не только возможность купить, но и возможность продать. Оцените depth, price impact и долю вашей позиции относительно доступной ликвидности.

Высокий экранный ROI без выхода — бумажный результат. Для более точной проверки используйте материал OneMagic о ликвидности криптовалюты.

Volume можно накрутить или создать incentives

Объём показывает оборот, но не обязательно органический спрос. Incentives и market making могут увеличивать цифру.

Полезно сравнивать volume с fees и долгосрочной динамикой.

TVL не равен revenue

Total Value Locked измеряет стоимость активов в протоколе по методике. Большой TVL может приносить мало fees, а небольшой — иметь высокую capital efficiency.

Не используйте TVL как универсальную оценку качества.

Fees и revenue нужно разделять

Users могут платить fees, которые полностью уходят LP или validators. Protocol revenue — только часть, которую получает сам протокол или treasury по правилам.

Token value capture — ещё один отдельный шаг.

P/S и FDV/revenue требуют нормализации

Сравнение valuation multiples возможно только между похожими бизнес-моделями. Protocol с subsidies и protocol с organic revenue нельзя сравнивать одной цифрой.

Также учитывайте token inflation: высокий revenue не компенсирует огромную emission автоматически.

Рост метрики нужно разложить на цену и количество

TVL или treasury value могут расти просто из-за подорожания underlying assets. Чтобы понять real inflow, смотрите units и net flows.

Долларовый график без decomposition может вводить в заблуждение.

Stablecoin supply иногда показывает использование сети

Рост stablecoin balances может свидетельствовать о доступном расчётном капитале, но не гарантирует активность. Часть средств может лежать неиспользуемой.

Смотрите вместе с transactions, users и fees.

Benchmark нужен даже для фундаментального анализа

Если проект вырос на 20%, а его сектор вырос на 80%, relative performance слабая. Но цена не должна заменять фундамент: benchmark используется как дополнительный контекст.

Сравнивайте и бизнес-метрики, и рыночный результат.

Метрика Полезна для Чего не доказывает
Market cap Масштаб Ликвидность
FDV Dilution context Будущую цену
Liquidity Исполнимость выхода Фундамент
Volume Оборот Органический спрос
TVL Размер капитала в протоколе Revenue
Fees Готовность платить Token accrual
Revenue Экономику протокола Ценность token автоматически

Red flags: что должно остановить DYOR до покупки

Гарантированная доходность

Обещания гарантированной прибыли, особенно высокой и быстрой, противоречат природе рискованного рынка. Если продавец не способен объяснить источник дохода, прекращайте исследование.

В инвестиционном анализе обещание гарантированного результата — не преимущество, а сигнал повышенного риска.

Давление «нужно купить сейчас»

Искусственная срочность мешает проверке. Если вам объясняют, что через час шанс исчезнет, остановите решение минимум на сутки.

Настоящая инвестиционная идея должна пережить проверку и отсутствие эмоционального давления.

Секретная стратегия без проверяемой механики

Фраза «алгоритм зарабатывает, но раскрыть нельзя» не заменяет объяснение источника PnL. Вы должны понимать, откуда экономически возникает результат.

Закрытый код возможен, но тогда повышается trust requirement и цена ошибки.

Фальшивые партнёрства

Логотип крупной компании на сайте ничего не доказывает. Найдите подтверждение на стороне партнёра или официальный документ.

Если партнёрство существует только в посте проекта, считайте его неподтверждённым.

Audit badge без отчёта

Логотип аудитора должен вести к реальному отчёту с датой, scope и commit hash. Старый audit для другой версии кода не покрывает текущий контракт.

Также проверьте unresolved findings и изменения после аудита.

Неверифицированный контракт при большом TVL

Если пользователи доверяют контракту существенный капитал, а deployed code невозможно сопоставить с source, информационный риск высок.

Это не автоматический scam, но серьёзный stop-signal.

Необъяснимый mint или admin key

Если один адрес способен без лимита выпустить supply или вывести treasury, а проект это не раскрывает, риск несопоставим с обычным market risk.

Вопрос должен быть решён до покупки.

Копирование whitepaper и команды

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

Несоответствия имён, дат и репозиториев — повод остановиться.

Соцсети с огромной аудиторией и слабой on-chain активностью

Разрыв между миллионами подписчиков и несколькими сотнями пользователей может указывать на маркетинговую модель или накрутку.

Сравните social reach с usage.

Seed phrase, private key или удалённый доступ

Никакой DYOR, support или recovery procedure не требует передавать seed-фразу. Запрос private key или recovery phrase означает, что контакт нужно немедленно прекратить.

Для безопасности исходите из принципа: секреты кошелька никогда не передаются третьей стороне.

Платная «разблокировка прибыли»

Если после якобы успешной инвестиции требуют дополнительную оплату для вывода, налога, AML-сертификата или восстановления, не отправляйте новые средства.

Попытка вернуть уже потерянное часто используется для второй волны мошенничества.

Red flag Действие
Гарантия прибыли Отказаться
Срочность Остановить решение минимум на сутки
Нет источника дохода Не инвестировать
Партнёрство не подтверждается Считать ложным до проверки
Audit без отчёта Не учитывать как защиту
Unlimited mint Понять authority или отказаться
Seed phrase request Немедленно прекратить контакт
Платная разблокировка Не переводить новые средства

Практический DYOR: чек-лист на 10 минут, 1 час и полный разбор

10 минут: фильтр очевидного риска

Цель быстрого фильтра — не решить покупать, а понять, стоит ли тратить время дальше. Проверьте сайт, документацию, contract address, supply, top holders, наличие product, verified source и критические admin rights.

Если уже здесь обнаружен unlimited mint без объяснения или фальшивые партнёры, полный анализ не нужен.

10 минут: проверьте адрес и сеть

Сверьте token contract минимум в двух официальных местах. Откройте explorer и убедитесь, что именно этот адрес используется в продукте.

Не полагайтесь на поиск по тикеру.

10 минут: посмотрите supply и концентрацию

Сравните circulating, total, max supply и крупнейших holders. Небольшой free float при огромном FDV — повод перейти к vesting.

Сразу классифицируйте treasury и системные контракты.

1 час: прочитайте документацию по вопросам, а не подряд

Создайте список: продукт, token utility, fees, governance, oracle, upgrade, mint, treasury, vesting. Ищите ответы напрямую.

Так исследование быстрее, чем линейное чтение сотен страниц.

1 час: проверьте реальные метрики

Сопоставьте заявления о пользователях, TVL, fees и revenue с доступными on-chain или аналитическими данными.

Если цифры различаются, выясните методику.

1 час: постройте supply timeline

На ближайшие 12 месяцев запишите основные unlock и emission. Рассчитайте, на сколько процентов может вырасти circulating supply.

Сравните это с предполагаемым источником спроса.

1 час: составьте dependency map

Нарисуйте проект в центре и вокруг: oracle, bridge, custodian, governance, multisig, chain, front-end, stable assets. Для каждого элемента запишите failure mode.

Так становятся видны риски, которых нет в whitepaper.

Полный разбор: сформулируйте инвестиционный тезис

Тезис должен быть проверяемым: «пользовательская активность растёт, token необходим для X, supply dilution уменьшается, valuation ниже сопоставимых проектов».

Фраза «сектор перспективный» слишком общая.

Полный разбор: напишите bear case

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

Если портфель не выдерживает такой сценарий, размер позиции слишком велик.

Полный разбор: определите kill criteria

Kill criteria — факты, после которых thesis считается сломанным: потеря ключевого integration, governance capture, exploit без адекватной реакции, падение organic users, изменение token utility.

Запишите их до покупки, пока цена не влияет на рассуждение.

Полный разбор: назначьте monitoring cadence

Не все метрики нужно проверять ежедневно. Unlock schedule — ежемесячно, governance — по proposals, security incidents — по событиям, revenue и users — раз в неделю или месяц.

Слишком частый мониторинг цены только усиливает эмоциональные решения.

Scorecard помогает сравнивать проекты одинаково

Создайте десять категорий по шкале 0–5: продукт, пользователи, token utility, supply, governance, contract security, liquidity, team, valuation, transparency. Итоговая сумма не заменяет решение, но уменьшает влияние красивого нарратива.

Критический red flag должен иметь veto независимо от общей суммы.

Decision log защищает от переписывания истории

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

Это позволяет учиться не только на PnL, но и на качестве процесса.

Пример оценки нового DeFi-протокола

Продукт работает, но 80% TVL пришло за месяц incentives. Token нужен для governance, fee sharing пока отсутствует. Через три месяца unlock команды увеличит circulating supply на 25%. Контракт audited, но upgrade admin — 2-of-3 multisig без timelock. Вывод: техническая часть приемлема, но экономический и governance risk высоки.

DYOR не обязан давать бинарное «scam или не scam». Он помогает определить, какие риски вы реально покупаете.

Пример оценки RWA-проекта

On-chain контракт простой и verified, но underlying управляется SPV. Значит, основная работа смещается в юридическую структуру, custody, redemption и bankruptcy remoteness.

Одинаковый чек-лист адаптируется к типу актива.

Пример оценки новой сети

Для собственной сети важнее validator concentration, client diversity, token issuance, gas demand, ecosystem usage и bridge dependencies. Проверка одного token contract здесь почти бессмысленна.

DYOR начинается с архитектуры объекта.

Финальный чек-лист

  1. Определить, что именно является объектом: token, protocol, network, RWA или stable asset.
  2. Собрать первичные источники и contract addresses.
  3. Проверить рабочий продукт и реальные usage-метрики.
  4. Объяснить token utility без слов «цена вырастет».
  5. Разобрать circulating supply, FDV, allocation, vesting и emission.
  6. Проверить verified source, mint, pause, proxy, multisig и admin rights.
  7. Классифицировать крупнейших holders и treasury.
  8. Проверить governance и фактическую концентрацию голосов.
  9. Оценить liquidity и возможность выхода нужным объёмом.
  10. Отделить TVL, fees, revenue и token value capture.
  11. Проверить team, investors и конфликты интересов.
  12. Найти минимум три red flags или bear arguments.
  13. Сформулировать thesis и kill criteria.
  14. Определить position size и горизонт.
  15. Записать решение в decision log.

Практикум: как проверять заявленное партнёрство

Представим, что на главной странице проекта размещены логотипы известной технологической компании, банка и крупного блокчейн-фонда. Не записывайте это автоматически в преимущества. Сначала определите точную формулировку: partnership, technology integration, grant, accelerator, infrastructure provider или просто ecosystem participant. Эти статусы различаются по экономическому смыслу. Далее найдите подтверждение на стороне партнёра: официальный пресс-релиз, документацию интеграции, репозиторий, программу грантов или упоминание в реестре участников. Если подтверждения нет, снижайте вес утверждения до нуля.

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

Практикум: как читать отчёт аудита без технического образования

Откройте отчёт и найдите четыре вещи: дату, scope, commit hash и список findings. Scope показывает, какие именно контракты проверялись; commit hash позволяет сопоставить аудит с конкретной версией исходного кода. Если deployed implementation позже обновлялся, старый audit может не покрывать production. Затем изучите severity: critical, high, medium, low и informational. Важно не количество замечаний само по себе, а то, какие из них исправлены, какие acknowledged и какие остались открытыми.

Если проект показывает только логотип аудитора без прямой ссылки на отчёт, не учитывайте этот факт как защиту. Если отчёт существует, но покрывает один token contract, а основной риск находится в bridge, oracle или vault, аудит не закрывает систему целиком. Наконец, спросите, кто может обновить audited contract после проверки. Upgradeable proxy под одним admin key способен превратить сильный audit в исторический документ уже на следующий день.

Практикум: как исследовать treasury и реальный runway

Составьте список treasury addresses и классифицируйте активы: stablecoins, BTC/ETH, собственный token, LP-позиции, locked assets и прочие позиции. Затем посмотрите крупнейшие движения минимум за три месяца. Разделите их на payroll, grants, liquidity, market-making, investments и неизвестные переводы. Если проект заявляет runway на три года, попробуйте воспроизвести расчёт только на основе действительно ликвидных внешних активов и разумной оценки расходов.

Собственный токен проекта нельзя считать эквивалентом cash по последней цене. В стрессовый момент стоимость token treasury падает одновременно с доверием к проекту, а продажа крупного пакета ухудшает ликвидность. Поэтому полезно считать два runway: nominal, включающий все активы, и conservative, где собственный token получает сильный discount или исключается. Большая разница между этими числами показывает зависимость проекта от собственной рыночной капитализации.

Практикум: как проверить, действительно ли token нужен продукту

Проведите counterfactual test: мысленно удалите token из продукта. Может ли система продолжить работу, если fees оплачиваются другим активом, governance заменяется multisig, а rewards — обычной программой лояльности? Если да, связь между product success и token demand может быть слабой. Затем спросите, кто обязан покупать token по мере роста usage: пользователи, валидаторы, borrowers, провайдеры безопасности или никто.

Если token используется для governance, выясните, контролирует ли голосование экономически значимые параметры: fee switch, treasury, risk limits, upgrades, emissions. Governance над косметическими вопросами создаёт намного меньше value capture. Если token нужен как collateral, проверьте, насколько этот collateral реально востребован и не субсидируется ли спрос огромными incentives. Цель DYOR — найти механизм, который связывает рост продукта с устойчивым спросом на token.

Практикум: как отличить органических пользователей от охотников за наградами

Количество active addresses особенно легко интерпретировать неверно. Один человек может создавать десятки кошельков, а incentive campaign — временно приводить сотни тысяч адресов. Поэтому смотрите не только total users, но и repeat users, cohort retention, среднее число действий на адрес и долю пользователей, которые продолжают пользоваться продуктом после уменьшения rewards. Если доступно, сравните платящих пользователей с бесплатными участниками кампаний.

Сильный тест — сравнить три периода: до incentives, во время и после. Если usage вырос в десять раз на фоне airdrop points и сразу вернулся к прежнему уровню после завершения программы, доказательство product-market fit слабое. Если часть пользователей остаётся, продолжает платить fees и возвращается без дополнительной субсидии, качество спроса выше. DYOR должен отделять купленную активность от устойчивого поведения.

Практикум: как проверить ликвидность до покупки

Определите предполагаемый размер позиции и смоделируйте не вход, а выход. Если вы планируете вложить 20 000 долларов, посмотрите, какой price impact даст продажа 20 000, 40 000 и 60 000 при ухудшении рынка. Учтите, что текущая depth способна исчезнуть именно тогда, когда все хотят выйти. Для concentrated liquidity отдельно проверьте, находится ли капитал в активном диапазоне около текущей цены.

Market cap здесь почти бесполезен как замена. Токен с капитализацией 300 млн долларов способен иметь только несколько сотен тысяч долларов активной глубины. Если ваша позиция составляет существенную долю depth, экранная цена становится теоретической. В scorecard можно добавить отдельный liquidity discount: чем сложнее выйти без сильного price impact, тем меньше допустимый position size независимо от фундаментального качества проекта.

Практикум: как искать информацию, которая опровергает вашу идею

После позитивного анализа сформулируйте противоположный тезис. Если вы считаете, что проект растёт благодаря product-market fit, ищите данные, что рост куплен incentives. Если считаете token дефицитным, ищите скрытые emissions, vesting и treasury sales. Если уверены в децентрализации, проверьте upgrade keys, quorum и delegation. Смысл — намеренно создать конкурирующее объяснение тех же фактов.

Лучший найденный bear argument следует включить в итоговую карточку рядом с bull case. Затем спросите, какой факт позволит различить эти две версии в течение следующих месяцев. Например, органический growth должен сохраняться после снижения rewards; устойчивый fee demand должен расти вместе с usage; реальная децентрализация должна проявляться в governance turnout и невозможности одного участника провести критическое изменение. Так DYOR превращается в проверяемую гипотезу.

Практикум: DYOR новой L1 или L2 сети

Для сети checklist токена недостаточен. Начните с consensus или sequencing model: кто производит блоки, сколько независимых validators или sequencers, какие hardware requirements, существует ли client diversity. Затем изучите finality, data availability, bridge model, upgrade keys и возможность emergency intervention. У L2 отдельно важно понять, какие гарантии наследуются от базовой сети и какие остаются под контролем оператора.

После security layer переходите к экономике: token issuance, staking ratio, gas demand, stablecoin liquidity, активность разработчиков и приложений. Сеть может иметь впечатляющий TVL, который почти полностью перенесён одним bridge или поддерживается incentives. Сравните unique apps, repeat users, fees и долю активности, которая сохраняется без субсидий. У network DYOR объектом является вся система зависимостей, а не один smart contract.

Практикум: как определить размер позиции после хорошего DYOR

Качество исследования не должно превращаться в чрезмерную уверенность. Даже проект с сильным продуктом, прозрачной токеномикой и audited code способен потерять большую часть стоимости из-за общего рынка, неизвестной уязвимости или регуляторного события. Поэтому position size выбирают не по эмоциональной уверенности, а по максимально допустимому убытку и общей структуре портфеля.

Полезный стресс-вопрос: если актив завтра снизится на 70%, liquidity ухудшится и восстановление займёт два года, нарушит ли это мои обязательства или инвестиционный план? Если да, позиция слишком велика. Хороший DYOR может увеличить качество идеи, но не отменяет диверсификацию и риск-бюджет. Отдельный материал OneMagic о размере позиции полезен именно после завершения исследования.

Практикум: как обновлять DYOR после покупки

Сделайте monitoring sheet из пяти–десяти метрик, напрямую связанных с thesis. Для DeFi это могут быть organic users, fees, revenue, utilization, liquidity, circulating supply и next unlock. Для L1 — fees, active applications, validator concentration и stablecoin supply. Для RWA — underlying value, redemption, issuer disclosures и custody. Если показатель не способен изменить решение, его не обязательно мониторить.

Установите частоту: governance proposals и security incidents проверяются по событиям, unlock — по календарю, financial и usage metrics — раз в неделю или месяц. На каждом review задайте один вопрос: изменился ли исходный thesis? Цена может падать без ухудшения фундаментальных данных и оставаться стабильной при разрушении продукта. Monitoring нужен для проверки причины владения, а не для постоянного наблюдения за графиком.

Практикум: DYOR стейблкоина

Для stable asset основная логика отличается от governance token. Сначала выясните модель: fiat-backed, crypto-collateralized, algorithmic или hybrid. Для резервной модели нужны issuer, состав резервов, частота раскрытия, custodian, право redemption и ограничения пользователей. Цена около одного доллара не доказывает полноценность backing; она лишь показывает текущий рыночный результат. Сильный DYOR пытается понять, что произойдёт при массовом погашении.

Для on-chain collateral проверьте collateral ratio, oracle, liquidation incentives и концентрацию залога. Смоделируйте резкое падение основного collateral и одновременное ухудшение liquidity. Если система зависит от governance token самого проекта, учитывайте коррелированный риск. Материал OneMagic о стейблкоинах можно использовать как отдельный технический слой внутри общего DYOR.

Практикум: DYOR lending-протокола

Для lending market недостаточно посмотреть TVL и APY. Разделите deposits, borrows, available liquidity и utilization. Высокий utilization увеличивает ставку для borrowers, но одновременно уменьшает доступность немедленного вывода lenders. Проверьте collateral factors, liquidation thresholds, oracle architecture и bad-debt history. Если market поддерживает экзотические collateral assets, отдельно оцените их liquidity в стрессовом сценарии.

Затем изучите governance risk: кто способен изменить collateral parameters, добавить новый market или обновить implementation. Посмотрите, существует ли emergency guardian и какие полномочия у него есть. Сильный протокол может иметь хороший codebase и одновременно быть уязвимым к неправильным risk parameters. DYOR lending — это исследование credit engine, а не просто сравнение процентных ставок.

Практикум: DYOR bridge

Bridge анализируется как система custody и message verification. Определите, что происходит с исходным активом: lock, burn или escrow. Кто подтверждает событие в другой сети — validators, multisig, light client или optimistic mechanism? Сколько участников требуется для компрометации? Как устроены лимиты и emergency pause? Убедитесь, что representation действительно можно redeem обратно в canonical asset.

История bridge incidents важнее общего TVL. Посмотрите, были ли exploits, как быстро обнаруживались проблемы и кто покрыл убытки. Большой объём locked assets повышает не только доверие, но и value at risk. Если bridge admin может заменить validator set или обновить verification contract мгновенно, этот ключ становится центральным элементом DYOR независимо от количества пользователей.

Практикум: DYOR проекта перед крупным unlock

Не ограничивайтесь датой unlock. Определите, кто получает токены, какова их cost basis, есть ли договорные ограничения, насколько размер транша велик относительно daily liquidity и circulating supply. Unlock команды на 2% supply и unlock ранних инвесторов на 20% free float — разные события. Затем изучите предыдущие unlock: переводились ли токены на custody, treasury, market maker или оставались на адресах.

Сценарный анализ полезнее предсказания цены. В базовом сценарии получатели не продают, в умеренном — реализуют 10–20% транша, в стрессовом — значительная часть выходит на рынок при слабой liquidity. Рассчитайте потенциальный объём относительно доступной depth. Так unlock превращается из эмоционального календарного события в измеримый supply risk.

Практикум: как проверить концентрацию governance

Откройте последние десять proposals и запишите долю голосов крупнейших делегатов. Если несколько адресов регулярно определяют исход, governance nominally open, но practically concentrated. Затем проверьте quorum и возможность delegation. Низкий turnout делает систему особенно чувствительной к крупным holders. Посмотрите, есть ли veto, emergency council и возможность foundation менять параметры вне обычного голосования.

Отдельно оцените voter incentives. Если голосование оплачивается rewards, participation может быть высоким количественно и слабым по качеству. Если крупные delegates получают grants от foundation, возникает экономическая зависимость. DYOR не требует идеальной децентрализации; он требует честно описать реальный control plane и понять, кто способен изменить правила, влияющие на капитал пользователя.

Практикум: как проверять команду без охоты за личными данными

Цель проверки команды — не собирать частную информацию, а подтвердить профессиональную историю и accountability. Ищите публичные продукты, репозитории, исследования, конференционные выступления, governance posts и предыдущие проекты. Сопоставляйте даты и роли. Если человек заявлен как lead developer известной системы, должно быть возможно найти технические contributions или публичное подтверждение этой роли.

Если команда псевдонимная, переносите вес на on-chain controls: ограничены ли admin powers, есть ли multisig, timelock, независимые auditors и распределённое governance. Псевдонимность при минимальных полномочиях — одна модель риска; псевдонимность при полном контроле treasury и upgrade — другая. DYOR должен оценивать систему контроля, а не социальный статус человека.

Если проект зависит от юридического эмитента, custody, RWA или регулируемого продукта, найдите entity name, jurisdiction, terms, restrictions и процедуру redemption. Не делайте вывод «легально» только из регистрации компании. Регистрация подтверждает существование юридического лица, но не обязательно разрешение конкретной деятельности. Для значимой позиции документы могут потребовать профессиональной правовой оценки.

Особенно внимательно относитесь к обещаниям «регулируется во всех странах» или «имеет международную лицензию» без точного названия органа и номера разрешения. Проверьте реестр соответствующего регулятора. Если компания утверждает, что не обслуживает вашу юрисдикцию, попытка обходить ограничения создаёт отдельный operational и legal risk, который нельзя компенсировать высокой ожидаемой доходностью.

Практикум: как оценивать social sentiment без попадания в толпу

Социальные данные полезны, если рассматривать их как температуру нарратива. Сравните рост подписчиков с ростом пользователей и on-chain activity. Посмотрите качество дискуссий: преобладают технические вопросы и product feedback или только прогнозы цены и referral posts. Слишком синхронные сообщения одинакового содержания могут указывать на coordinated promotion. При этом негативная дискуссия тоже не означает автоматически плохой проект.

Используйте соцсети для поиска вопросов, которые затем проверяются первично. Если community утверждает, что новая версия увеличила fees, найдите on-chain данные. Если жалуются на withdrawals, изучите contract state и официальные incident reports. Social sentiment становится полезным, когда генерирует гипотезы, а не заменяет evidence.

Практикум: как построить единый DYOR score без ложной точности

Создайте десять категорий по пять баллов, но не относитесь к сумме как к математической fair value. Например: product 4, users 3, token utility 2, tokenomics 1, contract security 4, governance 2, liquidity 3, team 4, valuation 2, transparency 5. Общая сумма помогает сравнить два проекта по одному процессу и увидеть слабые зоны, но не говорит, что актив с 34 баллами обязательно лучше актива с 32.

Добавьте veto-факторы: unverifiable contract, seed-phrase request, unlimited mint без контроля, ложное партнёрство, отсутствующий reserve при обещании backing. Один такой фактор может остановить решение независимо от score. Это защищает от компенсации критического риска множеством второстепенных плюсов. Scorecard — дисциплина последовательности, а не способ превратить неопределённость в точную цифру.

Практикум: пост-анализ после прибыли и после убытка

После закрытия позиции не оценивайте качество DYOR только по PnL. Хорошее исследование может привести к убытку из-за рыночного режима, а плохое — случайно дать большую прибыль. Сравните исходный thesis, ожидаемые catalysts, risks и kill criteria с фактическими событиями. Какие данные были правильно интерпретированы? Что пропущено? Какой источник оказался ненадёжным? Где решение нарушило собственный план?

Создайте две оценки: outcome quality и process quality. Первая измеряет финансовый результат, вторая — качество принятия решения на основе доступной тогда информации. Такой разбор превращает DYOR в обучаемый процесс. Цель не в том, чтобы никогда не ошибаться, а в том, чтобы одинаковые ошибки не повторялись из-за отсутствия системы.

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

Новый токен может быстро набрать внимание благодаря теме AI, RWA, gaming или другой популярной категории. В DYOR сначала уберите название сектора и спросите, что уже работает. Есть ли контракт, продукт, пользователи, fees, SDK, интеграции? Если всё ценностное предложение состоит из будущих обещаний, valuation фактически основана на ожиданиях. Это не запрещает спекуляцию, но риск должен быть назван правильно: вы покупаете execution и narrative risk, а не работающий бизнес.

Далее сравните valuation с более зрелыми проектами того же сектора. Если новый token имеет похожий FDV при отсутствии продукта и пользователей, инвестор платит большой premium за будущее. Если FDV ниже, это ещё не делает актив дешёвым: будущие unlock и низкий free float могут быстро изменить оценку. DYOR должен связывать цену с текущей стадией развития, а не только с размером потенциального рынка.

Кейс: очень высокий APY как повод проверить источник денег

Если протокол показывает APY 200%, начните с decomposition. Какая часть создаётся borrower interest или trading fees, какая — новым token emission, какая — временным grant? Затем оцените, кто покупает reward token и почему. Если весь доход фактически выплачивается новой эмиссией, участник получает больше единиц актива, который одновременно размывается. Высокий процент начислений может сопровождаться отрицательным ROI.

Проверяйте устойчивость без incentives. Смоделируйте, что reward emission завтра уменьшается на 80%. Останутся ли deposits, borrowers или liquidity? Если пользователи уйдут, продукт конкурирует размером субсидии, а не качеством услуги. Такой вывод важнее рекламного APY и помогает понять, является ли доходность результатом экономической активности или перераспределением нового supply.

Кейс: новый токен после airdrop

После airdrop circulating supply часто распределён между получателями с почти нулевой cost basis, командой, инвесторами и treasury. Первые недели могут показывать большую волатильность, потому что разные группы имеют разные стимулы. Проверьте долю airdrop в circulating supply, claim rate, непроданные allocations и ближайшие unlock. Высокий процент неclaimed token тоже важен: он способен выйти на рынок позже.

Отдельно посмотрите, сохранилась ли активность продукта после snapshot. Если пользователи участвовали только ради airdrop, usage способен резко снизиться после раздачи. Сравните retention, fees и repeat users. DYOR после TGE должен обновляться: данные до запуска токена описывали ожидание reward, а данные после запуска показывают, остаётся ли самостоятельный спрос на продукт.

Кейс: протокол пережил exploit

Сам факт прошлого exploit не означает, что проект нужно навсегда исключить. Исследуйте причину, размер потерь, скорость реакции, качество post-mortem и изменения архитектуры. Команда, которая публикует точную техническую причину, компенсирует пользователей по прозрачным правилам и устраняет root cause, отличается от команды, которая скрывает детали и обвиняет внешних участников.

Проверьте, остались ли те же admin keys, oracle и upgrade paths, которые привели к проблеме. Посмотрите повторный аудит и реальные code changes. История инцидента может даже дать больше информации о качестве операционной команды, чем безупречный маркетинговый профиль проекта, который ещё ни разу не проходил стресс. Но повторяющиеся однотипные ошибки — сильный отрицательный сигнал.

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

Большой treasury способен финансировать годы разработки, но иногда создаёт иллюзию устойчивой бизнес-модели. Рассчитайте burn rate расходов и отдельно operating revenue. Если продукт ежегодно расходует 30 млн долларов, а получает 2 млн fees, runway зависит от капитала, а не от самофинансирования. Это может быть нормальной стадией роста, но оценка должна учитывать необходимость будущего финансирования.

Смотрите, в каких активах хранится treasury. Если половина состоит из собственного token, рыночное падение одновременно уменьшает runway и доверие к проекту. Если treasury диверсифицирован в stable assets, риск ниже. DYOR должен ответить, сколько месяцев команда может работать без новых token sales и насколько сильно такие продажи увеличат давление на рынок.

Кейс: высокая on-chain активность от одного приложения

Сеть может показывать рост transactions и active addresses, но почти вся активность генерируется одним приложением. Это концентрационный риск экосистемы. Если приложение уйдёт на другую сеть или потеряет аудиторию, network metrics резко ухудшатся. Разбейте activity по приложениям и категориям, чтобы понять диверсификацию спроса на blockspace.

Для native token это особенно важно, если инвестиционный тезис основан на gas demand. Сто тысяч транзакций от устойчивого набора приложений и тот же объём от одной incentive-игры имеют разное качество. Наблюдайте fee-paying activity, а не только transaction count. Сеть с низкими fees может иметь огромный throughput и очень маленький реальный денежный спрос.

Кейс: фонд или известный инвестор вошёл в проект

Публичное имя фонда часто воспринимается как внешний знак качества. DYOR должен выяснить условия. На какой стадии инвестор вошёл, по какой оценке, получает ли equity, tokens, warrants, advisory allocation или отдельные права? Если фонд купил token эквивалентно по 0,02 доллара, а публичный рынок оценивает его в 1 доллар, risk-reward сильно различается.

Затем проверьте vesting и возможность secondary sale. Инвестор может быть долгосрочным участником или иметь право на ликвидность значительно раньше команды. Наличие крупного фонда полезно как подтверждение того, что кто-то провёл собственную проверку, но не позволяет делегировать ему ваше решение. У вас другой горизонт, цена входа и ограничения.

Кейс: проект меняет токеномику после запуска

Изменение emissions, max supply, fee distribution или staking rules не обязательно негативно: система может адаптироваться к реальным данным. Но инвестору важно оценить процесс и перераспределение выгод. Кто инициировал изменение, кто голосовал, какая группа получает преимущество, был ли timelock и могли ли holders выйти до вступления новых правил в силу?

Сравните исходный thesis с новой моделью. Если вы покупали token из-за ограниченного supply, а governance разрешила постоянную эмиссию, фундаментальная причина владения изменилась. Нельзя оправдывать такой сдвиг только потому, что цена пока не отреагировала. Kill criteria существуют именно для моментов, когда правила меняются раньше котировки.

Кейс: токен торгуется дорого при очень маленьком free float

Низкий circulating supply способен создать впечатляющую цену и небольшую market cap при огромном FDV. Проверьте, какая доля токенов реально доступна рынку и сколько будет разблокировано в ближайший год. Если free float составляет 5%, а оставшиеся 95% принадлежат инвесторам, команде и treasury, текущая цена формируется на очень узкой базе. Небольшой спрос способен двигать котировку сильнее, чем в зрелом активе.

Сделайте простую таблицу dilution: circulating сегодня, через три, шесть и двенадцать месяцев. Затем сравните прирост supply с текущим daily liquidity. Если будущий unlock равен десяткам дневных объёмов, рынок может испытывать давление даже без негативных новостей. Это не прогноз падения, а измерение structural risk, которое должно влиять на valuation и размер позиции.

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

Иногда приложение популярно, fees растут, пользователи довольны, но token почти не участвует в экономике. Он может давать только governance без fee rights, не использоваться как gas и не быть обязательным collateral. Тогда успех продукта и стоимость token связаны слабее, чем кажется. Инвестор фактически покупает ожидание будущего value capture, а не существующий денежный механизм.

В DYOR разделите business quality и token quality на две оценки. Сильный продукт способен существовать с плохим token design, а посредственный продукт — временно иметь сильную спекулятивную токеномику. Такой раздельный score помогает не переносить успех команды на актив автоматически. Если thesis требует будущего fee switch, запишите это как catalyst, а не как уже существующую ценность.

Кейс: быстро растущая сеть субсидирует почти все fees

Если пользователей привлекают grants, rebates или бесплатный gas, transaction count может расти быстрее реального спроса. Сравните gross activity с net fees, которые остаются после субсидий. Посмотрите, сколько стоит привлечь одного пользователя и возвращается ли он после окончания программы. Очень дешёвая активность полезна для bootstrap, но не всегда доказывает устойчивую экономику.

Для native token важен вопрос: создаёт ли рост использования обязательный спрос на token или расходы фактически компенсирует foundation. Если второй вариант доминирует, высокие network metrics могут существовать одновременно со слабым value capture. DYOR должен отделять технологическую пропускную способность от готовности пользователей платить за blockspace.

Кейс: исследователь ошибся, но процесс был правильным

Предположим, DYOR показал хороший продукт, умеренную valuation, прозрачный контракт и сильную liquidity. После покупки весь сектор падает на 60% из-за внешнего макрособытия. Финансовый результат плохой, но это не обязательно означает ошибку исследования. В post-mortem нужно спросить, был ли внешний сценарий учтён в position sizing и мог ли инвестор выдержать просадку.

Обратный случай опаснее: актив дал +300%, хотя research игнорировал unlimited mint, ложные партнёрства и слабую ликвидность. Прибыль не превращает плохой процесс в хороший. Если оценивать DYOR только по цене после сделки, инвестор будет закреплять случайные привычки. Качество процесса измеряется тем, насколько решение соответствовало доступным данным и заранее установленным правилам риска.

Последняя проверка перед решением: что осталось неизвестным

Перед финальным решением составьте отдельный список unknowns. Не все неизвестные одинаково опасны: отсутствие точного прогноза цены нормально, а неизвестный владелец upgrade key или непонятный источник collateral — критично. Разделите вопросы на три категории: можно принять, нужно мониторить, нельзя принимать. Инвестиция не должна проходить дальше, если в третьей категории остаётся хотя бы один фактор, способный уничтожить капитал.

Такой список полезнее попытки добиться абсолютной уверенности. DYOR не устраняет неизвестность, а делает её видимой и управляемой. Если риск невозможно измерить, ограничить или хотя бы описать, position size должен уменьшаться вплоть до нуля. Именно это отличает исследование от уверенного рассказа о проекте.

Итог

DYOR в криптовалюте — это не лозунг и не обязанность читать всё подряд. Это дисциплина проверки: отделить источник от рекламы, продукт от обещаний, токеномику от нарратива, on-chain факты от презентации и рыночную цену от фундаментальной гипотезы. Чем сложнее проект, тем важнее разбить его на проверяемые слои.

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

Если после проверки остаются неизвестные критические параметры — unlimited admin rights, неясный reserve, непонятная utility или неподтверждённая ликвидность — отсутствие ответа само является ответом. Иногда лучший результат DYOR — не новая инвестиция, а решение сохранить капитал.

Для практического продолжения используйте OneMagic чек-лист проверки токена, а для оценки рынка — материал о капитализации, ликвидности и структуре крипторынка.