Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.quanux.org/llms.txt

Use this file to discover all available pages before exploring further.

QuanuX does not request CPU time from the operating system—it occupies silicon directly. The execution model is built around physical core isolation: two threads run on two dedicated CPU cores, each pinned so hard that the Linux scheduler never touches them. One core generates alpha; the other enforces risk at the hardware level. The result is a verified 59-nanosecond tick-to-trade path with an 11.33-nanosecond hardware-enforced halt.
This page describes the bare-metal HFT execution model. If you are using QuanuX through the REST API or the Tauri cockpit without managing your own execution nodes, you do not need to configure core pinning or understand the Sentinel interlock directly. These guarantees are already built into the engine you deploy via quanuxctl nest drop.

​
The 59ns tick-to-trade flow

The hot path from market data ingress to order-out is deterministic and has no OS context switches on the critical thread.
1

Market data ingress

Raw market events arrive at the edge node. On a standard execution node, the Linux network stack delivers packets to the NATS DMA pipe. On a NIC/Solarflare node, the Solarflare EF_VI interface bypasses the kernel entirely, reducing NIC ingress from ~800ns toward the hardware minimum.
2

Spreader processing (Core 3)

Thread 1 spins on MARKET.BIN, the NATS subject for binary market data. Core 3 is a “Dead Core”—isolated from the Linux scheduler, never context-switched, never sleeping. It runs a bare-metal C++ loop that owns the L1 cache and processes each tick against your strategy logic. This is where the 59-nanosecond budget is spent.
3

Risk check (Core 5 — the Sentinel)

Before any order leaves the machine, the Sovereign Sentinel on Core 5 evaluates the current market state against your risk thresholds. If all conditions pass, the Spreader continues. If a threshold is breached, the Sentinel executes an asm lock orb instruction on the L3 cache bus—flipping the 0th bit of the 64-byte Sovereign block. The Spreader physically cannot traverse its pipeline past this point.
4

Order out (Thread 2)

Thread 2 handles strategy output and FIX order entry. Once the Sentinel’s L3 block is clear, the order is published over the NATS DMA pipe and dispatched to the exchange adapter.

​
The Sovereign Sentinel and L3 interlock

Traditional software risk checks are if/else statements—they can be skipped by memory corruption or logic errors in the Spreader. QuanuX implements risk as a hardware gate instead. The Sentinel monitors what the manifesto calls “Sins”:
  • Stale data — market data has not refreshed within the expected window
  • Notional breach — cumulative position size exceeds your configured limit
  • Order storms — order submission rate exceeds the defined threshold
When a Sin is detected, the Sentinel executes: 
asm volatile("lock orb $1, (%0)" : : "r"(sovereign_block_ptr) : "memory");
This flips the 0th bit of the L3 Sovereign block—a 64-byte cache-line shared between Core 3 and Core 5. The Spreader checks this bit before every pipeline traversal. Because the check is a CPU cache operation rather than a syscall, the time from Sin detection to halt is 11.33 nanoseconds.
The L3 interlock is a bus-level event. Even if the Spreader’s memory is corrupted or it enters an infinite loop, the Sentinel continues monitoring independently on its own core. The halt cannot be bypassed by strategy-level bugs.

​
Latency budget

For bare-metal deployments, the full internal budget is:
ComponentLatency
NIC ingress (kernel bypass / Solarflare)~800ns
QuanuX C++ core processing (Spreader)59ns
L3 risk interlock check (Sentinel)11ns
NIC egress~800ns
Total internal budget< 2 microseconds
The 59ns and 11ns figures exclude NIC wire travel. They represent processing time on the CPU, measured against the hardware TSC (Time Stamp Counter).

​
The Ritchie FSM: state machine for execution

The Sovereign Engine runs a deterministic Finite State Machine (FSM) called the Ritchie FSM. It governs how the engine responds to market failure modes—ensuring recovery is predictable regardless of what caused the interruption.
The engine has not yet initialized or has been fully shut down. No orders can be placed. This is the starting state before the habitat and nest are configured.
Normal operating state. The Spreader is spinning on MARKET.BIN, the Sentinel is monitoring, and orders can flow. This is the state you see when systemctl status quanux-engine reports active (running).
The process was interrupted mid-fill—for example, due to a crash or restart. Because QuanuX uses Persistent Shared Memory (HugePages) for its internal state machine, the state survives process termination. A warm restart attaches to the existing memory segment, recognizes STATE_PARTIAL, and resumes hedging in under 50 microseconds without a full exchange re-sync.
The Sentinel has detected a Sin and tripped the L3 interlock. The Spreader is frozen at the hardware level. No orders can leave the node until the halt condition is cleared and the interlock is explicitly lifted via invoke_hot_swap after a verified strategy redeployment.
A transitional state entered when the engine detects it was previously in STATE_PARTIAL or STATE_HALT and is reconciling position state before returning to STATE_ACTIVE.
If your node enters STATE_HALT unexpectedly, check the Panopticon ledger (OpenSearch) for the log entry recording which Sin was triggered and at what notional level. This gives you the exact market condition that tripped the interlock.