Orbitra Prime
Торговый интеллект
Каждый тикет заявки в Orbitra Prime — от рыночной заявки в один клик до блока RFQ — сводится к примитивам ApexMatch с одинаковыми доказательствами исполнения для каждого пользователя.
ApexMatchOrbitra L1
Детерминированный нативный механизм сопоставления заявок
Ядро биржи живёт внутри протокола.
ApexMatch — это не приложение, развёрнутое в сети. Это нативный рыночный модуль Orbitra L1: сопоставление, отмена, фандинг, изменения маржи и доказательства расчётов происходят в рамках одного атомарного перехода состояния. Одни и те же входные данные, одни и те же исполнения, одно и то же состояние.
Как это работает
Подписанная заявка, прослеженная от начала до конца
- 01ВходПодписанная заявка
- 02УпорядочиваниеСправедливое упорядочивание
- 03РискБарьер Aegis
- 04СопоставлениеЦена-время
- 05КлирингЧистые дельты
- 06ФинализацияДоказательство QSE
- Детерминированный
- Одинаковые входные данные — одинаковые исполнения, одинаковое состояние.
- Атомарный
- Сделка и обновление обеспечения происходят вместе.
- Наблюдаемый
- Каждый этап формирует подписанную запись.
- Компонуемый
- Приложения могут вызывать нативные рыночные примитивы.
Иллюстрация показывает одну подписанную заявку на всём пути — от входа через справедливое упорядочивание, риск-барьер Aegis, сопоставление по цене и времени и клиринг, до момента, когда сертификат QSE делает её финальной. Каждый этап формирует подписанные доказательства, показанные как след под основным путём.
Проблема
Почему механизму сопоставления пришлось переместиться в протокол
Большинство площадок выполняют сопоставление в одной системе, а расчёты — в другой. Заявки принимаются приложением, сопоставляются в закрытом движке, а затем сверяются с хранением и реестрами позже. Каждый переход между этими системами — место, где состояние может расходиться, где на порядок можно повлиять и где исполнение заявки может существовать до того, как переместилось обеспечение, которое его подкрепляет.
Ончейн-площадки, которые развёртывают контракт сопоставления в сети общего назначения, наследуют другую проблему: эта сеть никогда не создавалась для книг заявок. За место в блоке борется несвязанная активность, порядок формируется аукционами комиссий, а каждая сделка конкурирует с сетью за время исполнения.
ApexMatch устраняет оба разрыва. Ядро — это детерминированный модуль протокола, поэтому исполнение заявки, его эффект на маржу и его расчёт — одно неделимое событие: наблюдаемое, воспроизводимое и финальное под QSE.
Последовательность работы
Шесть этапов. Один атомарный переход.
Каждая заявка — ручная, алгоритмическая или выставленная агентом Cortex — проходит один и тот же путь через ядро.
- 01
Вход
Заявка поступает через региональный шлюз как подписанное намерение с прикреплёнными лимитами. Подписи проверяются пакетами до упорядочивания.
- 02
Упорядочивание
Справедливое упорядочивание присваивает каноническую позицию. Порядок определяется заявленными правилами, а не аукционом комиссий, поэтому очередь нельзя купить.
- 03
Риск
Предварительная проверка риска Aegis моделирует портфель после сделки: маржу, расстояние до ликвидации и лимиты политики. Заявки, которые превысили бы лимит, отклоняются до того, как коснутся книги заявок.
- 04
Сопоставление
Приоритет по цене и времени в ApexBook. Предотвращение самоторговли, семантика «пост-онли» и «только на уменьшение» обеспечиваются самим ядром.
- 05
Клиринг
Исполнения заявок формируют чистые изменения — по позициям, обеспечению, комиссиям и фандингу, — вычисляемые в рамках того же перехода, что и сопоставление.
- 06
Финализация
VectorLanes исполняет переход, и сертификат финальности QSE делает его финальным. Исполнение заявки, его эффект на маржу и доказательство расчёта становятся финальными вместе.
Архитектура
Компоненты ядра
ApexMatch состоит из небольших детерминированных частей с явными интерфейсами. Каждую можно наблюдать, тестировать и воспроизводить независимо.
- 01
Региональный вход
Шлюзы, расположенные близко к участникам рынка, принимают подписанные заявки, проверяют подписи пакетами и передают их далее с отметками времени получения.
- 02
Сиквенсер
Применяет заявленную политику упорядочивания и формирует канонический входной поток, который каждый валидатор воспроизводит идентично.
- 03
Барьер Aegis
Синхронный вызов Aegis, который оценивает заявку относительно графа рисков портфеля счёта и набора правил.
- 04
ApexBook
Центральные лимитные книги заявок с приоритетом по цене и времени, предотвращением самоторговли и нативной поддержкой RFQ и блочных рабочих процессов.
- 05
Механизм клиринга
Вычисляет изменения по позициям, обеспечению, комиссиям и фандингу для каждого исполнения заявки и записывает их в рамках того же перехода состояния.
- 06
Поток доказательств
Каждый этап формирует подписанные записи — подтверждение, позицию в очереди, вердикт риска, исполнение заявки, дельту — благодаря чему любое исполнение заявки можно восстановить независимо.
Безопасность и контроль сбоев
Безопасность и контроль сбоев
Механизм сопоставления должен отказывать безопасно. ApexMatch устроен так, что сбой на одном этапе не может привести к исполнению заявки, которое остальная система не распознаёт.
- АтомарностьСделка и обновление её обеспечения фиксируются вместе или не фиксируются вовсе. Не существует момента, когда исполнение заявки существует без эффекта на маржу.
- Детерминированное воспроизведениеВалидаторы воспроизводят один и тот же упорядоченный входной поток и должны получить одинаковый корень состояния. Расхождение обнаруживается, а не поглощается.
- Отказ до сделкиЗаявки, которые превысили бы лимиты по марже, плечу или политике, отклоняются на барьере Aegis, а не ликвидируются постфактум.
- Рыночные автоматические выключателиЦеновые коридоры по каждому рынку, паузы при волатильности и пороги достоверности Prism останавливают сопоставление, когда справочные данные становятся недостоверными.
- Целостность потока заявокПравила справедливого упорядочивания — часть спецификации протокола, поэтому порядок нельзя купить или изменить оператором.
В трёх системах
Как ApexMatch связывает три системы
Orbitra L1
Расчёты и вычисления
ApexMatch — нативный модуль рыночных услуг Orbitra L1. Он исполняется на VectorLanes, а его переходы финализируются QSE.
Orbitra Realm
Приложения и коммерция
Приложения в Orbitra Realm вызывают нативные рыночные примитивы напрямую из контрактов NexusWASM, поэтому кошелёк, игра или казначейский инструмент могут предложить настоящие книги заявок без создания собственной площадки.
Ценность
Что это меняет
- Трейдеры и пользователи
- Прозрачные, воспроизводимые исполнения заявок. Вы видите, где ваша заявка находилась в очереди, почему она была принята и когда стала финальной.
- Институты
- Детерминированное поведение, которое можно моделировать, воспроизводить и проверять аудитом. Копии отчётов о сделках, TCA и сверка считываются из того же потока доказательств, что и само ядро.
- Разработчики
- Компонуемые рыночные примитивы — книги заявок, RFQ, клиринговые дельты — доступны контрактам без необходимости заново реализовывать биржу.
Спецификации
Спецификации
- Модель сопоставления
- Центральная лимитная книга заявок, приоритет по цене и времени
- Детерминированность
- Идентичный упорядоченный входной поток даёт идентичные исполнения заявок и корни состояния на каждом валидаторе
- Контроль до сделки
- Синхронная оценка Aegis для каждой заявки
- Расчёты
- Атомарны с сопоставлением; финальность закрепляется сертификатом QSE
- Семантика заявок
- Рыночная, лимитная, стоп, стоп-лимит, пост-онли, только на уменьшение — нативно; расширенные и алгоритмические типы строятся на основе этих примитивов
- Защита
- Предотвращение самоторговли, ценовые коридоры, паузы при волатильности, остановки по достоверности оракула
- Доказательства
- Подписанное подтверждение, позиция в очереди, вердикт риска, исполнение и дельта для каждой заявки
- Интерфейсы
- Нативный API, шлюз FIX, рыночные примитивы NexusSDK
Терминология
Терминология
- Справедливое упорядочивание
- Правило, определённое протоколом, которое присваивает каждой заявке каноническую позицию независимо от уплаченных комиссий.
- Приоритет по цене и времени
- Заявки с более выгодной ценой сопоставляются первыми; при равных ценах первыми сопоставляются более ранние заявки.
- Клиринговая дельта
- Чистое изменение позиций, обеспечения, комиссий и фандинга, вызванное исполнением заявки.
- Сертификат финальности
- Совокупность подписей валидаторов, которая делает переход состояния финальным под QSE.
- Предотвращение самоторговли
- Правило, которое не позволяет счёту сопоставляться с собственными выставленными заявками.