Engineering · Open Source

We put our cryptography in the open.

KXCO has published fourteen post-quantum packages on npm and GitHub, independently indexed by Socket.dev. It is the inspectable foundation of the KXCO stack, and the point is that you don't have to take our word for any of it. This is what third-party-verifiable security looks like.

post-quantum open source third-party verifiable KXCO Engineering 21 July 2026 ~11 min read

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.

01Trust you can check for yourself

In a field crowded with "quantum-safe" marketing, the rarest thing is a claim a third party can verify rather than believe. That is what open-sourcing the foundation delivers. Anyone, a bank's security team, a regulator, a competitor, can inspect exactly how KXCO implements post-quantum cryptography, to the finalised NIST standards, and confirm it is real, current and correct.

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

02The fourteen 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-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-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-65 and anchor the attestation on-chain. kxco-pq-auditAudit & compliance, tamper-evident, 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-65 keypair and locked capability scope. kxco-pq-chainHTTP client for the post-quantum identity relay, sign 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-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.

03Why "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.

04Only the foundation, the rest is deliberately private

What is public is the foundation: primitives, the identity layer, verifiers and tooling. It is real and enough to build on. It is not everything KXCO has built. The advanced components, coordination logic, the ontology engine, and the systems that compose these primitives into one verifiable reality, are proprietary. They are protected through the combination that fits each system: trade secrets for the work that is strongest unpublished, and patent filings where protection is best served by filing. The core method for generating identity-verified operational records anchored to a blockchain ledger is already the subject of a filed patent application, S2025/0544.

The posture is two-tier by design: open-source the foundation so it can be inspected and trusted, and protect the advanced work as trade secrets and patent filings, matched to what each system needs. What you can see is genuine. What you cannot see is further ahead, and it is not unprotected.

05From packages to the product family

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

KXCO MeridianWhere Members run their deals. Built on the SDK, HSM, CLI and verifier packages. KXCO SentinelThe quantum-resistant cloud, attestation, tamper-evident audit and signed events. Armature L1The post-quantum settlement record, on-chain anchoring of signed intents and attestations. KnightsPurseWallet for people and AI agents, post-quantum identity via the agent and base packages. KXCO Treasury & MeridianEncrypted data and channels beneath value, deal-making and NDA-gated rooms.

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.

06Chain, 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-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.

07What 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.

08The 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.

The test that proved itself

On 31 August the ACVP job failed on a dependency bump made hours earlier. @noble/post-quantum 0.7.1 fails nine NIST SLH-DSA verification vectors that 0.7.0 passes, returning false where the vectors require true, which means a valid signature can be rejected. Nothing in that release's notes suggested signature verification had changed; they described option-handling hardening.

It was reverted within the hour, the affected release was deprecated on npm with an explanation, and the fix was public the same day. The whole sequence is in the changelog and the commit history.

A test suite that passes is not evidence of much. A test suite that catches a fault nobody was looking for, in a dependency nobody had reason to distrust, is the only kind worth maintaining. That is what the conformance harness is for, and it earned its keep.

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-3 parameters; KXCO does not claim CNSA 2.0. The Musk quotation is reproduced from public reporting for commentary. Nothing here is investment advice.