Цей розділ — практичний довідник із аналізу Solana для фаундерів, дослідників та інвесторів. Тут зібрано методології, за допомогою яких можна самостійно оцінювати стан мережі, розрізняти реальне зростання від штучно роздутих метрик і приймати рішення на основі доказів, а не наративів.
Щомісячний огляд змін екосистеми Solana
Методологія відбору значущих змін
Щомісячний огляд потребує чіткого фільтра, інакше він перетворюється на каталог комітів. Значущою вважається зміна, яка впливає хоча б на одну з трьох груп: користувачів, розробників чи валідаторів. Усе інше — технічний шум, корисний для вузьких спеціалістів, але не для оглядового матеріалу.
Ключові події місяця: оновлення протоколу, нові проєкти
Оновлення протоколу фіксуються за релізами клієнтів (Agave, Firedancer, Jito тощо) та активованими SIMD-пропозиціями. Нові проєкти відбираються не за кількістю пресрелізів, а за наявністю працюючого продукту на mainnet-beta та відстежуваною активністю користувачів.
Зміни, що впливають на користувачів
Тут фіксуються зміни в комісіях, часі фіналізації, нові типи транзакцій, оновлення гаманців та інтерфейсів, які змінюють досвід взаємодії з мережею. Якщо зміна стосується лише внутрішньої архітектури й не помітна кінцевому користувачу — вона не потрапляє до цієї категорії.
Зміни, що впливають на розробників
Оновлення Anchor, зміни в RPC-провайдерах, нові інструменти для дебагінгу, зміни в моделі обчислювальних бюджетів — це ті події, які визначають, чи стане розробка на Sol простішою чи складнішою цього місяця. Детальніші технічні розбори доступні в розділі розширеної розробки.
Зміни, що впливають на валідаторів
Зміни в моделі інцентивізації, оновлення вимог до апаратного забезпечення, зміни в механіці slashing (якщо такі обговорюються), нові інструменти моніторингу. Цей блок орієнтований на операторів нод, детальніше про яких — у матеріалі про валідатори Solana.
Обмеження: що не включено та чому
До огляду не потрапляють: релізи тестнетів без прив'язки до mainnet-плану, зміни в токеноміці окремих проєктів (це окрема аналітика), спекулятивні прогнози без емпіричної бази. Мета огляду — зафіксувати те, що відбулося, а не те, що може статися.
Які метрики справді корисні для аналізу Solana
Метрики мережевої активності: TPS, транзакції, унікальні адреси
Solana регулярно фіксує високий TPS (transactions per second), але ця цифра сама по собі мало що каже. Корисніше дивитися на співвідношення підписаних транзакцій до унікальних адрес за добу: це дозволяє оцінити, чи є високий TPS результатом активності реальних користувачів, чи автоматизованих скриптів. Окремо варто відстежувати частку транзакцій з помилками (failed transactions) — різкий її зріст часто сигналізує про мережеві проблеми ще до офіційних заяв.
Метрики екосистеми: TVL, кількість проєктів, активність розробників
TVL (total value locked) потребує контексту ринкового циклу — зростання TVL на тлі загального бичого ринку має меншу вагу, ніж стабільність TVL під час корекції. Кількість проєктів корисна лише з фільтром «активні за останні 30 днів». Активність розробників — найповільніша, але найнадійніша метрика: її неможливо швидко штучно роздути.
Метрики децентралізації: розподіл stake, кількість валідаторів
Кількість валідаторів без контексту розподілу stake — оманлива метрика. Тисяча нод, кожна з якою контролює 0,01% stake, не означає децентралізації, якщо 20 нод утримують 80% голосів. Тому ці метрики розглядаються разом і детальніше — у відповідному розділі нижче.
Оманливі метрики та як їх розпізнати
- Абсолютний TPS без розбивки за типами транзакцій. Транзакції Jito tips, heartbeat-повідомлення валідаторів та спам-транзакції можуть становити значну частку загального обсягу.
- Кількість створених гаманців. Багато адрес генеруються автоматично для airdrop-кампаній і ніколи не використовуються повторно.
- TVL без вилучення протоколів-бриджів. Заблоковані в бриджах активи не завжди працюють на екосистему Solana — вони можуть бути просто транзитним капіталом.
- Кількість NFT-колекцій. Більшість із них не мають вторинного ринку й фактично неактивні.
Джерела даних та інструменти
Основні джерела: експлорери мережі (Solscan, SolanaFM), агрегатори DeFi-метрик (DeFi Llama), інструменти моніторингу нод, дані з GitHub. Жодне джерело не є достатнім самостійно — коректний аналіз вимагає перехресної перевірки.
Межі аналізу
On-chain-дані не показують мотивацію користувачів. Високий обсяг транзакцій може бути як ознакою реального використання, так і результатом MEV-активності чи арбітражу. Аналітика дає гіпотези, які потребують підтвердження з інших джерел — інтерв'ю, звітів проєктів, поведінкової аналітики.
Як оцінювати децентралізацію Solana
Розмірність децентралізації: валідатори, розробники, токеноміка
Децентралізація — не бінарна властивість, а багатовимірна. Мережа може бути технічно децентралізованою (багато нод), але централізованою на рівні розробки (один клієнт пише 90% коду) або токеноміки (майбутнє розблокування зосереджене в кількох сутностях). Кожен вимір оцінюється окремо.
Метрики розподілу stake: Gini, Nakamoto coefficient
Коефіцієнт Джині (Gini) показує нерівність розподілу: 0 — ідеальна рівність, 1 — повна концентрація. Коєфіцієнт Накамото (Nakamoto coefficient) — мінімальна кількість сутностей, які можуть об'єднати більшість голосів (зазвичай 33% для зупинки мережі чи 67% для проведення несумісного оновлення). Обидві метрики мають сенс лише разом: низький Накамото при високому Джині означає, що концентрація зосереджена в невеликій групі.
Географічний розподіл нод
Кількість нод у різних юрисдикціях впливає на стійкість мережі до регуляторного тиску. Важливо не лише фізичне розташування, а й юридична приналежність операторів. Дані про географію нод беруться з моніторингових інструментів, але мають похибку: VPN і хмарні провайдери можуть спотворювати реальну картину. Детальніше про інфраструктуру нод — у матеріалі про валідатори Solana.
Клієнтська різноманітність
Одна критична помилка в коді єдиного клієнта може зупинити всю мережу. Тому клієнтська різноманітність — ключовий показник стійкості. Важливо відстежувати не лише наявність альтернативних клієнтів (Firedancer, Sig, Tinydancer), а й реальну частку stake, яку вони обслуговують на mainnet.
Обмеження метрик та типові маніпуляції
Типова маніпуляція — демонстрація великої кількості валідаторів без зазначення, що більшість із них делеговано через кілька великих стейкінг-пулів. Інша — ігнорування того, що деякі «незалежні» валідатори фактично належать одній організації через різні юридичні структури. Метрики показують те, що вимірюється, а не те, що є насправді.
Практичні кроки для самостійної оцінки
- Отримати список валідаторів із розподілом stake з експлорера або dashboards валідаторів.
- Обчислити коефіцієнт Накамото: відсортувати за stake і знайти мінімальну кількість, що дає 33%.
- Перевірити клієнтську різноманітність: яка частка stake обслуговується кожним клієнтом.
- Перевірити перекриття: чи належать топ-валідатори різним організаціям (перевіряється за публічними даними, заявами, структурою власності).
- Оцінити географічний розподіл із урахуванням хмарних провайдерів.
Як розбирати postmortem мережевого інциденту
Структура postmortem: хронологія, причини, наслідки
Якісний postmortem містить три шари: точну хронологію подій (з таймстемпами в UTC), технічну причину (з посиланням на конкретний шматок коду або конфігурацію) та наслідки (які сервіси постраждали, як довго тривала перерва, чи були втрачені кошти). Якщо хоча б один шар відсутній — це не postmortem, а комунікаційна заява.
Як відрізнити технічну причину від системної
Технічна причина — це конкретний баг, конфлікт версій, помилка в логіці консенсусу. Системна причина — це архітектурне рішення, яке робить такі баги ймовірними: відсутність формальної верифікації, недостатнє тестування на load-сценаріях, залежність від єдиного клієнта. Баг — це симптом. Системна причина — це діагноз. Інциденти з однаковим симптомом, але різними діагнозами вимагають різних реакцій.
Реакція мережі: час відновлення, комунікація
Час відновлення (time to recovery) — об'єктивна метрика. Але не менш важлива комунікація: чи були оперативні оновлення для користувачів і розробників, чи було зрозуміло, що відбувається, чи не створювалося хибних вражень (наприклад, «мережа працює», коли фактично блоки не фіналізувалися). Мовчання під час інциденту — теж сигнал.
Уроки та зміни після інциденту
Критерій якості реакції — чи призвів інцидент до конкретних змін у процесах, а не лише до виправлення конкретного багу. Якщо postmortem завершується словами «виправлено баг у рядку 42» без змін у тестуванні, моніторингу чи архітектурі — ймовірність повторення висока.
Типові помилки в аналізі postmortem
- Зведення всього до «людського фактора». Це закриває питання замість того, щоб змінити систему так, щоб людська помилка була менш ймовірною.
- Порівняння з іншими мережами без контексту. «Ethereum теж падав» — не є аргументом, якщо архітектури різні і причини несумісні.
- Фокус на особистостях замість процесів. Хто саме допустив помилку — менш важливо, ніж чому система дозволила цю помилку потрапити на mainnet.
Межі: не звинувачення, а навчання
Мета розбору postmortem — не знайти винного, а зрозуміти, чи стають інциденти рідкіснішими та менш серйозними з часом. Якщо тренд не змінюється — це системна проблема, яка не вирішується точковими виправленнями.
Річний підсумок екосистеми Solana: тренди й досягнення
Методологія річного огляду
Річний підсумок будується на порівнянні метрик на початок і кінець року з урахуванням ринкового контексту. Зростання метрик на бичому ринку оцінюється інакше, ніж на ведмежому. Кожен тренд супроводжується конкретними даними, а не враженнями.
Ключові тренди року
Тренд фіксується, коли зміна метрики підтверджується принаймні двома незалежними джерелами і зберігається щонайменше два квартали поспіль. Разові сплески (наприклад, навколо окремого airdrop) не є трендом.
Досягнення проти очікувань
Корисно порівнювати не з абстрактними очікуваннями, а з конкретними заявами з початку року: roadmap-и фонду, публічні обіцянки команд, прогнози аналітиків. Це дозволяє оцінити не лише результат, а й здатність екосистеми виконувати плани.
Невдалі прогнози та чому вони не справдилися
Аналіз невдалих прогнозів цінний не для звинувачення, а для розуміння меж екосистеми. Чи не справдився прогноз через зовнішні фактори (регуляція, макроекономіка), чи через внутрішні проблеми (технічні обмеження, відтік розробників)? Відповідь на це питання визначає, чи варто очікувати виконання подібних прогнозів у майбутньому.
Прогнози на наступний рік: де є дані, де — гіпотези
Прогнози чітко розділяються на дві категорії: ті, що базуються на вже наявних трендах (наприклад, продовження зростання активності розробників) і ті, що є гіпотезами (наприклад, масове прийняття платежів). Читач має чітко розуміти, де закінчується екстраполяція даних і починається спекуляція.
Межі підсумку
Річний огляд фіксує стан на момент написання. Він не є інвестиційною рекомендацією і не передбачає майбутньої поведінки ринку. Метрики минулого року не гарантують повторення в наступному.
Аналіз TVL і ліквідності в екосистемі Solana
Що TVL реально показує, а чого — ні
TVL показує суму активів, заблокованих у смарт-контрактах протоколу. Він не показує: прибутковість протоколу, кількість реальних користувачів, ризик втрати коштів, ліквідність на вторинному ринку. Протокол із високим TVL, але низьким обсягом транзакцій — це, швидше, сховище, ніж працюючий DeFi-продукт.
Методика порівняння TVL між протоколами
Коректне порівняння вимагає урахування типу протоколу: DEX і lending-протокол природно матимуть різний TVL навіть при однаковій корисності. Порівнювати має сенс протоколи одного типу, а також відстежувати співвідношення TVL до обсягу транзакцій (capital efficiency). Детальніший огляд протоколів — у каталозі DeFi-додатків.
Фактори, що спотворюють TVL
- Власний токен протоколу в TVL. Якщо значна частка TVL — це нативний токен протоколу, реальна залучена ліквідність нижча, ніж здається.
- Бриджовані активи без реального використання. Капітал, що пройшов через бридж і залишився без руху, штучно роздуває TVL екосистеми.
- Ретроактивні інцентиви. Протоколи, що роздають токени за депозити, можуть тимчасово роздувати TVL, який зникає після завершення кампанії.
- Двосторонні позиції. В одному протоколі одна сутність може забезпечити обидві сторони пулу, створюючи ілюзію ліквідності.
Тренди TVL у контексті ринку
TVL Solana, як і будь-якої екосистеми, корелює з загальним станом крипторинку. Тому ізольований аналіз TVL без порівняння з іншими L1 дає викривлену картину. Корисніше дивитися на частку Solana у загальному TVL ринку та динаміку цієї частки.
Межі аналізу
TVL — запізніла метрика. Вона фіксує результати минулих рішень, а не поточний стан. Різке падіння TVL може статися вже після того, як реальні проблеми протоколу існували тижнями. Тому TVL використовується разом із іншими метриками, а не як єдиний індикатор здоров'я.
Як відстежувати активність розробників у Solana-екосистемі
Метрики активності розробників: коміти, PR, GitHub Stars
Кількість комітів — найбазовіша, але й найменш інформативна метрика: один розробник може зробити 100 комітів з автоматичним форматуванням, а інший — один, але з критичною логікою. Pull requests (особливо merged) дають кращу картину реальної роботи. GitHub Stars відображають інтерес спільноти, але не якість коду. Базові поняття розробки на Solana розглянуті в розділі Solana для розробників.
Джерела даних: GitHub, Electric Capital, інструменти
GitHub — первинне джерело, але його дані потребують очищення. Звіти Electric Capital (Developer Report) — найбільш систематизоване джерело порівняльної аналітики розробників across екосистем, але мають власну методологію з обмеженнями. Додаткові інструменти (GitHut, OSS Insight) дають допоміжні дані.
Оманливі метрики: боти, форки, inactive repos
- Бот-коміти. Автоматизовані коміти (dependabot, CI/CD) можуть становити значну частку загальної кількості. Їх треба виключати.
- Форки. Форк репозиторію не означає активної розробки — більшість форків залишаються без змін.
- Inactive repos. Репозиторій із 500 зірок, але без комітів за останній рік — це історія, а не активний проєкт.
- Перенесення коду. Іноді проєкт мігрує з одного репозиторію на інший, створюючи ілюзію «нового» проєкту зі старим кодом.
Порівняння з іншими екосистемами
Порівняння має сенс лише за єдиної методології. Electric Capital використовує стандартизований підхід, але навіть він не враховує розробників, що працюють закрито (у компаніях, що не публікують код відкрито). Тому будь-яке порівняння — це порівняння відкритої розробки, а не всієї розробки.
Межі аналізу
GitHub-метрики не показують якість коду, безпеку протоколів чи задоволеність розробників. Екосистема може мати багато активних репозиторій, але страждати від високого плинності розробників або концентрації ключової експертизи в одній команді.
Тренди використання Solana: платежі, DeFi, геймінг, соціальні
Методологія вимірювання використання за категоріями
Кожна категорія вимірюється своїми метриками: для платежів — обсяг і кількість транзакцій між різними адресами; для DeFi — обсяг на DEX, позиції в lending, стейкінг; для геймінгу — транзакції всередині ігрових контрактів; для соціальних — публікації, взаємодії, підписки. Спільна метрика (наприклад, «кількість транзакцій») без розбивки за категоріями не дозволяє зрозуміти, що саме відбувається в екосистемі.
Платежі: реальний обсяг проти спекулятивного
Реальні платежі характеризуються різноманітністю сум (від мікроплатежів до великих переказів), різноманітністю відправників і отримувачів, відсутністю регулярних патернів, притаманних арбітражу. Спекулятивний обсяг часто концентрується між кількома адресами, має регулярні інтервали та однотипні суми. Розмежувати їх повністю за on-chain-даними неможливо, але співвідношення дає орієнтовну картину.
DeFi: зрілість протоколів та поведінка користувачів
Зрілість DeFi-протоколу оцінюється не лише TVL, а й стабільністю метрик протягом кількох ринкових циклів, відсутністю критичних вразливостей, наявністю аудиту від визнаних компаній. Поведінка користувачів: чи повертаються вони після першого використання, чи це разова взаємодія заради інцентивів. Огляд ключових протоколів — у каталозі DeFi-додатків.
Геймінг та соціальні: реальні DAU проти ботованої активності
DAU (daily active users) у геймінгу та соціальних додатках — найманіпульованіша метрика в крипті. Ознаки ботованої активності: однотипні транзакції з фіксованими інтервалами, великі групи адрес з однаковою поведінкою, різкий сплеск DAU без відповідного зростання органічного трафіку (соціальні згадки, органічні інсталяції). Реальні DAU зазвичай мають більш хаотичний патерн і корелюють із зовнішніми подіями (оновлення гри, вірусний контент). Каталог проєктів за категоріями — у каталозі екосистеми.
Крос-категорійні тренди та зв'язки
Категорії не ізольовані. Наприклад, зростання соціальних додатків може генерувати попит на мікроплатежі, а розвиток геймінгу — стимулювати DeFi (позики на ігрові активи). Важливо фіксувати не лише тренд усередині категорії, а й зв'язки між ними — це дозволяє раніше помічати системні зрушення в екосистемі.
Межі аналізу: неповнота даних
On-chain-дані не фіксують користувацький досвід, який відбувається поза ланцюжком (наприклад, інтерфейс додатка, швидкість завантаження). Деякі додатки можуть використовувати Solana як settlement-шар, тоді як основна взаємодія відбувається на іншій інфраструктурі. Тому аналіз використання завжди є нижньою межею: реальне використання може бути вищим, але не нижчим за зафіксоване.