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 is organized around a “Russian Doll” concept: each layer of the system wraps the next, rather than sitting beside it as disconnected blocks. The outermost layer conditions your server to the network; the next layer assigns it a role; inside that sits the execution engine; and at the very core lives your strategy. Every surface is insulated from the one outside it, so the innermost logic—your alpha—is protected from infrastructure noise all the way to the hardware level.

​
The three planes

QuanuX separates concerns into three distinct planes. Each plane operates independently, communicates over a defined boundary, and cannot contaminate the others.

Control Plane

The HA Matrix manages high availability, leader election, and failover. It guarantees that a dead primary node is fully severed before a standby assumes control—preventing split-brain scenarios at the network and power layer.

Execution Plane

The Sovereign Engine is the C++20 core. All trade execution, order book logic, and quantitative computation run here, compiled natively on the edge node with -O3 -march=native. Docker and cross-compilation are structurally prohibited.

Observability Plane

The Panopticon captures, stores, and serves telemetry without touching the execution path. It is physically separated into dedicated droplets so that observing your system never adds latency to your trades.

​
The Russian Doll layers

Starting from the outermost layer and moving inward:
LayerTool / ComponentWhat it does for you
Networkingquanuxctl habitat equipConditions a bare server into the QuanuX VPC, installs C++ toolchains, and writes the habitat.env binding
Node rolequanuxctl nest dropCompiles and deploys the correct engine type for that node (execution, observation, statistics, etc.)
Execution engineSovereign Engine (C++20)Runs the Spreader and Sentinel on isolated cores; owns the L1/L3 cache path
StrategyYour logicThe “baby” at the center—protected by every layer around it

​
The NATS JetStream mesh

All inter-node communication travels over NATS JetStream, which QuanuX calls the CNATS Global Mesh. No node communicates over the public internet; messages are published and consumed exclusively on the internal 10.10.x.x VPC. This boundary gives you:
  • Lossless buffering — JetStream has been benchmarked at 234,013 messages per second (228 MiB/second) during ingestion spikes
  • Cryptographically-backed leader elections — the Control Plane uses JetStream KV to elect a primary node without relying on external consensus systems
  • Strict isolation — the Execution Plane publishes over CNATS; the Observability Plane consumes from it; neither crosses into the other’s processing path
FlatBuffers are the wire format on the execution plane. JSON is structurally forbidden in the hot path. Fixed-point int64 math is used for all pricing to eliminate floating-point drift.

​
Control Plane: the HA Matrix

The Control Plane runs a dynamic failover daemon that watches node health and manages state transitions. When a primary node fails, the Control Plane enforces STONITH (“Shoot The Other Node In The Head”): the standby actively severs the dead primary’s network and power dependencies before assuming control. This guarantees that two nodes can never simultaneously believe they are the active primary.

​
Execution Plane: the Sovereign Engine

The Sovereign Engine is a bare-metal C++ binary compiled directly on the edge node. It runs two threads on isolated cores:
  • Thread 1 (Core 3 — the Spreader): Consumes market data from the NATS DMA pipe and runs your strategy logic
  • Thread 2 (Core 5 — the Sentinel): Monitors risk thresholds and can halt execution at the hardware level in 11.33 nanoseconds
The engine is deployed as a systemd service (quanux-engine.service) and reads its VPC binding from /etc/quanux/habitat.env.

​
Observability Plane: Panopticon

The Panopticon is a five-node subsystem that ingests, stores, and serves telemetry data. Each component has a single responsibility:
Runs Vector and GreptimeDB. Scrapes the NATS firehose and flushes structured time-series data into partitioned Parquet files.
An OpenSearch cluster dedicated to asynchronous text-log indexing. Isolated from the high-frequency metrics path so that log writes never compete with trade telemetry.
A MinIO S3 cluster holding immutable Parquet chunks with a 7-day hard-delete ILM policy and cross-region replication readiness.
Runs DuckDB via an httpfs mount against the Vault. Uses Hive Partitioning to deliver sub-millisecond Parquet queries without scanning full datasets.
A Hasura GraphQL API that introspects both the DuckDB Oracle and OpenSearch Ledger into a single queryable supergraph. This is the surface your dashboards and AI agents query.
The Panopticon observes execution state through the L3 Tap—a 64-byte aligned circular buffer the Spreader writes into asynchronously. The Rust/Tauri Clerk reads this buffer without invoking syscalls, so observation adds zero nanoseconds to the trade path.