Quantum-Proof Blockchain
Phase 1 Live — Phase 2 In ProgressKXCO Armature is a quantum-proof permissioned blockchain. It verifies ML-DSA-65 (NIST FIPS-204) post-quantum signatures natively on-chain via a precompile at 0x0b, secures identity, document signing and audit anchoring with ML-DSA-65, and serves traffic over hybrid post-quantum TLS (X25519MLKEM768). Built on the NIST FIPS 203/204/205 standards.
KXCO Armature was designed with post-quantum cryptography as a first-class requirement, not a retrofit. This page documents every cryptographic surface in the system, its quantum exposure, and the protection deployed against it — or the exact roadmap phase that closes it.
Quantum Coverage — 21 surfaces audited
15
Protected today
2
Actively mitigated
4
On defined roadmap
—
Latest block
Green = live protection · Blue = deployed mitigation · Purple = committed roadmap
Complete Cryptographic Coverage Matrix
Every cryptographic surface in KXCO Armature — from transaction signing to backup encryption to entropy sources. No surface is undocumented, no gap is obscured.
| Layer | Surface | Threat | Status | Protection / Algorithm | Notes |
|---|---|---|---|---|---|
| Transaction | Transaction authorization | High | Live | secp256k1 (EVM); optional ML-DSA-65 via PQCAccount or relay, verified on-chain by the 0x0b precompile | Standard EVM signing; post-quantum authorization is available and verified natively on-chain — not forced on every transaction |
| Transaction | Transaction signing — algorithm diversity | High | Live | SLH-DSA-SHAKE-128s (FIPS 205) — hash-based, independent of lattice math | If lattice cryptography (ML-DSA) were broken, hash-based sig remains secure |
| Transaction | Payment memo confidentiality | Low | Phase 2 | ML-KEM-768 (FIPS 203) + AES-256-GCM — available in the kxco-post-quantum SDK | Application-layer encryption via the SDK; not an enforced on-chain feature today. |
| Consensus | Block attestation (per block) | High | Live | ML-DSA-65 (FIPS 204) off-chain attestation log | Independent ML-DSA-65 attestation of finalised blocks (chainId 1111111). A rolling public window + manifest is published continuously to JackKXCO/kxco-attestations; the full per-node log is retained on the validators. |
| Consensus | Validator PQC key pairs | High | Phase 2 | ML-DSA-65 key pairs for validators | Toward ML-DSA-65 consensus signatures; consensus today is QBFT (secp256k1) |
| Consensus | On-chain PQC verification precompile | High | Live | ML-DSA-65 (FIPS 204) precompile at 0x0b | Native EVM precompile verifying Dilithium3 signatures — live in production |
| Consensus | QBFT consensus messages | High | Phase 2 | ML-DSA-65 activation — keys already in place | Network isolated + ML-DSA-65 attestation as interim control |
| Transport | External HTTPS/TLS (chain.kxco.ai) | Medium | Live | X25519MLKEM768 hybrid — TLS 1.3 key exchange | Hybrid: ML-KEM-768 + X25519 — quantum and classical resilient |
| Transport | Node-to-node P2P | High | Mitigated | Private Docker network isolation | Inter-node traffic is not exposed to external parties |
| Account | Account authorization model | High | Phase 2 | PQCAccount (reference) — ML-DSA-65 verified via the 0x0b precompile | Accounts can require a post-quantum signature to move funds; reference implementation, not the default account model |
| Storage | Wallet private keys (at rest) | Medium | Live | AES-256-GCM + Argon2id v3 (64 MB · 3 passes) | Memory-hard KDF resists GPU/ASIC brute-force. 128-bit quantum security (AES-256). |
| Storage | Database backups (at rest) | Medium | Live | AES-256-GCM — encrypted before leaving container | Plaintext copy deleted immediately after encryption |
| Integrity | Block history / chain state | Medium | Live | ML-DSA-65 attestation log (rolling public window) | Independent off-chain integrity record published to JackKXCO/kxco-attestations; forgery of attested blocks is externally detectable. |
| Integrity | Encrypted backup integrity signing | Medium | Live | SLH-DSA-SHAKE-128s (FIPS 205) signature on every encrypted backup file | Hash-based: verifiable by any third party holding the published public key. |
| Session | Authentication tokens | Low | Safe | HMAC-SHA-512 — 256-bit quantum security | Grover's gives at most 128-bit attack on SHA-512; 256-bit HMAC key doubles that |
| API | Institutional API authentication | Medium | Live | ML-DSA-65 per-request signatures (FIPS 204) — alternative to bearer tokens | Server stores only public key. No bearer token to steal or rotate. |
| Hash | EVM hash function (keccak256) | Low | Safe | keccak256 — 128-bit quantum preimage resistance | Grover's algorithm achieves √N speedup: 2^256 → 2^128 operations |
| Hash | Key derivation (Argon2id v3) | Low | Safe | Argon2id v3 — 64 MB, 3 passes. Legacy PBKDF2 paths silently upgraded on next use | Memory-hard. SHA-512: 2^256 quantum preimage. GPU parallelism defeated by memory cost. |
| Entropy | Key generation randomness | None | Safe | OS CSPRNG (crypto.randomBytes) | Quantum computers do not attack entropy sources |
| Contract | Smart-contract PQC signature checks | High | Live | ML-DSA-65 via the 0x0b precompile (staticcall) | Contracts such as PQCAccount verify post-quantum (Dilithium3) signatures on-chain by calling the precompile |
| Infra | Docker image supply chain | Low | Mitigated | All external images pinned to SHA-256 content digests — Cosign + ML-DSA-65 signing Phase 5 | Tag-rebind impossible: Docker rejects any image not matching the pinned digest. Cosign signing adds ML-DSA-65 provenance in Phase 5. |
What Is Quantum-Resistant Today
Armature verifies ML-DSA-65 (NIST FIPS-204) post-quantum signatures natively on-chain, and every HTTPS connection uses hybrid post-quantum key exchange (X25519MLKEM768).On-chain ML-DSA-65 verification (precompile 0x0b) is live in production — smart contracts such as PQCAccount can require a valid post-quantum signature to authorize an action. Standard EVM transactions use secp256k1; the kxco-post-quantum SDK adds SLH-DSA-SHAKE-128s (FIPS 205) for hash-based algorithm diversity and ML-KEM-768 (FIPS 203) for key encapsulation. Wallet private keys use AES-256-GCM with Argon2id v3 (memory-hard KDF, 64 MB).
| Component | Status | Detail |
|---|---|---|
| Native on-chain ML-DSA-65 signature verification (precompile 0x0b) | Live | Armature verifies CRYSTALS-Dilithium3 (ML-DSA-65, NIST FIPS 204) signatures natively inside the EVM via a precompile at address 0x0b — live in production. Smart contracts such as PQCAccount call it (staticcall) to require a valid post-quantum signature before authorizing an action. Standard transactions use secp256k1 for EVM compatibility; the kxco-post-quantum SDK additionally provides SLH-DSA-SHAKE-128s (FIPS 205) for hash-based algorithm diversity. |
| ML-KEM-768 encrypted payment memos (SDK capability) | Phase 2 | Application-layer capability via the kxco-post-quantum SDK: payment narratives (invoice references, settlement IDs, compliance codes) can be encrypted with the recipient's ML-KEM-768 public key, deriving a per-message AES-256-GCM key via HKDF-SHA-512, so only the recipient can read them. This is an application/SDK feature today, not an enforced on-chain protocol feature. |
| ML-DSA-65 per-block attestation log | Phase 2 | An independent ML-DSA-65 attestation of finalised blocks — canonical message keccak256(chainId ‖ blockNumber ‖ blockHash) — published to the public GitHub repository JackKXCO/kxco-attestations as a rolling window of the most recent attestations plus a manifest, updated continuously by a host-side publisher. The full per-node log is retained on the validators. This provides a quantum-resistant chain-of-custody independent of the consensus layer, verifiable by any third party. |
| On-chain ML-DSA-65 verification precompile | Live | Address 0x000000000000000000000000000000000000000b is a native EVM precompile that verifies ML-DSA-65 (Dilithium3, NIST FIPS 204) signatures on-chain — live in production. Smart contracts such as PQCAccount call it (staticcall) to require a valid post-quantum signature before authorizing an action, with no EVM-loop overhead. |
| Hybrid PQ-TLS — X25519MLKEM768 key exchange | Live | All HTTPS connections to chain.kxco.ai use TLS 1.3 with the X25519MLKEM768 hybrid named group as the preferred key exchange. This combines ML-KEM-768 (NIST FIPS 203 / Kyber) with X25519 — a quantum adversary must break both simultaneously to compromise the session. Clients that do not support hybrid PQ fall back to X25519. Verified on nginx 1.29.8 + OpenSSL 3.5.5. |
| Wallet private key encryption (AES-256-GCM + Argon2id v3) | Live | Every wallet private key is encrypted with AES-256-GCM before storage. Key derivation uses Argon2id v3 (PHC winner, memory-hard: 64 MB, 3 iterations, parallelism 1) with a random 32-byte salt and server-side pepper. Memory-hardness defeats GPU/ASIC parallel brute-force: each attempt must hold 64 MB for the full duration. AES-256 provides 128-bit quantum security. Existing v1/v2 (PBKDF2) keys are silently migrated to v3 on next transaction — no user action required. |
| Database backup encryption + SLH-DSA integrity signing | Live | Wallet database backups are encrypted with AES-256-GCM before leaving the container. The plaintext copy is deleted immediately after encryption. Each encrypted backup is additionally signed with SLH-DSA-SHAKE-128s (NIST FIPS 205) — a hash-based signature that proves the backup was produced by KXCO infrastructure. Any third party holding the published public key can verify the signature independently. |
| ML-DSA-65 per-request institutional API authentication | Live | Institutional API clients may authenticate using per-request ML-DSA-65 signatures instead of bearer tokens. The client generates a keypair locally, registers only the public key with a platform administrator, and signs each request with the private key (signed message: timestamp:METHOD:url). The server stores no secret — only the public key. This eliminates bearer token theft risk entirely and makes every request independently verifiable. |
| Session authentication (HMAC-SHA-512) | Safe | Session tokens use HMAC-SHA-512. Grover's algorithm provides at most a √N speedup against hash functions, reducing SHA-512 preimage security from 2^512 to 2^256 quantum operations — orders of magnitude beyond any foreseeable attack. HMAC-SHA-512 was deliberately selected over HMAC-SHA-256 for this reason. |
| Hash functions (keccak256, SHA-512) | Safe | The EVM uses keccak256 for all on-chain hashing. Grover's algorithm gives keccak256 a quantum preimage resistance of 2^128 operations — acceptable under NIST guidance (AES-128 equivalent). SHA-512 (used internally by Argon2id and HKDF) has 2^256 quantum preimage resistance. Neither function is threatened by any known quantum algorithm. |
| Key generation entropy (OS CSPRNG) | Safe | All key generation uses the operating system's cryptographically secure pseudorandom number generator (crypto.randomBytes in Node.js). Quantum computers do not attack entropy sources — CSPRNG security is not affected by quantum capability. |
Independent block attestation log (Live)An ML-DSA-65 attestation of finalised blocks is published continuously to a public GitHub repository — a rolling window plus a manifest — so any regulator, auditor, or counterparty can verify the chain-of-custody independently. The full per-node log is retained on the validators. View attestation log → github.com/JackKXCO/kxco-attestations
What Is Not Yet Fully Quantum-Resistant
Honest disclosure: two attack surfaces use classical cryptography at the protocol layer and have defined roadmap phases to close them.Both have deployed mitigations in effect today that meaningfully reduce the practical risk. Both require protocol-level Besu changes to close fully; the key material and network controls are already in place. Publishing this table is a deliberate choice — any serious counterparty will ask, and partial migration is safer to acknowledge than to obscure.
| Attack Surface | Classical Layer | Residual Risk | Deployed Mitigation | Full Cryptographic Close |
|---|---|---|---|---|
Validator consensus messages Network Isolated + PQC Attested | ECDSA secp256k1 | A quantum adversary could forge consensus votes to manipulate finality. Requires server-level access — consensus traffic is inaccessible externally. | Consensus traffic is isolated on a private Docker network; P2P ports are not externally reachable. An independent, live ML-DSA-65 block attestation log (published to JackKXCO/kxco-attestations) provides a quantum-resistant chain-of-custody so consensus tampering is externally detectable. | Phase 2 — ML-DSA-65 signing of QBFT consensus messages at the protocol level. Dilithium3 key material is already generated and stored; activation is a software upgrade, not a key ceremony. |
Node-to-node P2P transport Network Isolated + PQ-VPN Active | Classical TLS (ECDH) | Harvest-now-decrypt-later on classical ECDH. On the current single-server deployment, all inter-node traffic is on the Docker bridge and cannot be harvested externally — there is no traffic for an adversary to record. | Docker bridge isolation + localhost-only P2P ports. A WireGuard overlay with ML-KEM-768 (NIST FIPS 203 / Kyber) derived preshared keys is deployed and active — this wraps ECDH with a post-quantum symmetric layer, neutralising harvest-now-decrypt-later even if Curve25519 is later broken. | Phase 3 — ML-KEM-768 replaces ECDH natively in the Besu node transport layer. |
Peer comparison
Same attack surfaces — how major chains respond
Bitcoin, Ethereum, and Solana share these attack surfaces. None has deployed mitigations. On public permissionless networks, the P2P harvest-now-decrypt-later attack is actively feasible today — anyone can connect and record encrypted traffic. KXCO Armature's P2P is inaccessible to external parties.
| Attack Surface | Bitcoin | Ethereum | Solana | KXCO Armature |
|---|---|---|---|---|
| Consensus / validator signing | PoW — no signing No consensus signatures; PoW-based finality. All node communication is classical and public. | BLS12-381 (classical) Validator attestations use classical BLS aggregate signatures. No PQC. Open network — traffic is harvestable. | Ed25519 (classical) Vote transactions signed with Ed25519. No PQC. Open network. | QBFT (secp256k1) + on-chain ML-DSA-65 verify QBFT proof-of-authority consensus (secp256k1); Armature additionally verifies ML-DSA-65 post-quantum signatures natively on-chain (precompile 0x0b). Permissioned network — consensus is not externally reachable. |
| Node-to-node P2P transport | TCP / ECDH (v2) Bitcoin v2 P2P adds classical ECDH encryption. No PQC. Fully public — any party can connect and harvest traffic today. | libp2p/Noise — X25519 Classical X25519 ECDH key exchange. No PQC. Fully public network — harvest-now-decrypt-later is actively feasible. | QUIC/TLS 1.3 — ECDH Classical ECDH in TLS 1.3. No PQC. Fully public — any party can harvest encrypted traffic. | Classical TLS — network isolated + WireGuard PQ PSK active All P2P runs on a private Docker bridge (172.20.0.0/24). No external traffic to harvest. ML-KEM-768 WireGuard PSK overlay is deployed and active. |
| External HTTPS / API transport | Classical TLS 1.3 Classical ECDH (X25519). No hybrid PQ. Harvest-now-decrypt-later on all API traffic. | Classical TLS 1.3 No PQ-TLS on any major Ethereum endpoint. X25519 only. | Classical TLS 1.3 No hybrid PQ-TLS deployed. | X25519MLKEM768 hybrid TLS TLS 1.3 with X25519MLKEM768 as the preferred named group. Hybrid: must break both ML-KEM-768 and X25519 simultaneously to compromise the session key. |
| Account / address model | HASH160(secp256k1) Public key revealed on first spend. No PQC accounts or migration path deployed. | keccak256(secp256k1) Public key revealed on first spend. EIP-4337 account abstraction exists but no PQC wallet standard is deployed or scheduled. | Ed25519 pubkey = address The public key is directly the account address — exposed on every transaction. Worst-case quantum exposure of any major chain. | PQCAccount (ML-DSA-65) available Accounts can use PQCAccount, governed by an ML-DSA-65 key verified on-chain by the 0x0b precompile (live in production) — so secp256k1 exposure alone confers no authority over assets. Reference implementation, not the default account model. |
| Private key / data at rest | Application-dependent No protocol-level specification. Most wallets use AES-256 if they encrypt at all. | Application-dependent Keystore format (EIP-55) uses AES-128-CTR with PBKDF2 or scrypt. AES-128 has only 64-bit quantum security — below NIST minimum. | Application-dependent No protocol-level encryption standard for stored keys. | AES-256-GCM + Argon2id v3 Wallet private keys encrypted with AES-256-GCM and Argon2id v3 (memory-hard: 64 MB, 3 passes). AES-256: 128-bit quantum security. Argon2id defeats GPU/ASIC parallelism. Note: Ethereum keystore format uses AES-128 — insufficient under NIST guidance. |
| Deployed PQC mitigations (total) | None No committed roadmap. | None No formal EIP or committed timeline for base-layer PQC. | None No public PQC roadmap. | High-risk surfaces addressed 17 of 21 surfaces protected today. Native on-chain ML-DSA-65 verification (precompile 0x0b), hybrid PQ-TLS (X25519MLKEM768), AES-256-GCM + Argon2id v3 key storage, ML-DSA-65 API auth, and post-quantum identity/document signing are live. ML-DSA consensus signatures, PQCAccount as the default account, and per-block attestation are on the roadmap. |
Implementation Specifics
The following details address the questions a cryptographic peer would ask before accepting our implementation claims.
ML-DSA-65 (Dilithium3) Parameters
| Algorithm | CRYSTALS-Dilithium3 (ML-DSA-65) |
| Standard | NIST FIPS 204, August 2024 |
| Security level | NIST Level 3 ≈ AES-192 |
| Mathematical basis | Module Lattice (MLWE + MSIS) |
| Public key size | 1,952 bytes |
| Signature size | 3,309 bytes |
| Resistant to | Shor's algorithm, Grover's algorithm |
ML-KEM-768 (Kyber) — TLS Key Exchange
| Algorithm | ML-KEM-768 (Kyber768) |
| Standard | NIST FIPS 203, August 2024 |
| Security level | NIST Level 3 ≈ AES-192 |
| Mathematical basis | Module Lattice (MLWE) |
| TLS group name | X25519MLKEM768 (hybrid) |
| Deployment | nginx 1.29.8 + OpenSSL 3.5.5 |
| Fallback | X25519 for non-PQ clients |
Post-Quantum Signing on Armature
| Base transactions | secp256k1 ECDSA (EVM-compatible) |
| On-chain PQC verify | ML-DSA-65 precompile at 0x0b (FIPS 204) — live |
| Post-quantum auth | PQCAccount / relay require an ML-DSA-65 signature |
| Algorithm diversity | SLH-DSA-SHAKE-128s (FIPS 205) in the SDK |
| Identity & documents | ML-DSA-65 KxcoIdentity, document signing, audit anchoring |
| Verification | Native in the EVM via staticcall to the 0x0b precompile |
Symmetric & Key Derivation Layer
| Private key encryption | AES-256-GCM |
| Backup encryption | AES-256-GCM |
| KDF (current v3) | Argon2id — 64 MB, 3 passes, parallelism 1 |
| KDF (legacy v1/v2) | PBKDF2-SHA-256 / PBKDF2-SHA-512 — auto-upgraded |
| Salt | 32 bytes random per key |
| Server pepper | Additional secret in environment |
| Memory zeroization | Derived AES key Buffer.fill(0) after use |
| Session MAC | HMAC-SHA-512 |
| Quantum security | 128-bit (AES-256) / 256-bit (SHA-512) |
SLH-DSA-SHAKE-128s Parameters
| Algorithm | SPHINCS+-SHAKE-128s (SLH-DSA) |
| Standard | NIST FIPS 205, August 2024 |
| Security level | NIST Level 1 ≈ AES-128 |
| Mathematical basis | Hash functions (SHA-3 / SHAKE) only |
| Public key size | 32 bytes |
| Signature size | 7,856 bytes |
| Why deployed | Algorithm diversity: different math from ML-DSA |
ML-KEM-768 Encrypted Memos
| Encapsulation | ML-KEM-768 (NIST FIPS 203) |
| Memo encryption | AES-256-GCM, fresh IV per transfer |
| Key derivation | HKDF-SHA-512 from secp256k1 key |
| Data location | Transaction data field (on-chain, immutable) |
| Format | KXCOMEMO header + KEM ciphertext + IV + tag + ciphertext |
| Decryption | Server-side, on authenticated request only |
| Observer view | Opaque ciphertext — memo content not visible |
ML-DSA-65 Precompile Parameters
| Algorithm | ML-DSA-65 (CRYSTALS-Dilithium3) |
| Standard | NIST FIPS 204 |
| Security level | NIST Level 3 |
| Mathematical basis | Module-LWE lattice |
| Public key size | 1,952 bytes |
| Signature size | 3,309 bytes |
| Deployment | Native EVM precompile at 0x0b — live in production |
| Use case | On-chain PQC signature verification (e.g. PQCAccount) |
kxco-post-quantum — Open Source Library
| Package | kxco-post-quantum |
| Version | v1.0.3 (npm) |
| License | MIT — independently auditable |
| Algorithms | ML-DSA-65, ML-KEM-768, SLH-DSA-SHAKE-128s |
| Standards | NIST FIPS 203, 204, 205 |
| Used in | Block attestation, API auth, tx signing |
| Audit status | Public — source reviewable by any third party |
Why Level 3 (Dilithium3) and not Level 5 (Dilithium5)?Dilithium5 increases the signature size to 4,595 bytes, adding approximately 40% overhead versus Dilithium3. For a private permissioned network with a known and controlled validator set, NIST Level 3 provides a security margin that materially exceeds any foreseeable quantum attack capability. This follows NIST's own published guidance that Level 3 is appropriate for most production infrastructure. Level 5 is available as a configurable upgrade if the threat model changes.
Why X25519MLKEM768 (hybrid) for TLS rather than pure ML-KEM?The hybrid approach ensures security against both classical and quantum adversaries simultaneously. If ML-KEM-768 has an undiscovered vulnerability, X25519 still protects the session. If X25519 is broken by a quantum computer, ML-KEM-768 still protects it. Both must be broken simultaneously. This follows the IETF hybrid PQ recommendation (draft-ietf-tls-hybrid-design) and NIST's own migration guidance. OpenSSL 3.2+ supports X25519MLKEM768 natively.
Roadmap to Full Quantum Resistance
The roadmap defines what "fully quantum-resistant" means for KXCO Armature and the concrete steps to achieve it. Each phase closes a specific residual gap identified in the tables above.
Phase 1 — Complete
PQC Foundation & Infrastructure Hardening
Live: native on-chain ML-DSA-65 verification (0x0b precompile), hybrid PQ-TLS, key-at-rest encryption, ML-DSA-65 API auth, post-quantum identity & document signing
- Native on-chain ML-DSA-65 (Dilithium3, FIPS 204) signature verification — EVM precompile at 0x0b, live in production
- PQCAccount: reference ERC-4337-style smart account that verifies an ML-DSA-65 signature via the 0x0b precompile
- Hybrid PQ-TLS: X25519MLKEM768 on HTTPS endpoints via nginx + OpenSSL 3.5 (verified live)
- Wallet private key encryption: AES-256-GCM + Argon2id v3 (64 MB · 3 passes) — memory-hard, silent migration from PBKDF2 on next use
- Database backup encryption: AES-256-GCM with SLH-DSA-SHAKE-128s integrity signatures — hash-based, third-party verifiable
- ML-DSA-65 per-request API authentication: server stores only the public key, no bearer token required
- Post-quantum identity (KxcoIdentity), document signing and audit anchoring use ML-DSA-65
- All external Docker images pinned to SHA-256 content digests — tag-rebind supply chain attack eliminated
Phase 2 — In Progress
PQC Consensus Layer — QBFT Validator Signing
Surface closed: validator consensus messages
- All QBFT consensus messages (proposals, votes, commits) signed with Dilithium3 in addition to classical key
- No new key generation required — Dilithium3 keys from Phase 1 are activated for consensus use
- Dual-signing transition: both classical and PQC signatures required during migration window, then classical retired
- Coordinated upgrade across all four validators — executed as scheduled maintenance
Phase 3 — Planned
Native PQC Transport, Transaction Type & On-Chain Precompile
Surfaces closed: P2P transport (protocol-level), EVM account model (protocol-level), on-chain verification
- ML-KEM-768 replaces ECDH in node-to-node TLS at the Besu protocol layer — eliminates harvest-now-decrypt-later residual on P2P
- Native Dilithium3 transaction type promoted from application layer to protocol layer
- On-chain ML-DSA-65 (Dilithium3) verification precompile — LIVE at 0x0b (delivered ahead of this phase); smart contracts verify PQC signatures without EVM-loop overhead
- Dilithium3-derived address scheme — new accounts use PQC-derived addresses by default
- Existing accounts: migration tooling provides balance continuity path to PQC-derived addresses
Phase 4 — Planned
Classical Signing Retirement — Full PQC Operation
Result: all active signing operations are quantum-resistant at the protocol level
- Classical secp256k1 transaction signing disabled at protocol level after migration window closes
- Network operates entirely on Dilithium3 for all active signing operations
- Classical keys retained for historical signature verification (read-only)
- As a private permissioned network, KXCO Armature executes this upgrade by validator governance vote — no contentious hard fork
Phase 5 — Planned
Supply Chain Hardening — PQC-Signed Docker Images
Surface: Docker image supply chain — digest-pinned today, Cosign provenance Phase 5
- All external images already pinned to SHA-256 content digests — tag-rebind attack is not possible today
- Phase 5 adds Cosign + ML-DSA-65 cryptographic provenance signing to all production images
- Mandatory signature verification before container start — invalid signatures block deployment
- Validator operator onboarding includes public key registration for supply chain trust chain
PQC Readiness — KXCO Armature vs Major Blockchain Networks
As of 2026, no major public blockchain has deployed production post-quantum transaction signing or hybrid PQ-TLS. KXCO Armature is in a distinct category: PQC is operational across multiple layers, not planned.
| Network | Classical Signing | PQC Tx Signing | PQC Consensus | Hybrid PQ-TLS | Roadmap |
|---|---|---|---|---|---|
| KXCO Armature | secp256k1 ECDSA | Live | Phase 2 | Live | Active — 5-phase plan, Phase 1 complete. 19 of 21 surfaces protected or mitigated today. |
| Bitcoin | secp256k1 ECDSA / Schnorr | None | None | None | No formal roadmap. BIP discussions exist; no consensus. |
| Ethereum | secp256k1 ECDSA | None | None | None | No formal standard or committed timeline. EIP-4337 could support PQC wallets as an application layer; no base-layer implementation is scheduled. |
| Solana | Ed25519 | None | None | None | No public roadmap. |
| XRP Ledger | secp256k1 / Ed25519 | None | None | None | Exploratory discussion only. No committed implementation. |
| Hedera | secp256k1 / Ed25519 | None | None | None | Community discussion. No formal proposal. |
| QRL | XMSS (hash-based) | Partial | None | None | PQC tx signing via XMSS (stateful — state management burden on signers). No ML-KEM, no hybrid TLS, no encrypted memos, no institutional settlement layer. |
Why public chains lag on PQCPublic blockchains require social consensus across thousands of independent stakeholders to change cryptographic primitives — a process that takes years and often fails. KXCO Armature's permissioned architecture means a quantum upgrade is a scheduled maintenance event coordinated across a known validator set. The key material is already in place. Activation requires governance vote, not a contentious hard fork. Hybrid PQ-TLS requires only an nginx configuration change and a supported OpenSSL version — both already satisfied.
Design Principles — Why This Architecture
Harvest-Now-Decrypt-Later
Nation-state adversaries are known to record encrypted traffic today for decryption when quantum capability matures. This applies to TLS sessions, inter-node P2P traffic, and any encrypted communication. KXCO Armature addresses this at every layer: hybrid PQ-TLS for external traffic, network isolation for P2P, AES-256 for stored data.
No Proprietary Cryptography
KXCO Armature uses only NIST-standardised algorithms. CRYSTALS-Dilithium3 and Kyber underwent six years of public cryptanalysis as part of the NIST PQC competition. The hybrid TLS group X25519MLKEM768 follows the IETF hybrid design draft. No custom, unreviewed, or "quantum-resistant by claim" schemes are employed anywhere in the stack.
Hybrid Transitional Security
Every PQC deployment on KXCO Armature uses a hybrid model during the transition: transaction signing requires both secp256k1 and ML-DSA-65; TLS uses both X25519 and ML-KEM-768. An adversary must break both the classical and post-quantum component simultaneously. This provides forward security even if either component has an undiscovered vulnerability.
Accelerated Response Capability
All PQC key material was generated at genesis. The TLS upgrade required only a configuration change. The migration path is pre-planned and pre-tested. A credible quantum timeline compression does not require emergency key generation, network redesign, or stakeholder consensus — the infrastructure is ready to accelerate.
Symmetric Safety Margin
AES-256 was deliberately chosen over AES-128 because Grover's algorithm halves symmetric key security in the quantum setting: AES-128 provides only 64-bit quantum security, below NIST's 128-bit minimum. AES-256 provides 128-bit quantum security. Argon2id v3 (memory-hard: 64 MB, 3 passes) was chosen over PBKDF2 for key derivation — its memory cost defeats GPU/ASIC parallel attacks that PBKDF2 cannot resist. Note: Ethereum's keystore format uses AES-128-CTR + PBKDF2 — insufficient on both counts under NIST guidance.
No Public Mempool Exposure
Transactions are not broadcast to a public network before inclusion. The window in which an adversary could observe a pending transaction's public key before it is mined — a known attack vector on public chains — does not exist on KXCO Armature. This eliminates a class of quantum timing attacks that are genuinely feasible against Bitcoin and Ethereum today.
Standards & Regulatory References
| Standard | Body | Published | Relevance to KXCO Armature |
|---|---|---|---|
| FIPS 204 — ML-DSA (Dilithium) | NIST | Aug 2024 | Primary signature algorithm — deployed in production for transaction signing and block attestation |
| FIPS 203 — ML-KEM (Kyber) | NIST | Aug 2024 | Key encapsulation — deployed in X25519MLKEM768 TLS hybrid; targeted for Phase 3 P2P transport layer |
| FIPS 205 — SLH-DSA (SPHINCS+) | NIST | Aug 2024 | Available in the kxco-post-quantum SDK — SLH-DSA-SHAKE-128s for hash-based algorithm diversity and backup integrity signing |
| FIPS 206 — Falcon (FN-DSA) | NIST | Draft | Not deployed on Armature; on-chain PQC verification uses ML-DSA-65 (FIPS 204) at the 0x0b precompile |
| IETF draft-ietf-tls-hybrid-design | IETF TLS WG | 2024 | Hybrid post-quantum TLS key exchange design — basis for X25519MLKEM768 implementation |
| NSA CNSA 2.0 | NSA / CISA | Sep 2022 | US government mandate: PQC migration complete by 2035 for national security systems |
| BSI TR-02102-1 | BSI (Germany) | 2024 | German federal guidance on cryptographic algorithms — Dilithium3 and AES-256 compliant |
| ENISA PQC Report | ENISA (EU) | 2022 | European cybersecurity agency PQC migration guidance for critical infrastructure |
| MAS TRM Guidelines | MAS (Singapore) | 2021 | Monetary Authority of Singapore technology risk framework — cryptographic agility requirement |
Technical enquiries
For implementation specifications, cryptographic audit requests, or integration questions, contact the KXCO Armature engineering team.