The wire protocol every DEC-LLC product speaks. NIST FIPS-203 / FIPS-204 native. Threshold delivery across heterogeneous media. DPU-offloaded reassembly. Federal-procurement-eligible by construction.
DEC QDX is DEC-LLC's proprietary post-quantum, multi-channel quorum transport. Every DEC-LLC product communicates over QDX. It splits each application payload across n independent channels — a satellite link, a fiber pair, an RF mesh, a free-space optical relay, a LoRa segment, terrestrial IP, even a unidirectional data diode — with the property that any threshold k of those n channels suffices to reconstruct the original payload. Each channel runs its own negotiated cipher suite, all of them built on NIST-FIPS-203 (ML-KEM) and FIPS-204 (ML-DSA) post-quantum primitives. Reassembly is offloaded to data-processing-unit (DPU) silicon, with BlueField-2 supported today and a BlueField-3 path documented.
Most secure transports protect a single link with a single cipher. QDX protects a session by spreading it across many links and many ciphers, designed so that the session survives the failure of either.
Three forces converged.
The first is the NIST post-quantum migration timeline. NIST's standardized PQC primitives (FIPS-203 ML-KEM, FIPS-204 ML-DSA) are now the federal-procurement default, with phased mandates rolling through 2025–2030. Most existing transports — TLS, IPsec, QUIC, Noise — are being PQC-retrofitted by hybrid extension. QDX took a different bet: design PQC-native from inception, so the migration is not a future engineering cycle but a foundational property.
The second is multi-medium operational reality. Federal, satellite, defense, energy-utility, and federated-trust customers do not operate on a single network. A satellite operator might have line-of-sight RF, satellite uplink, and ground-fiber concurrently — each with different latency, different reliability, and different threat models. A modern enterprise has on-premises fiber, multi-WAN to several carriers, cellular failover, and increasingly Starlink-class satellite fallback. Single-link transports treat this diversity as a redundancy problem to be solved at a higher layer (BGP, SD-WAN, route convergence). QDX treats it as a delivery property to be solved at the transport layer itself.
The third is cryptographic single-point-of-failure risk. A future cryptanalytic break against any one widely-deployed primitive — AES, ChaCha20, ECDH, ML-KEM — becomes a session-compromise event for any protocol that is single-suite per session. QDX's per-channel suite selection means the same session uses different primitives on different channels. Breaking the protocol requires breaking k distinct primitives, not one.
The sender takes an application payload P, encrypts it once with an AEAD cipher under a per-payload data key DK to produce ciphertext C, then performs two operations: a Rabin Information-Dispersal Algorithm (IDA) over C producing n shards, and a Shamir secret-sharing of DK producing n key-shares. Any k-subset of {shard, key-share} pairs is sufficient to recover DK (via Shamir reconstruction) and C (via IDA inverse), then to AEAD-open C back to P. The threshold parameters (k, n) are negotiated at session setup based on the channel set the peers have available.
Each channel selects one cipher suite from the session's negotiated table. The v1 suite catalogue:
| Suite | KEM | AEAD | Target |
|---|---|---|---|
QDX-1-HYBRID-AESGCM | X25519 + ML-KEM-768 | AES-256-GCM | Default. FIPS-friendly. DPU-inline-accelerated. |
QDX-2-HYBRID-XCHACHA | X25519 + ML-KEM-768 | XChaCha20-Poly1305 | Software path. ARM, embedded, no-AES-NI hardware. |
QDX-3-PURE-PQC | ML-KEM-1024 (no classical) | AES-256-GCM-SIV | Paranoid. No classical fallback. Misuse-resistant AEAD. |
QDX-4-FAST-BULK | X25519 + ML-KEM-768 | AEGIS-256 | Throughput-maximized. Modern x86. |
The point of having multiple suites is not to confuse the operator. It is to give each channel a primitive choice appropriate to its hardware and threat model, so that a future cryptanalytic break against (for example) AES-GCM does not cascade into a session-compromise on every channel at once.
On the receiver, scatter-gather collection across channels, per-channel chain verification, threshold reconstruction, and AEAD opening run on a BlueField-2 data-processing-unit. The application sees a single clean reassembled stream via DMA. CPU overhead on the host is negligible. A BlueField-3 upgrade path is scaffolded and documented; the same protocol runs on either generation of silicon.
QDX peers and existing HTTP+HMAC peers interoperate. At session setup, each side declares which transports it speaks. Existing customers running HTTP+HMAC continue to do so; PQC-capable peers upgrade transparently when both sides advertise QDX. There is no flag day for customer migration.
n − k channels. If 5 of 8 channels are jammed and 3 remain (with k = 3), delivery proceeds without retransmission.k channels does not yield reconstruction; replay on k or more is detected by the per-channel chain hashes and the AEAD authentication tag binding the transcript.The QDX core is shipping as an M1 prototype: a 12-crate Rust workspace, 267 tests passing, with the bundled make demo currently delivering 20 of 20 trial sessions at 100% payload integrity. The protocol specification, threat model, key-schedule documentation, and integration guides are written and version-controlled. PQC-native is not aspirational — it is the running code.
The seed round funds the operational productization of QDX into the routing layer. A path-agility router module integrates into DEC NIVMIA and DEC OpenUTM, using:
QDX's channel abstraction is back-end-agnostic: QDX says "send channel 2 via path B" and the router module picks the encoding. The single-IP path remains the default for non-multi-path deployments — the router is an opt-in capability for customers whose networks support it.
QDX is the engineered foundation that lets the rest of the DEC-LLC stack make a credible claim to operating in regulated, federated-trust, and adversarial-medium environments. It is shipping today, not promised.