Перейти к содержимому
ORBITRAONE

Orbitra L1 · Слой рыночных сервисов

Слой, который делает Orbitra L1 рыночно-нативным.

ApexMatch работает в слое рыночных сервисов Orbitra L1, рядом с Aegis, Prism, клирингом и расчётами. Это часть протокола, а не контракт, развёрнутый поверх него, — именно это свойство делает Orbitra L1 рыночно-нативным блокчейном первого уровня.

Иллюстрация: Orbitra L1 в виде шести уровней: пользовательский опыт — сверху, затем рыночные сервисы, исполнение, консенсус, данные и сеть — в основании. Свет движется вниз через уровни по мере исполнения и финализации транзакции и обратно вверх как подтверждённое состояние.
  1. 01Пользовательский опытOrbitra Prime · кошельки · приложения · институциональные API
  2. 02Рыночные сервисыApexMatch · Aegis · Prism · клиринг · расчёты
  3. 03ИсполнениеVectorLanes · детерминированный планировщик · NexusWASM
  4. 04КонсенсусКворум QSE · сертификаты финальности · политика валидаторов
  5. 05ДанныеКоммитменты состояния · история · потоки индексов · доказательства
  6. 06СетьРегиональный приём · зашифрованная передача · сеть доступности

Слой · Рыночные сервисы

Роль в стеке Orbitra L1

Заявки поступают из слоя пользовательского опыта — Orbitra Prime, институциональных API, кошельков и приложений — уже подписанными. ApexMatch выстраивает их последовательность, обращается к Aegis и Prism в том же слое, сопоставляет их и формирует клиринговые дельты.

Эти дельты не передаются в отдельную систему расчётов. Они становятся переходами состояния, которые слой исполнения выполняет на VectorLanes и которые финализирует QSE, поэтому исполнение заявки и её расчёты — это одно событие, а не две записи, ожидающие сверки.

Поскольку сопоставление заявок — нативный модуль, контракты на NexusWASM обращаются к нему через типизированные вызовы. Каждое приложение в сети использует одни и те же книги заявок, а не фрагментирует ликвидность по отдельным копиям.

Иллюстрация: Подписанная заявка проходит слева направо через шесть этапов: вход, справедливое упорядочивание, риск-барьер Aegis, сопоставление по цене и времени, клиринг с расчётом чистых дельт и финализацию с доказательством QSE. След подписанных записей фиксирует каждый этап.
  1. 01ВходПодписанная заявка
  2. 02УпорядочиваниеСправедливое упорядочивание
  3. 03РискБарьер Aegis
  4. 04СопоставлениеЦена-время
  5. 05КлирингЧистые дельты
  6. 06ФинализацияДоказательство QSE
Детерминированный
Одинаковые входные данные — одинаковые исполнения, одинаковое состояние.
Атомарный
Сделка и обновление обеспечения происходят вместе.
Наблюдаемый
Каждый этап формирует подписанную запись.
Компонуемый
Приложения могут вызывать нативные рыночные примитивы.

Что ApexMatch даёт сети

  • 01

    Книги заявок как сервисы протокола

    Централизованные книги заявок, рабочие процессы RFQ и блочных сделок обслуживают Orbitra Prime и приложения сети через одни и те же примитивы.

  • 02

    Риск в том же слое

    Проверка риска Aegis до сделки выполняется рядом с сопоставлением заявок, поэтому заявка, которая превысила бы лимит, отклоняется до того, как достигнет книги заявок.

  • 03

    Справочные данные в пределах доступа

    Рыночное состояние Prism задаёт ценовые диапазоны и условия приостановки для каждого рынка, не выходя за пределы слоя.

  • 04

    Расчёты как переход состояния

    Клиринговые дельты напрямую поступают в исполнение и финализацию, без пакетной сверки между торговой площадкой и реестром.