KXCO's founding principle is "proof, not promises." Today we applied it to our own software. The cryptography that issues identities, signs records and encrypts data across the KXCO stack is now public: fourteen open-source post-quantum packages on npm, mirrored on GitHub and independently indexed by the supply-chain security service Socket.dev. Not a black box behind a sales deck, code you can read, run and scan.

Update, 16 August 2026

kxco-post-quantum reached 1.3.0: @noble/post-quantum 0.7.0, plus FIPS 204/205 context-parameter support for domain separation at the signature level. While rolling that out, we audited the rest of the family and found seven packages calling the underlying primitive's raw sub-namespace directly instead of going through the wrapper's own sign/verify API, a latent inconsistency rather than a break, since the signatures those call sites produced were always correct. It pinned them to one @noble generation and left them without the new context support. All seven are migrated, re-tested and republished: kxco-pq-sdk, kxco-pq-audit, kxco-pq-attest, kxco-pq-tls, kxco-pq-cli, kxco-pq-agent and kxco-pq-hsm. Every commit and version bump is on the public repos linked below, the same standard this whole post argues for.

Trust you can check for yourself

# the base layer, install and inspect it yourself
npm i kxco-post-quantum
# or the complete stack in one package
npm i kxco-pq

The 14 packages

Rather than one library, KXCO released an interconnected suite: a base primitives layer, specialised modules for regulated needs, developer tooling, and a meta-package that ties them together.

kxco-post-quantumThe base layer, ML-DSA-87 and ML-DSA-65 signatures and ML-KEM-768 key encapsulation with key fingerprinting. kxco-pqThe complete stack in one package, identity, HSM, audit, attestation, channels, encryption, webhooks, chain relay. kxco-pq-sdkInstitution identity layer, hierarchical ML-DSA-87 and ML-DSA-65 credentials, HSM-backed signing, optional Armature L1 anchoring. kxco-pq-vaultData protection, file and envelope encryption with ML-KEM-768, to one or many recipients. kxco-pq-attestSignatures & proof, sign documents with ML-DSA-87 or ML-DSA-65 and anchor the attestation on-chain. kxco-pq-auditAudit & compliance, tamper-evident, ML-DSA-87 or ML-DSA-65 signed, SHA-256 hash-chained log; tampering breaks the chain. kxco-pq-tlsSecure communication, post-quantum encrypted channels for Node.js streams and WebSockets. kxco-pq-hsmSigning and decapsulation across a hardware security module boundary, institutional key custody. kxco-pq-agentAI-agent identity, a KYC-verified institution sponsors an ML-DSA-87 or ML-DSA-65 keypair and locked capability scope. kxco-pq-chainHTTP client for the post-quantum identity relay, sign ML-DSA-87 or ML-DSA-65 intents and post them to the record. kxco-post-quantum-webhookPost-quantum webhook signing and verification, recipients can prove a payload came from you. kxco-pq-cliCommand-line institution key management, generate and rotate ML-DSA-87 and ML-DSA-65 keypairs. kxco-verifyA standalone, browser-safe verifier for KXCO signatures and attestations, no account required.

The categories map to what regulated institutions actually need: data protection, digital signatures, hash-chained audit, secure channels, AI-agent identity, HSM key custody and developer tooling. HSM support, tamper-evident logs and on-chain attestation are not demo features, they are compliance requirements.

Why "in the open" is the whole point

Publishing openly is not generosity; it is evidence. Three independent surfaces now carry KXCO's cryptography, and none is controlled by our marketing:

  • npm, live, versioned, installable by anyone; the version history shows sustained development, not a one-off drop.
  • GitHub, the source is readable line by line and auditable by any security team before a byte is trusted.
  • Socket.dev, an independent supply-chain security service indexes and scans the suite, entirely outside KXCO's control.

This is third-party validation in its most durable form. A vendor can claim anything in a datasheet; it cannot fake a public, inspectable, independently scanned codebase implementing named NIST standards. That KXCO exposes its cryptographic foundation to that scrutiny, and that the suite is coherent and production-shaped rather than a toy, is a signal about the maturity of the engineering behind it. Confidence that survives inspection is the only kind worth having.

From packages to the product family

These packages are the cryptographic engine inside KXCO's products, the same primitives, exposed as libraries.

KXCO GuildhallWhere Members run their deals. Built on the SDK, HSM, CLI and verifier packages. KXCO PortcullisThe quantum-resistant cloud, attestation, tamper-evident audit and signed events. Armature L1The post-quantum settlement record, on-chain anchoring of signed intents and attestations. KXCO walletWallet for people and AI agents, post-quantum identity via the agent and base packages.

The open-source suite is therefore also a preview: the quality visible in the packages is the quality running inside the platform. The verifiable state of the foundation is direct evidence for the advanced, private state of the whole.

Chain, quantum and AI, converging, and KXCO is early

Three forces are arriving at once. AI is producing autonomous agents that act, not just advise. Quantum computing is threatening the cryptography under everything they touch. And the chain is becoming the neutral record where their actions settle and can be proven. Handled separately they are three problems; handled together they are one, and these packages sit exactly on that seam.

// an agent, quantum-resistant from identity to settlement to proof
kxco-pq-agent    // institution sponsors a post-quantum agent identity
kxco-post-quantum // it signs each action with ML-DSA-87 or ML-DSA-65
kxco-pq-chain     // the action is anchored on Armature L1
kxco-verify       // anyone verifies it offline, no KXCO account

That is chain, quantum and AI operating as one system, shipped as software you can install today. Very few organisations are building at this intersection at all; fewer still have published working code to prove it. The deeper account is in Why KXCO is the indispensable environment for the AI-quantum era.

What third-party validation signals

For an institution evaluating KXCO, the takeaway is simple: the claims are checkable, the foundation is open and independently scanned, the engineering is advanced enough to expose to the world and mature enough to carry a product family, and the most advanced work is deliberately held back, which means the visible state of the art is a floor, not a ceiling. Verifiable in public, advanced in private. KXCO is not asking to be believed; it is inviting inspection, and letting the code speak.

The evidence, updated August 2026

Publishing the code was the first step. The second was making the claims about it checkable, which took most of August. Four things now ship with every release, and all four can be verified by someone who has never spoken to us.

Conformance. The package runs against NIST's own ACVP test vectors on every change: 2,103 cases, zero failures. The vectors are fetched from NIST rather than bundled by us, and checked against a published list of digests, so a silently rewritten upstream fails the job rather than changing the result. Run it with npm run conformance:acvp.

Interoperability against three independent implementations. Passing NIST's vectors proves agreement with NIST. It does not prove a counterparty on different software can read what we sign. So the matrix runs in both directions against liboqs, the reference C implementation the field measures itself against, Bouncy Castle, and two pure-Python libraries written from the specification. 225 checks, zero failures, including negative controls: a tampered signature the peer must reject, and a corrupted ML-KEM ciphertext that must yield an unrelated secret. Those two are the reason to believe the other checks, because a peer whose verify returned true unconditionally would pass everything else.

Provenance and a bill of materials. Every release carries a SLSA provenance attestation tying the published tarball to the commit and workflow that built it, verifiable with npm audit signatures. Every release also publishes a CycloneDX SBOM at a permanent unauthenticated URL on the GitHub release, not an expiring build artifact.

Reproducible builds. The published tarball rebuilds from its own tag, byte for byte, and CI checks it on every run. A provenance attestation says a build happened in CI. A reproducible build says the artefact is the source. Those are different claims and the project makes both.

OpenSSL where the platform provides it

Since 1.5.0 the FIPS 203/204/205 primitives run in OpenSSL 3.5 on Node 24 and later, rather than in JavaScript. Older Node and browsers keep the JavaScript backend. The two are interchangeable on the wire, which is checked rather than assumed: the interoperability matrix runs in full against both, CI runs both legs, and every generated report records which backend produced it.

Signing is roughly six times faster on the OpenSSL path, and the tail matters more than the average: ML-DSA-65's p99 drops from 40.8 ms to 4.6 ms. The rejection-sampling tail that makes ML-DSA signing unpredictable is still there, about nine times tighter.

Explore the packages: npmjs.com/~kxco · github.com/KnightsbridgeAIQ · socket.dev/npm/user/kxco. KXCO is a software company; regulated services are operated by licensed institutions. Cryptographic posture reflects NIST FIPS 203/204/205 alignment at Category-5 and Category-3 parameters; KXCO does not claim CNSA 2.0. The Musk quotation is reproduced from public reporting for commentary. Nothing here is investment advice.