Check It Yourself: The Evidence Behind the KXCO Post-Quantum Stack

1. The claim, and how to break it

Every infrastructure vendor says its technology is real. The word for the ones that are not is vapourware, and the reason the word exists is that the claim and the evidence are usually separated by a sales cycle. So let me do this the other way round. Here is the claim, and here are the commands that would expose it if it were false.

The claim: KXCO runs a working post-quantum cryptography stack. Fourteen packages are published. The base layer is tested against NIST's own vectors. It interoperates with independent implementations that share no code with it. It signs real documents in production, and those signatures are anchored on a public chain where anyone can check them.

Four commands test all of that.

npm view kxco-post-quantum
npm audit signatures
curl -s https://www.livetradingnews.com/<any-article> | grep content-signature-kid
curl -s -X POST https://chain.kxco.ai/rpc -d '{"jsonrpc":"2.0","id":1,
  "method":"eth_getTransactionByHash","params":["0x30658fc5..."]}'

The first tells you whether the package exists and what it depends on. The second tells you whether the published binary was actually built from the source it claims. The third tells you whether a live article carries a real post-quantum signature. The fourth tells you whether that signature is on a chain.

Nothing in this article asks you to trust me. Every figure below was read from a public endpoint on 23 August 2026, and the query that produced it is printed alongside it.

2. What is actually published

Fourteen packages sit on npm under the kxco maintainer account. All are Apache-2.0, all are ESM-only, all require Node 20.19 or later. The base layer, kxco-post-quantum, was first published on 20 May 2026 and has shipped 22 versions since.

A published version history is the cheapest form of evidence and the hardest to fake. Twenty-two versions of the base package across three months is a record of a thing being maintained. It is also a record of mistakes being fixed, which matters more, and I will come back to that.

The dependency graph is public and it is not what the marketing version of this story would say. Eight packages depend on kxco-post-quantum directly: the SDK, vault, TLS, chain, attest, HSM, audit and agent layers. Two more, the umbrella and the CLI, reach it transitively. That is ten of the thirteen siblings.

Three do not depend on it at all, and that is deliberate. kxco-post-quantum-webhook has zero runtime dependencies. kxco-verify reaches the primitives directly rather than through our own wrapper. That second one is worth pausing on, because it looks like an inconsistency and is actually the point: a verifier that shares no code with the signer is a stronger check than one that shares all of it. If our wrapper had a bug that made bad signatures look good, a verifier built on the same wrapper would agree with it. One built independently would not.

3. Proof one: the binary was built from the source it claims

The oldest problem in software supply chains is that the package on the registry and the code in the repository are two different artefacts, and nothing normally connects them. You read the source on GitHub, you install the tarball from npm, and you assume they match.

[email protected] carries a SLSA provenance attestation. It states, cryptographically, that this exact tarball was built by a GitHub-hosted runner from github.com/KnightsbridgeAIQ/kxco-post-quantum at git tag refs/tags/v1.4.0 via .github/workflows/publish.yml. The registry serves the attestation at a public URL and npm audit signatures checks it for you.

That closes the gap between the source and the binary without anyone having to take our word for it.

Four of the fourteen packages carry it today: kxco-post-quantum, kxco-pq-tls, kxco-pq-hsm and kxco-pq-audit. Those four are the most recent releases, published on 17 and 18 August. The other ten were published by an automation token, which authenticates the publisher but attests nothing about the build. Provenance is being rolled forward as each package cuts its next release, base layer first.

I would rather write that sentence than round it up to fourteen. Four of fourteen is a real state of a real migration. Fourteen of fourteen would be a lie a reader could check in ninety seconds.

4. Proof two: the mathematics is right, and the library is stricter than the test file

NIST publishes test vectors for its post-quantum standards through the ACVP programme. They are the reference answers. If your implementation disagrees with them, your implementation is wrong.

The conformance run pins NIST's vector repository at commit 975de31eb83d87039ec88934fdc47d8c312b892d, with per-file SHA-256 digests recorded in the repo. If NIST rewrites a file upstream, the fetch fails rather than the result silently changing. That detail is the difference between a test suite and a claim about a test suite.

The result: 2,103 tests run, 1,793 passed, 0 failed, 310 skipped.

Coverage is wider than the package's own surface. Every parameter set NIST publishes vectors for is exercised, not only the five the package wraps in its own helpers: ML-KEM-512, 768 and 1024, ML-DSA-44, 65 and 87, and all twelve SLH-DSA sets across SHA2 and SHAKE at 128, 192 and 256 bits, in both fast and small variants. The signature sets cover every interface variant in NIST's files: external and internal interfaces, pure and pre-hashed, external-mu, deterministic and randomised signing, empty and non-empty context strings. Deterministic groups reproduce NIST's expected signature bytes exactly.

Now the 310 skips, because a sceptical reader should go straight to them. They are not gaps in coverage. Every one is a pre-hash pairing the library refuses to sign, because the hash offers less collision strength than the parameter set requires. SHA2-256 with ML-DSA-87 offers 128 bits against 256 required. SHAKE-128 with ML-DSA-65 offers 128 against 192. NIST's sample files pair every approved hash with every parameter set, including those combinations. The library declines them.

That is the implementation being stricter than the vector file. It would have been easy to sign those cases, pass 2,103 of 2,103, and print a bigger number. Instead the refusals are counted separately, each with its reason, on the stated principle that a skip is not a pass.

5. Proof three: it interoperates with code that shares nothing with it

Passing your own tests proves you are self-consistent. It does not prove you are correct. The test that matters is whether an independent implementation, written by other people from the same specification, agrees with your bytes.

Two peers, both version-pinned: Bouncy Castle bcprov-jdk18on:1.85.2 in Java, and dilithium-py 1.4.0 with kyber-py 1.2.0 in Python. Neither shares code with our backend. Bouncy Castle is one of the most widely deployed cryptographic libraries in enterprise Java; the Python pair are independent spec-derived implementations.

Result: 156 checks passed, 0 failed, 10 not applicable, across 24 rows.

Each row runs six checks in both directions:

The last two are negative controls, and they are the reason to believe the first four. Without them, a peer whose verify function returned true unconditionally would pass every positive check in the matrix. This is the part of a conformance claim that is almost always missing.

Two further details establish the posture more than the pass count does. SLH-DSA is covered by Bouncy Castle only, because no maintained pure-Python implementation was available to pin. That narrower base is stated in the document rather than averaged into a headline number. And the test material is derived from published labels rather than shipped as opaque fixtures, so a third party can recompute the seeds and rerun the whole matrix without trusting anything in the repository.

6. Proof four: it is signing real documents, and you can check today's

Conformance tests prove a library is correct. They do not prove anyone is using it. This is where most infrastructure stories go quiet.

The article you are reading is signed with this stack, and so is every other published article on Live Trading News. Each page emits its cryptographic metadata as structured data, and you can read it with curl and grep. Spot-check any three and the same six fields come back.

Take a published piece from June. Its page declares a signature algorithm of ML-DSA-65, a signing key identifier of 6b8e4750027cfe89, an envelope digest of 2924ff15dbc0ab1f390461a86a70c05058ca20d97a5a6a981eb439ed6a8a6103, a chain transaction hash of 0x30658fc5dd924ef44f4b6ab3581b8b5a03ccfd4a7f828c4fcaacc7d2bc3b25c6, and a block number of 90557.

Now ask the chain. A single JSON-RPC call to chain.kxco.ai/rpc returns that transaction. It is in block 90557, which matches. It is on chain 1111111, which is Armature. It was mined at 13:36:49 UTC on 14 June 2026. Its input is 164 bytes.

And here is the join that turns four separate facts into one piece of evidence. The signing key identifier printed on the article page appears in that transaction's calldata at byte offset 4. The envelope digest printed on the article page appears at byte offset 37. The page says what it signed. The chain says when. Neither can be changed without the other disagreeing, and the disagreement would be public.

This is what the difference between a demonstration and a deployment looks like. Nobody set that transaction up for this article. It has been sitting in block 90557 since June, alongside every other publish.

Change an article and the record does not quietly update. The text is re-signed, re-anchored, and the chain time moves, so the original and the revision both stand on the public record with their own verifiable dates. Verification needs no permission from us and no trust in us.

For counterparties who want to check signatures without installing anything, verify.kxco.ai runs the verifier entirely client-side in the browser.

7. What it costs, including the number most vendors would hide

Cryptography that is correct but too slow to use is a research result, not infrastructure. So the package publishes latency, and it publishes it as tail latency rather than as a mean, because a mean hides the tail and the tail is what a request budget has to absorb.

ML-KEM is sub-millisecond at the median across all three parameter sets. Key encapsulation at Category 3 costs 0.82 milliseconds. Moving up to Category 5 costs well under a millisecond more, which means the real cost of the stronger parameter set is its 1,568-byte keys, not its speed.

ML-DSA signing has a long tail, and the document says so plainly. ML-DSA-65 signs in 11.3 milliseconds at the median and 51.1 milliseconds at the 99th percentile, a factor of 4.5. That is not measurement noise. ML-DSA uses rejection sampling, so signing loops until the candidate falls in range, and an unlucky signature does several more rounds. Anyone who sizes a timeout from the median will size it wrong.

Then there is the number a marketing department would delete. SLH-DSA-SHA2-192s, the hash-based signature set the package wraps, signs in about 6.8 seconds. Not milliseconds. Seconds.

That number is published, in a table, with a note explaining that it is therefore not a per-request operation and suits infrequent high-value signatures such as firmware or root attestations. Verification of the same signature costs about 5 milliseconds, so it is expensive to create and cheap to check, which is exactly the shape you want for a root of trust.

I include it here for the same reason it is in the documentation. A performance table with no ugly numbers in it has been edited.

8. What is not claimed, including one retraction

Over-claiming is the fastest way to lose an institutional buyer, because the person evaluating you is paid to find the gap between your claim and your evidence. So the package ships a threat model and an audit posture whose job is to state the boundary.

There has been no third-party audit of this library. The audit document says so in its first line, and adds that it exists to make the posture legible so the right questions get asked of the right party. The upstream primitives it wraps, @noble/post-quantum, have also not been independently audited; the maintainer has self-audited, and that is what is cited.

That document also contains a retraction, and I want to put it in an article rather than leave it in a file. Earlier releases of the audit posture cited a 2024 Cure53 audit of @noble/post-quantum. That citation was wrong. Cure53's 2023 engagement covered @noble/ciphers, @noble/curves and @noble/hashes, and not the post-quantum package. The document was rewritten to say so, the correction is dated and versioned, and no code path changed because it was a documentation error rather than an implementation one.

A vendor that has never published a correction has either never made a mistake or does not tell you about them. The second is far more common. The reason I am pointing at ours is that a public, dated, self-inflicted retraction is stronger evidence of how a thing is built than any positive claim in the same document.

The rest of the boundary, stated as the threat model states it:

• Not constant-time in general. The library gives you correct, conformant ML-KEM, ML-DSA and SLH-DSA. It does not give you resistance to an attacker who can measure the machine while it runs. One specific property is asserted: kidEquals compares key fingerprints without an early return, so it does not leak how many leading bytes matched. That is an achievable property for a fixed-length comparison in JavaScript. It is not a claim that the wider code is constant-time, and the document says explicitly not to read the first statement as implying the second.

• Side-channel protection for long-lived signing keys is a deployment responsibility, not a library guarantee. If your threat model includes an attacker who can measure timing, cache or power, the key belongs behind a hardware boundary. That is what kxco-pq-hsm is for.

• FIPS 140-3 module validation is not claimed. Algorithm-level conformance evidence and a validated cryptographic module are two different things, and the document refuses to blur them.

• CNSA 2.0 compliance is not claimed. The Category 5 parameter sets that CNSA 2.0 specifies for national security systems, ML-DSA-87 and ML-KEM-1024, are available in the package, and they pass NIST's vectors. Compliance itself is a property of a whole system rather than of a function, so having the parameters available is not the same as being compliant. The package defaults to Category 3.

• An attacker with code execution in your process is out of scope, and best-effort key zeroization does not change that.

9. Why any of this is worth money

Being early in a standards transition costs something. You maintain a library while the surrounding ecosystem is thin, you write documentation answering questions most developers have not asked, and your download counts stay small for a while. The commercially rational move is usually to wait, then publish something more polished into a bigger market.

The reason not to wait is procurement. The deadlines are set and they are not negotiable by anyone selling software.

The threat that makes those dates real does not require a quantum computer to exist yet. It is called harvest now, decrypt later: an adversary records encrypted traffic today and stores it until the machine arrives. Anything with a long confidentiality requirement, medical records, long-lived financial contracts, government archives, is already exposed under that model. Signatures face a different clock: the day classical signatures can be forged, every system still relying on RSA or elliptic curve signatures alone becomes vulnerable to impersonation.

Institutions cannot start that migration when the deadline arrives, because migration takes years. And by the time a regulated entity writes a formal requirement for quantum-resistant signing, the libraries it will use have already been evaluated, tested and in many cases written into reference architectures. Arriving after that evaluation window closes is more expensive than arriving early with a deliberately modest package.

The market is moving on the same clock. $GOOGL has said post-quantum cryptography will be integrated into Tensor G6 and Titan M3 silicon in the Pixel 11, which puts these algorithms in consumer hardware rather than in a standards document. On the hardware side of the same story, $IBM is targeting fault tolerance by 2029 with its Nighthawk processor, and $QBTS moved a second production quantum application onto a national mobile network this month. None of that says a codebreaking machine is imminent. All of it says the transition has a schedule.

10. The download numbers, and why they are the weakest evidence here

Across the fourteen packages, npm recorded 32,623 downloads between 18 May and 22 August 2026. The base package accounts for 6,557 of those. The last seven days brought 5,838 across the family and 867 for kxco-post-quantum.

Now the honest reading, because I would rather give it than have someone else find it. That series is lumpy, and its peaks line up with our own release dates. A meaningful share of it is continuous integration installing our packages into each other, plus registry mirrors. The launch weeks in late May are the largest in the whole series, which is what publication activity looks like, not what adoption looks like.

So treat the download curve as the weakest evidence in this article. It shows the packages are being fetched and that the release cadence is real. It does not prove a stranger is depending on them in production, and any vendor presenting a curve like this as adoption is asking you not to look closely.

The stronger signals are the ones in sections 3 through 6, and they are stronger precisely because they do not depend on our own reporting. A provenance attestation is issued by GitHub and served by npm. A NIST vector either matches or it does not. Bouncy Castle either verifies our signature or it does not. A transaction is either in block 90557 or it is not. None of those four facts is ours to adjust.

11. Who does what

A word on how this gets built, because it bears on whether you should believe any of it.

I set the requirements. I decide which problems are worth solving, which standards are mature enough to bet institutional credibility on, what the documentation standard is, and that the base layer ships under an open licence so counterparties can verify rather than trust. I do not write the constant-time comparison routines and I do not run the conformance suite at three in the morning. Those belong to engineers who are better at them than I am.

That division is deliberate rather than modest. Cryptographic engineering needs a kind of sustained attention to a narrow surface that is incompatible with the breadth needed to design a stack spanning identity, attestation, encrypted channels, audit logs and settlement. Attempting both usually produces mediocre versions of each.

It is also why the documentation looks the way it does. The reader I care about is not the developer who wants to install something in five minutes. It is the internal security team, the external auditor, or the regulated counterparty whose job is to say no. That reader needs the threat model, the non-claims, the conformance evidence and the reproduction commands. Give them a marketing page and they say no, correctly. Give them the evidence and the answer becomes a technical question with a technical answer.

12. What would falsify all of this

The test of an evidence-based claim is whether it can be broken. Four things would break the argument above, and I would rather name them than wait for someone else to.

If `npm audit signatures` failed on the base package, the link between our published source and our shipped binary would be gone, and every downstream claim would rest on trust again.

If a NIST vector failed rather than being refused, the mathematics would be wrong, and no amount of documentation discipline would matter.

If Bouncy Castle rejected a signature we produced, or produced one we rejected, the interoperability claim would collapse and the package would be a private dialect rather than an implementation of a standard.

If the calldata in block 90557 did not contain the digest printed on the article page, the anchoring would be theatre.

All four are checkable today by someone with a terminal and no relationship with us. That is the entire design.

The honest summary is narrower than a press release and more useful. Fourteen packages are published and versioned. The base layer is provably built from its stated source. It matches NIST's vectors 1,793 times with zero failures and refuses 310 cases it considers unsafe to sign. It interoperates in both directions with two independent implementations, negative controls included. It signs live documents whose signatures are anchored in public blocks. It has no third-party audit, does not claim FIPS 140-3 validation or CNSA 2.0 compliance, is not constant-time in general, and has published a correction to its own audit citation.

That is not the most exciting set of sentences available. It is the set that survives contact with someone whose job is to find the gap.

Stocks mentioned in this article: $GOOGL, $IBM and $QBTS.

Shayne Heffernan, Ph.D., is the founder of Live Trading News, the KnightsBridge Group, Knightsbridge Law and the KXCO.ai ecosystem spanning post-quantum cryptography, identity, attestation and enterprise ontology.

This article explains method and evidence. It is not investment advice and it is not a security assessment of your systems. Cryptographic choices carry operational and regulatory consequences, and independent review is always required. All package versions, download figures, conformance results and chain data were read from public endpoints on 23 August 2026 and will move as new versions ship.

Sources

1. kxco-post-quantum on npm, version 1.4.0, with README, CONFORMANCE.md, THREAT-MODEL.md, AUDIT.md, MIGRATION.md and SECURITY.md: npmjs.com/package/kxco-post-quantum

2. The full package family under the kxco account: npmjs.com/~kxco

3. SLSA provenance attestation for [email protected], served by the npm registry: registry.npmjs.org/-/npm/v1/attestations/[email protected]

4. Download statistics from the npm registry API, 18 May to 22 August 2026: api.npmjs.org/downloads

5. NIST ACVP test vectors, usnistgov/ACVP-Server at commit 975de31e: github.com/usnistgov/ACVP-Server

6. NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, August 2024: nvlpubs.nist.gov

7. NIST FIPS 204, Module-Lattice-Based Digital Signature Standard, August 2024: nvlpubs.nist.gov

8. NIST FIPS 205, Stateless Hash-Based Digital Signature Standard, August 2024: nvlpubs.nist.gov

9. NSA CNSA 2.0 transition timeline: nsa.gov

10. Bouncy Castle bcprov-jdk18on 1.85.2, the Java peer used in the interoperability matrix: bouncycastle.org

11. @noble/post-quantum, the upstream primitive library, and its maintainer self-audit: github.com/paulmillr/noble-post-quantum

12. Armature L1 JSON-RPC endpoint used to confirm transaction 0x30658fc5 in block 90557: https://chain.kxco.ai/rpc

13. Client-side signature verifier: verify.kxco.ai