Orbitra Prime
Trading intelligence
Every order ticket in Orbitra Prime — from a one-click market order to an RFQ block — resolves to ApexMatch primitives, with the same execution evidence for every user.
ApexMatchOrbitra L1
Deterministic native matching engine
The exchange kernel lives inside the protocol.
ApexMatch is not an application deployed on a chain. It is a native market module of Orbitra L1: matching, cancellation, funding, margin deltas and settlement proofs share one atomic state transition. Same inputs, same fills, same state.
How it moves
A signed order, followed end to end
- 01IngressSigned order
- 02SequenceFair ordering
- 03RiskAegis gate
- 04MatchPrice-time
- 05ClearNet deltas
- 06FinalizeQSE proof
- Deterministic
- Same inputs, same fills, same state.
- Atomic
- Trade and collateral update together.
- Observable
- Every stage emits signed evidence.
- Composable
- Apps can invoke native market primitives.
The illustration follows one signed order through ingress, fair sequencing, the Aegis risk gate, price-time matching and clearing, until a QSE certificate marks it final. Each stage emits signed evidence, shown as the trace beneath the path.
The problem
Why the matching engine had to move into the protocol
Most venues run matching in one system and settlement in another. Orders are accepted by an application, matched in a private engine, then reconciled with custody and ledgers later. Every hop between those systems is a place where state can diverge, where ordering can be influenced and where a fill can exist before the collateral that backs it has moved.
Onchain venues that deploy a matching contract on a general-purpose chain inherit a different problem: the chain was never built for order books. Block space is contested by unrelated activity, ordering is shaped by fee auctions and every trade competes with the network for execution time.
ApexMatch removes both gaps. The engine is a deterministic protocol module, so a fill, its margin effect and its settlement are one indivisible event — observable, reproducible and final under QSE.
Operating sequence
Six stages. One atomic transition.
Every order — manual, algorithmic or issued by a Cortex agent — follows the same path through the kernel.
- 01
Ingress
The order arrives through a regional gateway as a signed intent with its limits attached. Signatures are verified in batches before sequencing.
- 02
Sequence
Fair sequencing assigns a canonical position. Ordering follows declared rules, not fee bidding, so the queue cannot be bought.
- 03
Risk
Aegis pre-risk simulates the post-trade portfolio: margin, liquidation distance and policy limits. Orders that would breach a limit are rejected before they touch the book.
- 04
Match
Price-time priority on ApexBook. Self-trade prevention, post-only and reduce-only semantics are enforced by the kernel itself.
- 05
Clear
Fills produce net deltas — positions, collateral, fees and funding — computed inside the same transition as the match.
- 06
Finalize
VectorLanes executes the transition and a QSE quorum certificate finalizes it. The fill, its margin effect and its settlement proof become final together.
Architecture
Components of the kernel
ApexMatch is composed of small deterministic parts with explicit interfaces. Each can be observed, tested and replayed independently.
- 01
Regional ingress
Gateways close to market participants accept signed orders, verify signatures in batches and forward them with receive timestamps.
- 02
Sequencer
Applies the declared ordering policy and produces the canonical input stream that every validator replays identically.
- 03
Aegis gate
A synchronous call into Aegis that evaluates the order against the account’s portfolio risk graph and policy set.
- 04
ApexBook
Central limit order books with price-time priority, self-trade prevention and native support for RFQ and block workflows.
- 05
Clearing engine
Computes position, collateral, fee and funding deltas for every fill and writes them in the same state transition.
- 06
Evidence stream
Each stage emits signed records — receipt, sequence position, risk verdict, fill, delta — so any fill can be independently reconstructed.
Security and failure control
Security and failure control
A matching engine must fail safely. ApexMatch is built so that the failure of one stage cannot produce a fill that the rest of the system does not recognize.
- AtomicityA trade and its collateral update commit together or not at all. There is no window in which a fill exists without its margin effect.
- Deterministic replayValidators replay the same sequenced input and must produce the same state root. Divergence is detected, not absorbed.
- Pre-trade rejectionOrders that would breach margin, leverage or policy limits are rejected at the Aegis gate rather than liquidated afterwards.
- Market circuit breakersPer-market price bands, volatility pauses and Prism confidence thresholds halt matching when reference data becomes unreliable.
- Order-flow integrityFair sequencing rules are part of the protocol specification, so ordering cannot be purchased or reordered by an operator.
Across the three systems
How ApexMatch connects the three systems
Orbitra L1
Settlement and compute
ApexMatch is a native market-services module of Orbitra L1. It executes on VectorLanes and its transitions are finalized by QSE.
Orbitra Realm
Applications and commerce
Applications in Orbitra Realm call native market primitives directly from NexusWASM contracts, so a wallet, a game or a treasury tool can offer real order books without building a venue.
Value
What it changes
- Traders and users
- Transparent, reproducible fills. You can see where your order sat in the queue, why it was accepted and when it became final.
- Institutions
- Deterministic behavior that can be modeled, replayed and audited. Drop copy, TCA and reconciliation read from the same evidence stream as the engine.
- Developers
- Composable market primitives — books, RFQ, clearing deltas — available to contracts without re-implementing an exchange.
Specifications
Specifications
- Matching model
- Central limit order book, price-time priority
- Determinism
- Identical sequenced input produces identical fills and state roots on every validator
- Pre-trade control
- Synchronous Aegis evaluation on every order
- Settlement
- Atomic with the match; final under a QSE quorum certificate
- Order semantics
- Market, limit, stop, stop-limit, post-only, reduce-only natively; advanced and algorithmic types compose these primitives
- Protection
- Self-trade prevention, price bands, volatility pauses, oracle-confidence halts
- Evidence
- Signed receipt, sequence position, risk verdict, fill and delta for every order
- Interfaces
- Native API, FIX gateway, NexusSDK market primitives
Terminology
Terminology
- Fair sequencing
- A protocol-defined rule that assigns each order a canonical position independent of fees paid.
- Price-time priority
- Orders at a better price match first; at equal prices, earlier orders match first.
- Clearing delta
- The net change to positions, collateral, fees and funding caused by a fill.
- Quorum certificate
- The aggregated validator signatures that make a state transition final under QSE.
- Self-trade prevention
- A rule that stops an account from matching against its own resting orders.