Базовий огляд Saga можна почитати тут: Saga (SAGA): Modular Blockspace for App-Dedicated Chains and Infinite Scalability. Нижче — те, що інвестору часто потрібно далі: рамка для оцінки юніт-економіки, go-to-market і реальних обмежень моделі виділених ланцюгів для застосунків.
1) Бізнес chainlet — це B2B продаж інфраструктури
Обіцянка Saga — швидкий запуск і спеціалізація: команда отримує власне середовище замість боротьби за універсальний blockspace. Економічно це перетворюється на B2B угоду, де покупець — команда застосунку, а рішення залежить від повної вартості володіння, часу виходу на ринок і операційного ризику.
- Тригер рішення: коли зростаючий продукт відчуває податок від перевантажень, непередбачуваних комісій або браку кастомізації.
- Ризик заміни: багато команд спершу протестують L2 або інші appchain-стеки.
- Модель продажу: деврел, інтеграційна підтримка і референси важать не менше за технологію.
2) Юніт-економіка: за що платять і хто фінансує витрати
Модульна архітектура може масштабуватись технічно і провалитись комерційно, якщо не зрозуміло, що саме є оплачуваною одиницею. Інвестору варто зіставити одиницю доходу й одиницю витрат та перевірити їх на реальних сценаріях використання.
- Одиниця доходу: підписка на chainlet, послуги безпеки і валідаторів, доступ до спільної ліквідності, преміум інструменти.
- Одиниця витрат: стимули валідаторам, операційні витрати, гранти, підтримка інтеграцій.
- Ключове питання: чи здатні регулярні платежі покривати безпеку і сервіс без постійних стимулів.
3) Вузьке місце — не пропускна здатність, а координація
Виділені ланцюги знімають локальні затори, але додають витрати координації: оновлення, маршрутизація ліквідності, містки, UX між середовищами виконання. Найкраща лінза перевірки — чи робить Saga координацію дешевою для девкоманд і кінцевих користувачів.
- UX: чи приховує продукт складність, чи перекладає її на гаманці й містки.
- Ліквідність: як швидко агрегується ліквідність, коли застосунки ізольовані за дизайном.
- Операції: наскільки передбачувані оновлення і реакція на інциденти у великій кількості chainlets.
4) Крива прийняття: дивіться на повторюваність, а не на анонси
В інфраструктурі важлива не подія запуску, а крива використання. Разовий запуск зробити легко, стабільну активність — складно. Варто відстежувати сигнали, які дорого підробити.
- Повторюваність: ті самі застосунки й користувачі повертаються щотижня.
- Платна поведінка: платежі за сервіси зростають у міру зниження стимулів.
- Глибина інтеграцій: реальні фічі, а не просто деплой.
- Операційна зрілість: прозора робота з інцидентами і стабільність.
5) Токен-узгодження: чи може попит на токен випередити емісії
Слабке місце багатьох інфратокенів — коли використання не створює структурного попиту. Перевірка — чи стає SAGA дефіцитним ресурсом у системі, а не лише інструментом винагород.
- Попит на безпеку: стейкінг, прив’язаний до реального ризику і вартості, що захищається.
- Комісійні потоки: сервіси, за які справді платять у токен-термінах.
- Тиск пропозиції: розблокування й емісії проти органічного попиту.
Чеклист інвестора перед розміром позиції
- Хто платить: які сегменти застосунків реально потребують виділеного виконання.
- Доказ продажів: повторні запуски від сильних команд, не лише пілоти.
- Рішення координації: ліквідність і UX між chainlets у масштабі.
- Сценарій даунсайду: якщо ринок стандартизується на інших стеках, де захиститься Saga.
Модель appchain може працювати, але лише якщо координація дешевша за затори, які вона замінює. Це межа між інфраструктурним бізнесом і нескінченним циклом стимулів.
