Цей матеріал розбирає реальний шлях DeFi-протоколу на Solana — від формулювання нішової проблеми до вимірюваних результатів і інцидентів. Об'єктом аналізу є Marinade Finance, один із перших і найбільш задокументованих протоколів ліквідного стейкінгу в екосистемі. Усі конкретні цифри TVL, APY та кількості користувачів змінюються щодня — перед прийняттям будь-яких рішень перевірте актуальні дані на дашбордах протоколу та незалежних агрегаторах (DefiLlama, Dune).

Вихідний контекст: нішева проблема DeFi

На момент запуску Marinade (2021 рік) Solana вже мала високу пропускну здатність і низьку вартість транзакцій, але стейкінг SOL був класичним і неповоротким: користувач делегував токени валідатору, отримував винагороду, але не міг використовувати цей стейк у DeFi-протоколах без попереднього розстейкінгу з типовою затримкою в епохи. Це створювало розрив між заблокованим капіталом і потребою ліквідності в наростаючій екосистемі.

Нішова проблема, яку вирішував протокол, — конвертувати неліквідний стейк у торгівельний актив, зберігаючи економічні стимули стейкінгу для мережі. Це не було унікальною ідеєю (Lido на Ethereum вже працював), але контекст Solana вимагав іншого інженерного підходу через архітектуру валідації, механіку епох та швидкість фіналізації.

Технічна архітектура та дизайн протоколу

Marinade побудовано на Anchor — фреймворку для написання смарт-контрактів на Rust у межах Solana. Ключові архітектурні рішення:

  • Ліквідний токен mSOL. Користувач stakes SOL у протокол і отримує mSOL у співвідношенні, що відображає накопичену винагороду. mSOL — це SPL-токен зі стандартним інтерфейсом, сумісний із будь-яким DEX або лендінговим протоколом на Solana.
  • Делегація через PDA (Program Derived Address). Протокол використовує PDA для управління стейк-акаунтами. Це дозволяє смарт-контракту володіти стейк-акаунтами без потреби в зовнішньому приватному ключі, що критично для безпеки.
  • Автоматичний розподіл між валідаторами. Алгоритм делегує SOL до пулу валідаторів із вагами, що залежать від показників ефективності (uptime, комісія, розмір стейку). Цей розподіл спочатку відбувався частково офчейн, що пізніше стало предметом дискусій про централізацію.
  • Механізм зняття. Існували два шляхи: миттєвий обмін mSOL на SOL через ліквідність пулу на DEX (з прослизанням) та відкладене зняття через чергу розстейкінгу з фіксованою затримкою в епохи.

Важливий нюанс: архітектура не була повністю ончейн з першого дня. Частина логіки розподілу виконувалася оператором (Marinade Labs), що створювало вектор довіри, нетиповий для «повністю децентралізованих» протоколів. Це рішення було компромісом між швидкістю запуску та рівнем децентралізації.

Стратегія залучення ліквідності та користувачів

Стратегія Marinade будувалася на кількох взаємодоповнюючих напрямках:

  • Інтеграція mSOL у пари на DEX. Пули mSOL/SOL на Raydium та інших агрегаторах забезпечували миттєву ліквідність для виходу, що знижувало бар'єр входу для нових користувачів. Чим глибшим був пул, тим меншим було прослизання при конвертації.
  • Лендінгові протоколи як канали розповсюдження. Коли mSOL став прийматися як колатерал у Mango Markets, MarginFi та інших протоколах, користувачі отримали додатковий стимул: стейкати SOL, отримувати винагороду від стейкінгу й одночасно використовувати mSOL як заставу для позик.
  • Інцентиви від Solana Foundation. На ранніх етапах протокол отримував гранти та інцентиви через програми екосистеми, що дозволило пропонувати додаткову винагороду (boosted APY) першим користувачам.
  • Маркетинг через утилітарність, а не хайп. Акцент робився не на «високому APY», а на тому, що mSOL дозволяє робити кілька речей одночасно: заробляти на стейкінгу, брати участь у DeFi, зберігати гнучкість капіталу.

Типова помилка, якої Marinade переважно уникали, — залежність від тимчасових інцентивів без побудови стійкої утилітарності токена. mSOL мав очевидну користь незалежно від додаткових нагород.

Вимірювані результати: TVL, кількість користувачів

Оскільки конкретні цифри змінюються щодня, наведемо якісні результати, які можна перевірити на DefiLlama та дашбордах протоколу:

  • Marinade тривалий час залишався одним із найбільших протоколів ліквідного стейкінгу на Solana за показником TVL, конкуруючи з Lido (stSOL), Jito (JitoSOL) та іншими.
  • Кількість унікальних адрес, що взаємодіяли з протоколом, сягала десятків тисяч, проток варто розрізняти активних користувачів від разових транзакцій — цей розрив є значним.
  • Частка mSOL у загальному обсязі ліквідного стейкінгу Solana змінювалася залежно від появи конкурентів, зокрема Jito з його MEV-інцентивами.

Важливий вимір, який часто ігнорують — співвідношення між стейком у протоколі та обсягом mSOL, що фактично циркулює в DeFi. Якщо більшість mSOL просто лежить на гаманцях, утилітарність ліквідного стейкінгу реалізується частково. Цей показник варто перевіряти окремо.

Інциденти, виклики та реакція

Жоден кейс не повний без аналізу невдач і кризових моментів:

  • Залежність від оператора та питання децентралізації. Спільнота неодноразово піднімала питання про те, що Marinade Labs контролює ключові параметри: список валідаторів, ваги делегації, оновлення протоколу. Реакція — поступова передача управління DAO та голосування через токен управління MNDE, хоча повна децентралізація так і не була досягнута на момент аналізу.
  • Конкуренція з Jito. Поява JitoSOL, який додатково розподіляє MEV-винагороду стейкерам, створила реальний тиск на Marinade. APY від стейкінгу через Jito виявився вищим за рахунок MEV, і Marinade відреагував інтеграцією Jito у свою архітектуру (можливість делегації частини стейку через Jito), а не спробою конкурувати безпосередньо.
  • Інциденти з ліквідністю під час падіння ринку. Під час різких знижень ціни SOL глибина пулів mSOL/SOL на DEX скорочувалася, що збільшувало прослизання при миттєвому знятті. Черга відкладеного зняття подовжувалася. Це системна вразливість усіх протоколів ліквідного стейкінгу, а не лише Marinade, але протокол не завжди достатньо прозоро комунікував про ці ризики.
  • Зміна моделі зняття. Протокол переглядав механіку зняття кілька разів, що свідчить про те, що початковий дизайн не повністю враховував стресові сценарії. Кожна зміна створювала додаткові питання від користувачів щодо надійності.

Межі кейсу

Цей аналіз має чіткі обмеження:

  • Кейс фокусується на одному протоколі й не є порівнянням із Lido, Jito, BlazeStake чи іншими рішеннями ліквідного стейкінгу на Solana. Таке порівняння вимагає окремого матеріалу.
  • Архітектурні деталі описані на рівні, достатньому для розуміння стратегічних рішень, але не замінюють аудит коду чи технічну документацію протоколу.
  • Економічна модель токена управління MNDE не розглядається детально — це окрема тема, пов'язана з механіками голосування та інцентивізації.
  • Кейс не розглядає регуляторні ризики ліквідного стейкінгу, які після подій навколо Lido на Ethereum стали більш релевантними.
  • Усі висновки про ефективність стратегії є ретроспективними й не гарантують аналогічних результатів для інших протоколів у інших ринкових умовах.

Для ширшого огляду інструментів децентралізованих фінансів у цій екосистемі перейдіть до каталогу DeFi-додатків на Solana.

Джерела