> For the complete documentation index, see [llms.txt](https://candora.gitbook.io/whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://candora.gitbook.io/whitepaper/candora-grid/orbit.md).

# Orbit

Matching, Execution and Order Lifecycle Engine

### Matching, Execution, and Order Lifecycle Engine

Candora Orbit is the deterministic execution engine of Candora Grid. It is responsible for order matching, execution sequencing, order lifecycle management, and trade finalization across the exchange infrastructure.

Orbit serves as the execution layer of the Grid. Every order, trade, liquidation execution, and order-state transition passes through Orbit before execution outcomes are propagated to Pulse for market-state synchronization, Risk Engine for exposure management, Vault for settlement processing, and Cortex for analytical telemetry.

Unlike conventional matching engines that focus primarily on throughput, Orbit is designed to balance execution efficiency, market integrity, and operational stability. Its objective is not only to match orders efficiently but also to preserve orderly market behavior during periods of elevated volatility, liquidity fragmentation, and systemic stress.

At its core, Orbit operates as a deterministic execution environment built around strict sequencing guarantees. Given the same validated event stream and execution state, Orbit will always produce identical order-book evolution, execution outcomes, and settlement notifications. This deterministic model enables reproducible recovery, simulation, auditability, and distributed replay throughout the broader Candora Grid infrastructure.

### Order Lifecycle and Execution State

Each order progresses through a predefined lifecycle managed by Orbit:

```
S_order ∈ {NEW, VALIDATED, QUEUED, MATCHED, PARTIAL, FILLED, CANCELLED}
```

Orders are first validated for structural correctness, instrument availability, session authorization, and submission integrity. Applicable pre-trade controls supplied by Risk Engine are evaluated before queue admission. Once accepted, orders enter the appropriate execution queue according to Orbit's sequencing rules and remain eligible for matching until completion, cancellation, or expiration.

Each state transition generates immutable execution events that propagate throughout Candora Grid. Pulse consumes execution transitions for market-state synchronization, Risk Engine updates exposure and solvency calculations, Vault records settlement obligations, and Cortex incorporates execution telemetry into analytical models.

Because all transitions are derived from deterministic processing logic, identical inputs always produce identical execution outcomes. Orbit therefore functions not only as a matching engine but also as the authoritative producer of execution state for the broader exchange environment.

To support recovery and distributed consistency, Orbit maintains synchronized execution checkpoints aligned with Pulse and Vault, ensuring execution-state restoration remains consistent with market-state and financial-state reconstruction processes.

### Matching Architecture and Execution Domains

Orbit utilizes a price-time priority matching model implemented within isolated symbol-level execution domains. Each market operates inside an independent shard that maintains its own order book, execution queue, replay stream, and recovery boundary.

Under normal operating conditions, orders are matched according to FIFO price-time priority. Buy-side liquidity is prioritized by highest bid price, while sell-side liquidity is prioritized by lowest ask price. Orders resting at the same price level are processed according to arrival sequence.

Matching occurs whenever executable liquidity exists:

```
BestBid ≥ BestAsk
```

This architecture provides efficient access to liquidity while preserving deterministic queue behavior and transparent execution ordering.

The use of isolated execution domains prevents congestion, replay activity, or liquidity shocks in one market from affecting unrelated trading pairs. Because there is no shared order-book state, cross-symbol dependency, or centralized execution bottleneck, Orbit can scale horizontally while maintaining fault isolation and deterministic behavior.

Each execution domain maintains independent matching logic, state transitions, replay streams, and recovery procedures. This allows individual markets to recover, replay, and scale independently while remaining synchronized with the broader Grid infrastructure.

### Execution Stability and Market Protection

Orbit continuously monitors execution conditions surrounding each order book, including liquidity depth, spread behavior, queue imbalance, aggressive order concentration, execution pressure, and liquidation activity.

These metrics do not alter matching priority or participant treatment. Instead, they provide situational awareness that supports market-protection mechanisms during abnormal trading environments and help maintain orderly execution during periods of market stress.

Execution telemetry is continuously exported to Pulse, Risk Engine, and Cortex, ensuring that broader infrastructure systems maintain synchronized awareness of execution conditions as they evolve.

### Adaptive Stabilization Mode

Under normal conditions, Orbit operates using continuous FIFO price-time matching. During periods of exceptional market stress, predefined activation conditions may trigger Adaptive Stabilization Mode, a temporary execution workflow designed to reduce destabilizing market behavior while preserving deterministic outcomes.

Rather than matching continuously, incoming orders are grouped into short execution intervals, typically ranging between:

```
10ms ≤ Interval ≤ 100ms
```

Within each interval, Orbit computes a uniform clearing price that maximizes executable volume across aggregate demand and aggregate supply.

Aggregate demand is defined as:

```
D(p) = Σ_{i:p_i ≥ p} q_i
```

Aggregate supply is defined as:

```
S(p) = Σ_{i:p_i ≤ p} q_i
```

The clearing price is:

```
p* = argmax_p min(D(p), S(p))
```

All compatible orders execute at the resulting clearing price. If aggregate demand and supply do not intersect within an interval, Orbit resolves pricing using the most recent valid market state to preserve continuity and deterministic replay behavior.

Adaptive Stabilization Mode remains part of the same execution engine and does not create a separate venue, auction market, or matching framework. All participants receive identical matching treatment while stabilization remains active. Once triggering conditions subside, Orbit automatically returns to continuous FIFO matching.

### Market Impact and Execution Pacing

Orbit incorporates execution-impact awareness to support orderly market behavior during changing liquidity conditions.

Execution impact is evaluated as a function of order size, available liquidity, and prevailing volatility:

```
Impact = f(OrderSize, LiquidityDepth, Volatility)
```

Under normal conditions, execution throughput remains optimized for efficient price discovery and liquidity interaction. During stressed conditions, Orbit may increase execution granularity and pacing controls to reduce sudden liquidity depletion and excessive market impact.

Orbit may additionally evaluate liquidity elasticity, execution footprint persistence, liquidation concentration, and adverse-selection risk to support execution-quality controls and broader market-protection mechanisms.

The objective of these mechanisms is not to alter execution fairness or matching priority, but to preserve orderly execution conditions while maintaining deterministic sequencing guarantees.

### Fault Tolerance and Recovery

Orbit supports deterministic recovery through checkpoint restoration and event replay.

Recovery follows a structured process:

1. Restore the latest execution checkpoint.
2. Verify sequence continuity.
3. Replay subsequent execution events.
4. Reconstruct order-book state.
5. Resume processing.

Execution state reconstruction follows:

```
S_recovered = S_snapshot + ∑ ΔEvents
```

Because execution behavior is deterministic, recovered state remains identical to the original execution state.

This allows exact reconstruction of order books, queue positions, execution sequences, and trade outcomes without requiring approximation or downstream service interruption.

Recovery procedures remain synchronized with Pulse market-state recovery, Oracle valuation-state reconstruction, Risk Engine solvency-state recovery, and Vault financial-state restoration, ensuring consistent recovery across the entire Candora Grid infrastructure.

### System Role Summary

Candora Orbit serves as the deterministic matching engine, execution coordination layer, order lifecycle manager, trade finalization system, execution-state authority, market-protection execution framework, adaptive stabilization engine, and execution recovery anchor of Candora Grid.

All order matching, execution sequencing, order-state transitions, and trade finalization within Candora Grid ultimately originate from Orbit, making it the foundational execution layer of the exchange infrastructure.