Реальний досвід команд, що будували продукти на Solana — найконкретніше джерело розуміння екосистеми. Нижче зібрані розбори за типами: від успішних стартапів до невдалих ініціатив, від хакатонних прототипів до інфраструктурних інструментів. Кожен кейс фокусується на прийнятих рішеннях, їхніх наслідках і межах застосовності досвіду для інших команд.
Кейс успішного Solana-стартапу: аналіз зростання й GTM
Вихідний контекст: проблема, рішення, цільова аудиторія
Drift Protocol запустився як децентралізована біржа з перпетуальними ф'ючерсами на Solana у момент, коли основний обсяг деривативів у крипті був зосереджений на централізованих платформах (Binance, dYdX на Ethereum). Проблема, яку команда ідентифікувала: на Solana практично не було повноцінного DEX-продукту для торгівлі з кредитним плечем із прийнятним UX для трейдерів, звичних до інтерфейсу CEX. Цільова аудиторія — активні трейдери, які шукали децентралізовану альтернативу з низькою латентністю.
Стратегія go-to-market та канали залучення
Команда обрала нестандартний для DeFi підхід: замість класичної моделі «liquidity mining з першого дня» вони спочатку зосередилися на продукті та інтеграціях. Ключові канали: тісна співпраця з Solana Foundation та іншими протоколами-партнерами для забезпечення початкової ліквідності, публічна розробка з відкритим комунікацією через Twitter і Discord, а також інтеграція з агрегаторами та фронтендами екосистеми. Важливу роль відіграла стратегія «будуємо публічно» — команда регулярно публікувала технічні розбори та roadmap.
Вимірювані результати: метрики зростання
Конкретні поточні метрики варто перевірити за даними DeFiLlama та офіційним дашбордом протоколу, оскільки вони змінюються щоденно. Проте загальновідомо, що Drift пройшов шлях від нульової ліквідності до статусу одного з ключових DeFi-продуктів на Solana протягом кількох місяців після повноцінного запуску. Ознакою успіху є те, що протокол утримав позиції навіть після серйозних екосистемних шоків (зупинки мережі, колапс FTX).
Ключові рішення та поворотні моменти
- Вибір архітектури з власним оракульним рішенням замість повної залежності від зовнішніх джерел цін — це дозволило швидше реагувати на волатильність.
- Впровадження соціального трейдингу та копітрейдингу як диференціатора в момент, коли конкуренти зосереджувалися лише на базовій інфраструктурі.
- Рішення випустити власний токен DRIFT з чітко прописаною утилітарною моделлю, а не як інструмент суто для ліквідності-мінингу.
Помилки та уроки
Команда публічно визнавала проблеми з початковою складністю інтерфейсу для нових користувачів та надмірну залежність від стабільності самої мережі Solana у періоди її зупинок. Урок: навіть найкращий продукт на L1 страждає від інфраструктурних проблем базового шару, і це треба закладати в ризик-модель.
Межі кейсу: один приклад, не шаблон
Досвід Drift специфічний для ніші деривативів. Стратегія GTM, що спрацювала для DEX з кредитним плечем, не є універсальною для NFT-маркетплейсів, інфраструктурних інструментів чи гейміфікованих додатків. Більше прикладів стартапів на Solana дивіться у розділі Solana-стартапи.
Кейс проєкту, що змінив напрям (pivot): уроки з екосистеми
Початковий напрям: гіпотеза та результати
Magic Eden розпочала як виключно Solana-орієнтований NFT-маркетплейс у середині 2021 року. Гіпотеза була простою: Solana набирає популярність, транзакції дешеві, NFT-бум у розпалі — потрібна якісна платформа для торгівлі. Результати перших місяців підтвердили гіпотезу: платформа швидко захопила значну частку ринку Solana NFT.
Причини pivot: дані, зворотний зв'язок, ринок
Протягом 2022 року команда стикнулася з кількома сигналами. По-перше, ринок Solana NFT суттєво скоротився після колапсу FTX — залежність від однієї мережі стала очевидним ризиком. По-друге, користувачі та колекції масово просили мультічейн-підтримку: творці хотіли виходити на Ethereum і Polygon, а покупці — мати єдиний інтерфейс. По-третє, конкурент OpenSea почав експериментувати з підтримкою інших мереж, що створювало загрозу.
Новий напрям: що змінилося і чому
Magic Eden перетворилася з Solana-специфічного маркетплейсу на мультічейн-платформу, додавши підтримку Ethereum, Polygon та Bitcoin (Ordinals). Це був не просто технічний крок, а фундаментальна зміна позиціонування: з «маркетплейс для Solana NFT» на «маркетплейс для цифрових колекцій незалежно від мережі». Команда також запустила власний токен ME та програму лояльності.
Вимірювані результати після pivot
Актуальні дані про частку ринку варто перевіряти за даними Dune Analytics та публічних дашбордів. Загалом відомо, що Magic Eden зберегла лідерські позиції на Solana одночасно з виходом на інші мережі, хоча частка на Ethereum залишається значно меншою порівняно з OpenSea та Blur.
Уроки для фаундерів
- Pivot не означає «все було неправильно» — початковий фокус на Solana дав критичну масу користувачів і бренд.
- Залежність від однієї мережі — системний ризик, який важливо оцінювати навіть за умови глибокої спеціалізації.
- Таймінг pivot має значення: Magic Eden змінила напрям після того, як ринок сам підкреслив вразливість одномережевої моделі.
Межі кейсу
Magic Eden мала значний ресурсний буфер до моменту pivot, що недоступний більшості команд. Досвід мультічейн-розширення для NFT-маркетплейсу не автоматично переноситься на інші типи продуктів. Додаткові кейси стартапів — у розділі Solana-стартапи.
Кейс невдалого проєкту на Solana: що пішло не так
Вихідний контекст та амбіції
Під час буму 2021 року на Solana з'явилося багато проєктів у категорії «високодохідне фермерство» (yield farming) з агресивними APY-обіцянками. Типова модель: токен з нульовою початковою вартістю, екстремальні ставки винагород за стейкінг, ліквідність, залучена через короткострокові інцентиви. Ці проєкти позиціонували себе як «основні DeFi-протоколи» нової екосистеми.
Причини невдачі: ринкові, технічні, командні
- Ринкові: модель була побудована на припущенні, що ціна токена зростатиме нескінченно. Коли ринок повернувся вниз, висока інфляція токена призвела до смертельної спіралі: продаж винагород тиснув на ціну, падіння ціни знижувало привабливість стейкінгу, відтік ліквідності прискорював падіння.
- Технічні: деякі з цих протоколів поспішали з аудитом смарт-контрактів або взагалі його не проводили, що призводило до вразливостей та експлойтів.
- Командні: типова проблема — анонімні команди без прозорого трекшну, без досвіду управління протоколом у кризових умовах. У моменти стресу комунікація зникала.
Чи можна було уникнути: аналіз з hindsight
З погляду ретроспективи, невдача була структурно передбачуваною. Екстремальні APY у поєднанні з токеномікою, де більшість пропозиції спрямована на інцентиви, а не на утилітарність — це класична модель понці, навіть якщо команда не мала такого наміру. Уникнути можна було б за умови консервативнішої токеноміки та фокусу на реальному використанні протоколу, а не на привабленні ліквідності через інфляцію.
Уроки для екосистеми
Екосистема Solana отримала жорсткий, але необхідний урок: висока швидкість і низька вартість транзакцій не компенсують хибну економічну модель. Згодом екосистема змістилася в бік протоколів з більш продуманою токеномікою та реальним призначенням.
Межі кейсу: повага до команді, без прикрашання
Цей кейс описує типову модель невдачі, а не конкретний проєкт з метою уникнення необґрунтованих звинувачень. Багато команд діяли щиро, але в межах хибної парадигми, яку підтримував загальний ринковий настрій. Конкретні назви та деталі варто перевіряти за незалежними постмортем-аналізами.
Кейс хакатонного проєкту, що став продуктом
Хакатон: тема, команда, прототип
Tensor розпочав як хакатонний проєкт під час одного з хакатонів, організованих Solana Foundation. Команда зібралася навколо ідеї створити NFT-маркетплейс нового покоління на Solana — з акцентом на швидкість інтерфейсу, професійні інструменти для трейдерів та ефективний порядок matching-у. Прототип демонстрував суттєво кращу продуктивність порівняно з існуючими рішеннями.
Шлях від прототипу до продукту
Перехід від хакатонного демо до повноцінного продукту зайняв кілька місяців. Ключові кроки: повний перезапис клієнтської частини з фокусом на продуктивність, розробка власного движка для обробки ордерів на стороні сервера (off-chain order matching з on-chain settlement), інтеграція з Tippy для зручності оплати комісій.
Фінансування, менторство, інкубація
Після хакатону команда отримала фінансування від notable VC-фондів, що спеціалізуються на крипті. Важливу роль відіграло те, що хакатон дозволив не лише продемонструвати технічні навички, а й отримати зворотний зв'язок від менторів та потенційних користувачів, що сформувало напрямок подальшого розвитку.
Вимірювані результати
Tensor досить швидко захопив значну частку ринку Solana NFT, обігнавши Magic Eden за обсягом торгівлі в певні періоди. Актуальні метрики варто перевіряти за даними Tiexo та інших агрегаторів NFT-статистики.
Уроки для хакатонних учасників
- Хакатон — це не кінець, а старт. Переважна більшість хакатонних проєктів не стають продуктами саме тому, що команди розходяться після події.
- Вибір проблеми важливіший за технологічну вишуканість: Tensor виграв не через унікальну архітектуру, а тому, що обрав реальну біль користувачів (повільні NFT-маркетплейси).
- Прототип має демонструвати не концепцію, а користувацьку цінність.
Межі кейсу
Досвід Tensor специфічний для NFT-ніші та контексту 2022–2023 років, коли існуючий лідер (Magic Eden) зазнавав репутаційних ударів через зміну політики щодо роялті. У інших умовах вихід з хакатону міг би мати інший результат. Більше про хакатони — у розділі Solana-хакатони.
Кейс DeFi-протоколу на Solana: аналіз стратегії та результатів
Вихідний контекст: нішева проблема DeFi
Marinade Finance запустився як протокол ліквідного стейкінгу на Solana. Проблема, яку він вирішував: коли ви стейкаєте SOL нативно, ваші токени блокуються і ви не можете використовувати їх в інших DeFi-протоколах. Marinade створив mSOL — ліквідний токен, що репрезентує стейканий SOL і може вільно циркулювати в екосистемі.
Технічна архітектура та дизайн протоколу
Протокол використовує модель з делегуванням до множини валідаторів, розподіляючи стейк для зменшення ризику централізації. Важливий архітектурний вибір: автоматична ротация валідаторів на основі їхньої продуктивності та комісій. Смарт-контракти написані на Rust з використанням Anchor. Протокол також впровадив «розумну» логіку автоматичного складання винагород (auto-compounding).
Стратегія залучення ліквідності та користувачів
Ключова стратегія — інтеграція mSOL як базового активу в інші протоколи екосистеми. Коли DEX-и, лендінг-протоколи та інші DeFi-додатки почали підтримувати mSOL як колатерал або торгову пару, це створило мережевий ефект: більше використання mSOL — більше привабливість стейкати через Marinade. Додатково протокол пропонував власні інцентиви у вигляді токена MNDE.
Вимірювані результати: TVL, кількість користувачів
Marinade став одним з найбільших протоколів на Solana за TVL (total value locked). Конкретні поточні цифри варто перевіряти на DeFiLlama. Важливіший показник: частка SOL, що стейкається через Marinade від загального стейканого SOL — це індикатор реальної екосистемної значущості.
Інциденти, виклики та реакція
Протокол стикався з викликами під час зупинок мережі Solana та колапсу FTX (значна частина екосистеми постраждала). Реакція команди полягала в прозорій комунікації, тимчасовому призупиненні певних операцій та швидкій адаптації до нових умов. Також були технічні інциденти, пов'язані з оновленнями протоколу, що підкреслило важливість багаторівневого тестування.
Межі кейсу
Ліквідний стейкінг — специфічна ніша з власною динамікою. Стратегія «стати базовим активом для інших протоколів» працює для ліквідних токенів стейкінгу, але не переноситься на, наприклад, DEX-и чи лендінг-протоколи без адаптації. Більше DeFi-кейсів — у розділі DeFi-додатки на Solana.
Кейс NFT-проєкту на Solana: від запуску до стійкості
Концепція та спільнота до запуску
Solana Monkey Business (SMB) — один із найдавніших NFT-проєктів на Solana, запущений на початку 2021 року. На відміну від пізніших проєктів з агресивним маркетингом, SMB стартував у мінімалістичний спосіб: проста піксельна графіка, невелика спільнота, відсутність масштабного PR. Концепція будувалася навколо естетики, схожої на ранні CryptoPunks, але на Solana.
Модель запуску: mint, аукціон, allowlist
Запуск відбувся за значно простішою моделлю, ніж стало нормою пізніше: без складних allowlist-механіків, без аукціонів, без газ-варів. Це було в час, коли NFT на Solana ще не були масовим явищем, і конкуренція за mint була мінімальною. Ця «простота запуску» стала можливою завдяки контексту часу, а не як свідома стратегія.
Життєвий цикл після запуску: утримання цінності
Ключовий фактор стійкості SMB — екосистемне розширення. Команда не обмежилася випуском колекції, а створила SMB Genesis, інтегрувалася з іншими проєктами, побудувала суббренд (SMB Gen2). Важливу роль відіграла репутація «орігіналу» — коли ринок Solana NFT виріс, SMB отримав статус «блакитної фішки» за правом першості.
Реальні метрики проти початкового хайпу
Поточні ціни та обсяги торгівлі варто перевіряти на Tensor або Magic Eden. Важливіше спостереження: ціна підлоги SMB пройшла через екстремальні цикли зростання та падіння, але проєкт зберіг ліквідність і спільноту, на відміну від сотень колекцій, що зникли після первинного хайпу.
Уроки для NFT-творців
- Стійкість NFT-проєкту залежить не від хайпу запуску, а від того, що відбувається після: утилітарність, екосистемні зв'язки, репутація.
- Статус «першого» у ніші дає структурну перевагу, яку важко скопіювати.
- Простота на старті не є недоліком, якщо проєкт має чітке бачення розвитку.
Межі кейсу
SMB запустився в унікальний часовий вікно, коли конкуренція на Solana NFT була мінімальною. Спробувати відтворити цю модель у нинішніх умовах перенасиченого ринку було б помилкою. Кейс показує принципи стійкості, а не шаблон запуску.
Кейс інфраструктурного проєкту: як побудувати інструмент для екосистеми
Проблема інфраструктури, яку вирішували
Helius з'явився як відповідь на хронічну проблему Solana: ненадійність публічних RPC-вузлів (Remote Procedure Call — інтерфейс, через який додатки спілкуються з блокчейном). Публічні RPC часто перевантажувалися, давали затримки або повертали помилки, що прямо впливало на UX кінцевих продуктів. Розробникам потрібен був надійний RPC-провайдер з інструментами для моніторингу та оптимізації.
Технічні рішення та компроміси
Helius побудував власну інфраструктуру RPC з географічно розподіленими вузлами, оптимізованим кешуванням та розширеними API-методами, яких немає в стандартному RPC. Компроміс: команді довелося інвестувати значні ресурси в інфраструктуру до того, як сформувався стабільний потік доходів. Також було прийнято рішення пропонувати безкоштовний tier для невеликих розробників, що створювало навантаження на інфраструктуру, але формувало екосистемну залежність.
Модель монетизації та стійкість
Freemium-модель: безкоштовний рівень з лімітами, платні плани для команд, що потребують вищої пропускної здатності та додаткових інструментів. Додаткові джерела доходу — розширені API (DAS — Digital Asset Standard для ефективного запиту токен-акаунтів, enhanced transactions API). Стійкість моделі залежить від того, чи продовжуватимуть розробники на Solana потребувати надійну інфраструктуру — поки що тренд підтверджує це.
Прийняття екосистемою: метрики використання
Helius став одним із ключових RPC-провайдерів у екосистемі. Конкретні цифри кількості клієнтів та обсягу запитів варто перевіряти за публічними даними команди. Показник прийняття: велика кількість відомих Solana-додатків використовує Helius як основний або резервний RPC.
Уроки для infra-будівників
- Інфраструктурний продукт на блокчейні має вирішувати біль, яку розробники відчувають щодня, а не гіпотетичну проблему майбутнього.
- Безкоштовний tier — це не благодійність, а інвестиція в екосистемну залежність та бренд.
- Документація та developer experience (DX) для infra-продукту є таким же продуктом, як і сама інфраструктура.
Межі кейсу
RPC-інфраструктура — специфічний тип бізнесу з високими постійними витратами та низькою маржинальністю на одиницю. Досвід Helius не переноситься без адаптації на інші типи інфраструктури (індексери, оракули, фронтенд-інструменти).
Кейс міграції проєкту з Ethereum на Solana: причини, процес, результати
Причини міграції: вартість, швидкість, UX
Сабер (Saber) — стаблсвап AMM, який спочатку розглядав Ethereum як цільову мережу, але зрештою запустився на Solana. Основні причини: вартість транзакцій на Ethereum робила часті операції зі стейблкоїнами (які є ключовим use-case для стаблсвапу) економічно недоцільними для користувачів із невеликими обсягами. Швидкість фіналізації на Solana (порядки секунд проти хвилин на Ethereum) також була критичною для UX торгового інтерфейсу.
Технічні виклики перепису смарт-контрактів
Міграція з Solidity на Rust вимагала не просто перекладу коду, а переосмислення архітектури. Модель обліку на Solana фундаментально відрізняється від Ethereum: замість одного контракту з mapping-ами — система акаунтів (PDA — Program Derived Address), кожен пул є окремим акаунтом, а не записом у стані контракту. Команді довелося перепроєктувати схему даних, логіку доступу та обробку помилок.
Міграція користувачів та ліквідності
Це виявилося найскладнішим етапом. Користувачі Ethereum не автоматично переходять на Solana — потрібні нові гаманці, нові токени, нові звички. Ліквідність також не мігрує автоматично: її треба залучати наново через інцентиви та партнерства. Команда вирішила це через агресивний liquidity mining на ранньому етапі та інтеграції з екосистемними мостами.
Вимірювані результати після міграції
Сабер став одним з найбільших DeFi-протоколів на Solana за TVL у період свого піку. Однак варто перевіряти актуальний статус протоколу, оскільки ландшафт DeFi на Solana суттєво змінився після 2022 року. Важливий нюанс: успіх міграції вимірюється не лише піковими метриками, а й здатністю протоколу функціонувати в умовах зміненого ринку.
Уроки для команд, що розглядають міграцію
- Технічна міграція — це менша частина проблеми. Міграція користувачів та ліквідності часто виявляється складнішою та дорожчою.
- Вибір мережі має базуватися на конкретному use-case, а не на загальних перевагах L1. Стейблсвап дійсно потребує дешевих транзакцій; інші продукти — не обов'язково.
- Міграція створює залежність від нової екосистеми з її власними ризиками (зупинки мережі, концентрація валідаторів тощо).
Межі кейсу: не рекомендація мігрувати
Цей кейс описує історичний досвід одного проєкту в конкретних умовах. Він не є аргументом на користь міграції з Ethereum на Solana загалом, ні навпаки. Рішення про міграцію залежить від типу продукту, цільової аудиторії, ресурсів команди та поточного стану обох мереж — усі ці фактори змінюються з часом.
Кейс спільноти навколо Solana-продукту: як будувати та утримувати
Стратегія формування спільноти
Superteam — не типовий продукт, а радше мережева структура локальних спільнот навколо Solana, що дає найкращий огляд побудови екосистемної спільноти. Стратегія базувалася на принципі «bottom-up»: замість централізованого створення спільноти з одного центру, команда заохочувала формування локальних осередків (Superteam DAO) у різних країнах і містах. Кожен осередок мав автономію в діяльності, але спільні цінності та інструменти.
Інструменти: Discord, Twitter, локальні події
Discord слугував основним операційним простором: канали для розробників, для творців, для організації подій. Twitter — для публічної комунікації та залучення нових учасників. Але ключовий інструмент — офлайн-події: хакатони, мітапи, воркшопи. Саме вони створювали реальні зв'язки між учасниками, які потім переносилися в онлайн-активність.
Метрики залучення та утримання
Конкретні цифри кількості учасників та подій варто перевіряти за публічними звітами команди. Більш показові якісні метрики: кількість проєктів, що виникли з учасників Superteam; кількість хакатонних команд, сформованих через спільноту; рівень повернення учасників на наступні події.
Кризи спільноти та реакція команди
Колапс FTX у листопаді 2022 року став найсерйознішою кризою для всієї екосистеми Solana, і Superteam не став винятком. Частина учасників пішла, активність різко впала. Реакція команди: відкрита комунікація про стан справ, фокус на тих учасниках, що залишилися, та перехід від «хайпу» до «будівництва» — акцент на реальних проєктах та навичках замість спекуляційних настроїв.
Уроки для community-менеджерів
- Спільнота, побудована на хайпі, розпадається разом із хайпом. Спільнота, побудована на реальних зв'язках та спільній діяльності, має значно вищу стійкість.
- Офлайн-компонент є критичним для довгострокового утримання, навіть у цифровій екосистемі.
- Автономія локальних осередків створює резистентність: якщо один осередок слабшає, інші продовжують функціонувати.
- Важливо розрізняти «кількість учасників у Discord» та «активну спільноту» — це різні метрики з різною цінністю.
Межі кейсу
Superteam — це специфічний тип спільноти (екосистемна, мережева), що фінансується частково через гранти Solana Foundation. Досвід не повністю переноситься на спільноту навколо комерційного продукту, яка має інші мотиви участі та інші KPI. Крім того, модель локальних осередків працює краще в регіонах з високою концентрацією крипто-ентузіастів.