The cryptographic core everything else at KXCO stands on, published on npm for anyone to read, install and audit before they trust a word of it. You need no account and no API key, and nothing calls home.
One install for the whole family. Or take a single package, listed below.
| Package | Version | What it does |
|---|---|---|
| kxco-pq | 2.0.3 | The whole family in one install. Start here unless you know you want one piece. |
| kxco-post-quantum | 1.7.2 | The primitives: ML-DSA-65, ML-KEM-768 and SLH-DSA-SHA2-192s, with key fingerprinting. OpenSSL 3.5 on Node 24 and later, a JavaScript backend on Node 20 and 22 and in browsers. |
| kxco-pq-scan | 1.1.2 | Finds the quantum-vulnerable cryptography already in a JavaScript dependency tree and separates what Shor's algorithm breaks from what it does not. Emits a CycloneDX CBOM. The one package you can run today without building anything. |
| eslint-plugin-kxco-pq | 1.0.1 | Fails the build when code reaches past the wrapper to touch a raw primitive. |
| kxco-pq-hsm | 1.4.2 | Key custody on a PKCS#11 token. ML-DSA keys are generated on the token and marked unextractable, so the private key never exists in process memory. |
| kxco-pq-sdk | 2.0.2 | Institution identity: hierarchical ML-DSA-65 credentials, HSM-backed signing and anchoring. |
| kxco-pq-cli | 2.1.0 | Key management from a terminal: generate, fingerprint, and rotate under a signed manifest. |
| kxco-verify | 1.3.0 | A standalone, browser-safe verifier. It shares no code with the signer, which is what makes it worth having. |
| kxco-pq-attest | 2.0.3 | Signs any payload into a self-contained envelope a counterparty can check on their own. |
| kxco-pq-audit | 1.4.0 | Tamper-evident audit log: signed entries, SHA-256 hash-chained, and replayable end to end. |
| kxco-pq-vault | 1.1.5 | File and envelope encryption to one or many recipients, using ML-KEM-768. |
| kxco-pq-tls | 1.2.1 | Encrypted channels for Node streams and WebSockets. ML-KEM-768 key exchange alongside X25519. |
| kxco-post-quantum-webhook | 1.2.2 | Signed webhooks, so a recipient can prove which payload came from where. Adapters for Express, Fastify, Hono, Workers and Vercel. |
| kxco-pq-chain | 2.1.4 | Sign an intent, post it to the relay, and Armature L1 verifies the signature in consensus. |
| kxco-pq-agent | 1.1.0 | Identity for AI agents and autonomous systems, sponsored by a verified institution. |
| kxco-pq-network | 1.0.4 | Three levels of proof for an envelope, from the signature alone offline through to a chain anchor. |
Every package is ESM, needs Node 20.19 or later, and ships type declarations.
Claiming a library is correct is easy and worth nothing. So the conformance results, the interoperability matrix, the supply-chain position and the per-package provenance live in one machine-readable document that anyone, or any assessor's tooling, can fetch and diff against the registry.
The published tarballs rebuild byte for byte from their own tags, checked in CI on every run, and the version numbers in that document are regenerated from the registry rather than typed, because a hand-kept evidence file rots faster than anyone checks it.
The platform's own signing identity is published. Fetch it, hash the public key, and confirm the first eight bytes match the key id it claims. Nothing in that check requires trusting this page.
That is ML-DSA-65 under FIPS 204 at NIST Category 3. The document states the algorithm, the specification, the key id and the rule used to derive it.
These packages are the free half of the picture. They give you the primitives, a build-time guardrail, key custody in hardware and an inventory of what you already have. What they deliberately do not do is decide whether a valid signature should count, which is a question about authority rather than mathematics. That decision is KXCO Command, it is licensed, and the architecture page shows how the two halves meet.
For the longer walkthrough, including who needs which package and what it costs, read the toolkit guide.