What each layer actually does
Three systems, read feature by feature from primary sources: the Origin PilotOS v4.2 manual and vendor pages, the Karsa Quantum OS prototype source, and the QryptOn scanner and library documentation. Not from marketing material.
Origin PilotOS — the quantum operating system
Launched 2021, open-sourced and made publicly downloadable in 2026. It sits between quantum hardware below and cloud, applications and supercomputing above, and it is the operations and scheduling hub of the Origin Wukong machines.
| Attribute | Value |
|---|---|
| Also known as | Origin Pilot / Origin Sīnán (本源司南) |
| Source reviewed | PilotOS 4.2 User Manual and API Reference, v3.4, 29 April 2026 |
| Vendor | Origin Quantum Computing Technology (Hefei) Co., Ltd. |
| Editions | Community and Enterprise |
| Backends addressed | Superconducting, trapped ion, semiconductor, neutral atom, photonic — plus classical HPC |
| Programming framework | QPanda / PyQPanda, QPanda3 Runtime; VQNet, ChemiQ, QCFD |
| Persistence | MySQL 8.0+ for metadata, MongoDB 6.0+ for circuits and raw results |
Six documented core capabilities
- Unified multi-backend access — multiple physical modalities plus classical resources
- Multi-user collaborative scheduling — concurrent queues, priority, resource isolation
- Unified hybrid task management — submission, queuing, execution, retry
- Hybrid compilation orchestration — multi-node parallel compilation, batch processing
- Resource management, monitoring, alerting — quotas, fidelity checks, anomaly detection
- System-level noise correction — sampling allocation, correction matrices
Intended audiences, per the manual
Research teams, quantum information scientists — including quantum cryptography, communication and networks — application developers, technology companies, and national laboratories. That second group is named explicitly, which is the doorway security labs walk through. The manual anticipates cryptography users; it just does not serve them a protocol engine.
Six layers, from user code to cryostat
Two ZeroMQ patterns, and why a browser cannot talk to it
Router–Dealer · request / reply
Connection-oriented, bidirectional, synchronous. Distributing tasks to backends, receiving results, querying real-time status, retrieving randomized benchmarking data, and heartbeat exchange for link health. Ordered, reliable delivery — appropriate for critical control commands.
Pub–Sub · publish / subscribe
Connectionless, unidirectional, asynchronous, event-driven. Proactive task status updates, dynamic chip parameter changes (T1/T2 coherence, gate fidelity), calibration completion, and real-time qubit availability. Eliminates polling overhead.
What it does not do
Both halves matter. The capabilities above are what you get for free. These are what must be supplied by another layer, or by an external security control.
| Capability | Owner | Why it is not native |
|---|---|---|
| QKD protocol engine | Build it | Photonic compute backends are documented. No BB84/E91/B92 or decoy-state application exists. QKD is not a chip-compute task |
| HNDL risk model | Build it | Entirely a classical business-risk calculation. Nothing in a quantum OS knows what a secrecy lifetime is |
| PQC runtime | Build it | ML-KEM, ML-DSA and SLH-DSA run on classical CPUs. The control plane can schedule them; it does not implement them |
| Cryptographic inventory / CBOM | Build it | Asset schema, scanners, attestation workflow and evidence lineage are business-layer concerns |
| Key protection | External | HSM, key vault and PKI stay outside the control plane. Private keys must never sit in the business database |
Scroll the table horizontally to see all columns.
Origin Quantum's machines, and China's 2026 landscape
PilotOS is not an abstraction exercise — it is the operating system shipped on real superconducting hardware, and the estate it addresses changed substantially in May 2026.
| System | Route | Specification | Status |
|---|---|---|---|
| Origin Wukong-180 | Superconducting | 180 computational qubits on a single core, plus 251 coupling qubits. T1 ≈ 40 µs, T2-echo ≈ 20 µs | 4th generation, online 9 May 2026, accepting global tasks |
| Origin Wukong | Superconducting | 72 computational qubits (198 total including 126 couplers) | 3rd generation, online Jan 2024. ~50 M remote accesses, 160+ countries, 900,000+ tasks |
| Hanyuan-2 | Neutral atom | 200 rubidium qubits, dual-core, cabinet-scale, under 7 kW | CAS Cold Atom Technology, May 2026. Room-temperature enclosure; atoms laser-cooled to µK |
| Jiuzhang 4.0 | Photonic | Up to 3,050 photons across 8,176 interferometric modes, 1,024 squeezed-state inputs | USTC, Nature, May 2026. First fully programmable photonic prototype at scale |
Scroll the table horizontally to see all columns.
Karsa Quantum OS — twelve modules
A dependency-free static HTML, CSS and JavaScript application — no framework, no build step, no CDN, no backend required. It runs standalone from local state, and switches to live control-plane data the moment the adapter is reachable.
Platform · mirrors the control plane
- 01 Command Center — KPIs, event feed, module map, live/degraded/local connection state
- 02 Task Management — submit, queue, cancel, clone; full
MsgTask/TaskStatuslifecycle - 03 Resource Management — 13-column chip inventory, pause/resume scheduling, M3 sampling, optimal qubit block
- 04 Status Monitoring — Router and Pub health, queue trend, alert feed
- 05 API Console — 20 endpoints across four systems, replayed offline or dispatched live
- 06 Access & License — roles, provisioning, licence verification
Use cases · the security value
- 07 PQC Migration Optimizer — budget, capacity and deadline constraints to a migration portfolio and wave plan
- 08 PQC Benchmark Lab — ML-KEM-768, ML-DSA-65, SLH-DSA-128s across server, mobile and edge profiles
- 09 Quantum Exposure Simulator — single-asset urgency signal from data-longevity assumptions
- 10 HNDL Batch & Vault Lab — portfolio sweep plus synthetic harvest snapshot
- 11 QKD Security Lab — BB84-family Monte Carlo with channel, detector and Eve models
- 12 Integration Architecture — interactive native / adapter / custom ownership map
The backend estate it serves
| Backend | System | Router / Pub | Qubits | Max shots | Native gates | Scheduling |
|---|---|---|---|---|---|---|
| Origin Wukong 72Q | superconducting | 7000 / 8000 | 60 / 72 | 20,000 | RPhi, CZ | Active |
| Superconducting_72_2 | superconducting | 7000 / 8000 | 60 / 72 | 20,000 | RPhi, CZ | Active |
| IonTrap | ion_trap | 7001 / 8001 | 6 / 6 | 10,000 | RPhi, MS | Active |
| HanYuan_01 | neutral_atom | 7002 / 8002 | 225 / 225 | 20,000 | RPhi, CZ | Paused |
| PQPUMESH8 | photonic | 7003 / 8003 | 3 / 3 | 100,000 | CZ, RPhi | Active |
| CPU Pool A | classical | — | — | — | N/A | Active |
Scroll the table horizontally to see all columns.
Verified by running it, not by reading it
Working simulation, not roadmap items
Both close gaps our own earlier analysis identified — a portfolio-scale HNDL engine and a working QKD protocol simulator. Both are live in the application today.
HNDL Batch & Vault Lab
- Inputs — migration lead time, threat horizon, and a conservative / moderate / optimistic scenario shift
- Scope — the full asset inventory scored in one pass, each asset carrying its own confidentiality lifetime against a shared horizon
- Outputs — assets scanned, counts already CRITICAL and HIGH, per-asset exposure window and P0–P3 wave, sorted most urgent first
- Synthetic vault — generates weighted session records: ID, asset, algorithm, capture date, classification, retention, projected decrypt-by year
- Dispatch — queues the batch as a control-plane job, visible in task management
- Boundary — no real network traffic is captured or analysed; everything is generated in-browser
QKD Security Lab
- Protocols — BB84, decoy-state BB84, E91, B92, with B92's lower conclusive-detection rate modelled explicitly
- Channel model — distance-based fibre loss at 0.2 dB/km, detector efficiency, dark-count rate, intrinsic noise floor, through a real per-pulse loop with a seeded generator
- Eve strategies — none, intercept–resend, photon-number splitting, detector blinding — the latter two as stealth attacks that never raise the error rate
- Countermeasures — decoy-state checking and optical power monitoring, toggleable, so you can see what each one actually catches
- Outputs — sifted key length, measured error rate, a derived ~11% security threshold, an illustrative secure-key estimate, ACCEPT/ABORT verdict and full run trace
- Boundary — models protocol behaviour under stated assumptions; it is not a physical QKD system, is not independently audited, and protects nothing
QryptOn — the layer that protects real traffic
Deliberately scoped to post-quantum cryptography rather than security in general. This is the only layer described on this site that touches real cryptographic material.
The threat model, without hype
What Shor and Grover actually do, harvest-now-decrypt-later with a working Mosca calculator, the three finalised standards side by side, and the regulatory picture — each claim sourced, or explicitly marked as needing a source.
Local toolchain scanner
A read-only POSIX shell script. Can the crypto libraries and CLI tools on this host negotiate post-quantum TLS and SSH today? Scored, capped, with confidence stated — and nothing leaves the machine by default.
Browser PQC toolkit
Generate a hybrid identity, password-protect it, encrypt to someone's public key, sign and verify
— all in WebAssembly on your own device, in the same file formats the qrypt CLI reads
and writes.
Seven invariants, seventeen checks, nine that score
Invariants, stated in the source
- Read-only — nothing written outside a scratch directory removed on exit
- No root required — anything needing root reports "unknown", never guessed
- No persistence — no dotfiles, cron, profile edits or systemd units
- No network by default —
--onlineallows exactly one TLS probe - Nothing transmitted without
--share— affirmative consent, fails closed - Bounded — 45 s total, 5 s per check, 256 KiB output cap, all enforced
- Deterministic — no AI in scanning or scoring; same host, same result
| Check | Category | Weight |
|---|---|---|
| TLS OpenSSL groups | TLS | 40 |
| SSH client ML-KEM | SSH | 15 |
| Live hybrid handshake | TLS · negotiated | 12 |
| SSH effective config | SSH | 10 |
| curl PQ negotiation | TLS · negotiated | 8 |
| SSH sntrup fallback | SSH | 5 |
| Go / Node / Python runtime | Runtime | 4 / 3 / 3 |
| Signature algorithms | PKI | 0 · reported |
What is implemented, not just mentioned
| Standard | Algorithm | In use | Public key | Signature / ciphertext | Status |
|---|---|---|---|---|---|
| FIPS 203 | ML-KEM | ML-KEM-768 | 1184 B | 1088 B ct | Live |
| FIPS 204 | ML-DSA | ML-DSA-65 | 1952 B | 3309 B sig | Live |
| FIPS 205 | SLH-DSA | All 12 parameter sets | — | — | Library only |
| FIPS 206 (not yet drafted) | FN-DSA | — | — | — | Tracked |
| Round 4 | HQC | — | — | — | Tracked |
Scroll the table horizontally to see all columns.
Why hybrid, not pure PQC
Every encryption operation combines X25519 with ML-KEM-768. The shared secret is compromised only if both components are broken, so the deployment loses nothing if an unknown weakness later appears on either side.
Stated plainly, everywhere relevant
The library implements the algorithms per FIPS 203/204/205 and passes NIST known-answer test vectors, but it is not FIPS 140-3 validated, has not undergone an external audit, and is pre-1.0.
A vendor-credibility test
As of mid-2026 NIST has published no draft of FIPS 206 and assigned no FIPS number to HQC. Anyone selling compliance with a standard that does not exist yet is telling you something useful about their other claims.