Зі стрімким розвитком екосистеми DeFi на Solana ончейн-протоколи для деривативів перетворюються на ключову інфраструктуру. На відміну від ранніх, простіших моделей торгівлі AMM, нове покоління протоколів зосереджується на високочастотній торгівлі, низькому прослизанні, контролі ризиків і професійному маркет-мейкінгу.
У цьому контексті Phoenix і Drift репрезентують два різні шляхи розвитку: модель ончейн-книги ордерів і гібридну модель ліквідності.
Phoenix vs. Drift: ключові відмінності на перший погляд
Як протокол торгівлі безстроковими ф'ючерсами на Solana, Phoenix використовує архітектуру повністю ончейн-книги ордерів. Ордери на купівлю та продаж користувачів надсилаються до централізованої лімітної книги ордерів (CLOB) на блокчейні, де зіставляються за пріоритетом ціни та часу.
Архітектура Phoenix покликана відтворити досвід торгівлі на традиційних централізованих біржах у середовищі ончейн. На відміну від моделей AMM, Phoenix акцентує на:
- глибині ордерів
- низькому прослизанні
- високочастотному зіставленні
- професійній підтримці маркет-мейкінгу
Як ще один протокол безстрокових ф'ючерсів в екосистемі Solana, ринкова структура Drift суттєво відрізняється від Phoenix. Спочатку Drift спирався на механізм vAMM (віртуальний автоматизований маркет-мейкер) і використовував віртуальну модель ліквідності для забезпечення торгівлі безстроковими ф'ючерсами.
Згодом Drift інтегрував книгу ордерів і зовнішні джерела ліквідності, перетворившись на гібридну структуру ліквідності.
Порівняно з моделлю книги ордерів Phoenix, Drift надає перевагу ефективності капіталу, відкритій ліквідності, гнучким ринковим структурам і гібридним механізмам зіставлення. Такий підхід дозволяє Drift підтримувати торгову функціональність навіть на ринках з низькою ліквідністю, але водночас означає, що логіка формування ціни відрізняється від Phoenix.
Чим відрізняється базова архітектура Phoenix і Drift?
Принципова відмінність між Phoenix і Drift полягає в їхній базовій ринковій структурі.
Phoenix використовує суто ончейн-книгу ордерів, де всі ціни визначаються реальними ордерами Maker. Користувачі торгують безпосередньо через лімітні та ринкові ордери; ринкові ціни відображають динаміку попиту та пропозиції між покупцями та продавцями.
Drift, навпаки, застосовує гібридний підхід. Спочатку він спирався на vAMM для ліквідності, а потім поступово інтегрував книгу ордерів і зовнішню підтримку маркет-мейкінгу. Відтак ринкові ціни Drift частково визначаються алгоритмічними моделями, а частково — зовнішньою ліквідністю.
Зі структурної точки зору:
| Вимір |
Phoenix |
Drift |
| Базова структура |
Ончейн-книга ордерів |
vAMM + гібридна ліквідність |
| Формування ціни |
Ордери Maker |
Алгоритм + ринкова ліквідність |
| Джерело ліквідності |
Ордери маркет-мейкерів |
Віртуальна ліквідність + маркет-мейкінг |
| Ринковий досвід |
Близький до традиційної біржі |
Більш орієнтований на DeFi |
| Підтримка високочастотної торгівлі |
Сильна |
Помірна |
Phoenix більш тісно відповідає структурі книги ордерів традиційних фінансових ринків, тоді як Drift акцентує на гнучкості ончейн-ліквідності.
Як відрізняються механізми ліквідності Phoenix і Drift?
Ліквідність Phoenix походить насамперед від професійних маркет-мейкерів та ордерів Maker.
У моделі книги ордерів глибина ринку залежить від кількості реальних ордерів. Тому Phoenix більше покладається на високоякісний маркет-мейкінг і безперервну ліквідність ордерів. Його сильні сторони — ефективніше визначення ціни та, як правило, кращий контроль прослизання.
Drift завдяки механізмам vAMM і гібридної ліквідності здатен підтримувати ринкову торгівлю навіть в умовах низької ліквідності. Така структура зменшує залежність від професійних маркет-мейкерів, але може наражати протокол на ризики відхилення ціни на волатильних ринках.
Підсумовуючи:
- Phoenix більше залежить від реальної глибини ордерів
- Drift більше залежить від механізмів ліквідності протоколу
Ця відмінність є головною причиною різного торгового досвіду, який пропонує кожна платформа.
Як порівнюються торгові досвіди Phoenix і Drift?
Логіка торгівлі Phoenix дуже нагадує традиційні централізовані біржі.
Користувачі можуть використовувати професійні типи ордерів, зокрема лімітні та ринкові, а також спостерігати глибину книги ордерів у реальному часі. Ця модель зазвичай краще підходить для високочастотної торгівлі, кількісних стратегій, професійного маркет-мейкінгу та великих обсягів угод.
Торговий досвід Drift більше відповідає звичкам традиційних користувачів DeFi. Його гнучка модель ліквідності полегшує участь роздрібних користувачів.
Однак для великих угод і складних стратегій структура книги ордерів Phoenix зазвичай забезпечує вищу точність ордерів і менше прослизання.
Як відрізняються механізми управління ризиками Phoenix і Drift?
І Phoenix, і Drift керують ризиками через механізми маржі, ставки фінансування та ліквідації, але їхні підходи відрізняються.
Система ризику Phoenix побудована навколо книги ордерів і ринкових цін у реальному часі. Оскільки ринкові ціни походять від реальних ордерів Maker, контроль ризиків сильніше залежить від глибини ордерів і ринкової ліквідності.
Drift має керувати як параметрами vAMM, так і ринковим ризиком. Оскільки деякі ціни визначаються алгоритмічними моделями, протокол повинен динамічно регулювати параметри ліквідності для підтримки стабільності.
Кожна модель має відмінні характеристики:
- Phoenix надає пріоритет фактичним ринковим цінам
- Drift надає пріоритет безперервності ліквідності
Під час екстремальних ринкових подій модель книги ордерів зазвичай пропонує більш пряме визначення ціни, тоді як vAMM може мати ризик відхилення ціни.
Яким користувачам найкраще підходять Phoenix і Drift?
Phoenix ідеально підходить для професійних трейдерів і користувачів, які застосовують високочастотні стратегії.
Оскільки його структура книги ордерів відображає традиційні торгові ринки, користувачі, знайомі з централізованими біржами, знайдуть операції Phoenix інтуїтивно зрозумілими.
Drift, навпаки, краще підходить для традиційних користувачів DeFi та торгівлі малого й середнього масштабу. Його гібридна модель ліквідності знижує бар'єр входу для участі в ринку та допомагає протоколу підтримувати торгову активність навіть в умовах низької ліквідності.
З точки зору користувача:
- Phoenix схиляється до професійної торгової інфраструктури
- Drift схиляється до відкритого протоколу деривативів DeFi
Чому Solana ідеально підходить для ончейн-протоколів безстрокових ф'ючерсів?
І Phoenix, і Drift побудовані на високопродуктивній мережі Solana.
Ринок безстрокових ф'ючерсів потребує:
- високочастотних оновлень даних
- перевірок ризику в реальному часі
- швидкого підтвердження ордерів
- низької затримки угод
Висока пропускна здатність і низькі комісії Solana підтримують складні ончейн-торгові структури.
Порівняно з більш ранніми блокчейн-мережами, Solana краще пристосована для роботи книг ордерів, високочастотного зіставлення та складних фінансових логік. Як наслідок, дедалі більше ончейн-протоколів для деривативів обирають Solana як свою базову інфраструктуру.
Висновок
Phoenix і Drift є ключовими протоколами безстрокових ф'ючерсів в екосистемі Solana, однак вони дотримуються різних філософій ринкового дизайну.
Phoenix надає пріоритет архітектурі повністю ончейн-книги ордерів, забезпечуючи низьке прослизання, високочастотну торгівлю та професійний ринковий досвід. Drift застосовує модель vAMM та гібридної ліквідності, акцентуючи на відкритій ліквідності та ефективності капіталу.
Жодна модель не є апріорі кращою; кожна служить різним ринковим потребам і групам користувачів.
Поширені запитання
Яка найбільша відмінність між Phoenix і Drift?
Phoenix переважно використовує модель ончейн-книги ордерів, тоді як Drift схиляється до структури vAMM та гібридної ліквідності.
Чи використовує Phoenix AMM?
Ні. Phoenix використовує модель централізованої лімітної книги ордерів (CLOB), а не традиційний AMM.
Чому Drift використовує vAMM?
vAMM підтримує ринкову торгівлю за низької ліквідності та підвищує ефективність капіталу.
Який протокол краще підходить для високочастотної торгівлі?
Структура книги ордерів Phoenix зазвичай більш придатна для високочастотної торгівлі та кількісних стратегій.
