A Real QuantumTransmission™ Certificate
Not a mockup, not a diagram — one real file, moved end to end, cryptographically bound and anchored to consensus, then put through an actual tamper attempt, shown here with its own signed evidence so you can check it yourself.
One real file. One real chain. One real attempt to break it.
A certificate shouldn’t ask you to trust the storage. It should show you the chain — and let someone try to break it.
On 2026-08-31, a real 1.75 MB PDF was moved through the QuantumTransmission™ gateway, sealed, and anchored to consensus. Two days later, as part of this certificate’s own evidence, we took a real record from its audit chain and tried to forge it — in memory only, nothing written — to see whether the chain would notice. What follows is that transmission’s own evidence, restyled for reading rather than for printing.
Self-attested · not a third-party audit opinion · not a CMVP / FIPS 140-3 validated module. On this specific preview build, the key-exchange layer (ML-KEM) is enforced and live; the per-file signature (ML-DSA) and archival seal (SLH-DSA) are explicitly pending, not silently skipped — see Post-quantum defense in depth below.
Every field below is read from this transmission’s own signed evidence.
This is one real file movement, identified by its own transmission ID and content hashes — not a synthetic example.
mid-year-market-outlook-2026.pdf — 1,834,143 bytes (1.75 MB)C12-PQC-06G-UPLOAD-PREVIEW-20260831T212007ZC12-PQC-06G-UPLOAD-PREVIEW-20260831T212007Z-SESSION, gateway-attestedPackage: 3dd10f80fdac2f5753cf6920847032b562126724700b68975386da030c8a2dd8678cf04f9d070b8965f47ff9f74bff4b1d49a8da4242ce20eb60935349c7f589
Payload: a68f10c8d6aea1f50a6b054dcdb46aee442793c7eb9e6082fa8e89dcb9b9dbd137a4afc8d07e8ab0ae0ecaaf9f94215d043a2d52d0e8cc1a73d09a4b496919af
Every field above is copied straight from the certificate’s own record. Don’t take that on faith — open the certificate itself and match them.
Open the Live Certificate & Verify →Three layers, named honestly — one live, two still pending on this build.
Key exchange, per-file signature, and archival seal are three separate jobs. On this specific preview build, only the first is measured and enforced per transmission — the other two are shown as pending, not silently upgraded to sound finished.
ML-KEM-1024 (FIPS 203) — suite-enforced at the gateway, live on this transmission, no fallback path.
ML-DSA (FIPS 204) — not computed for this preview build. Named as pending, not claimed as done.
SLH-DSA (FIPS 205) — pending seal on this preview build. The key-release decision below is sealed separately, with SLH-DSA, today.
This is the same self-attested-today, roadmap-tomorrow line drawn everywhere else on this site — see the full algorithm-by-algorithm status at Algorithm Profile →
This file never left the zone it was told to stay in.
Every transmission carries its own residency and export decision, not a policy applied after the fact.
UK-SOV-01COVALENCE-UK-SOVEREIGN-BCX-V1For an institution with data-localization or cross-border transfer obligations, this is the part that usually decides the conversation before the cryptography does.
This transmission’s real finality block — not an illustration.
The residency decision and the file movement above don’t stand on a single signature. They were attested by an independent ten-validator committee and finalized as a specific, numbered consensus block.
covalent-cluster-01 — checkpoint block #152020For how consensus and validator quorum work in full, see NSQC™ Consensus →
A chain doesn’t have to be unbreakable to be trustworthy. It has to be impossible to break quietly.
As part of this certificate, we ran a real forgery attempt against this transmission’s own audit record — in memory only, nothing written to the live chain — and re-verified the hash chain afterward.
movement_committedfalse → forged to trueThe storage layer itself accepted 4 of 4 real test mutations against a sacrificial file — overwrite, append, atomic replace, and unlink all succeeded. Immutability here is not enforced by the filesystem. What protects the evidence is the hash chain: every record commits to its predecessor’s digest, so an edit is detectable, not impossible. That distinction is the whole claim — we are not asking you to believe the storage can’t be written to, only that if it is, the chain will show it.
The gate between a sealed file and a readable one.
Encrypting a file is only half of custody. The other half is deciding, and recording, exactly when and why the key that unlocks it is released.
AUTO_APPROVED_PREVIEWOPTION_B_CQV_ESCROW — the Covalence Quantum Vault holds escrowcqv:v1:auditor:v3_key_release:slhdsa128f:1, at 2026-09-02 20:45:33 UTCZero trust in us — the chain is meant to be checked, not taken on faith.
41923389853e2a78db37966becc1ddf10deabf7ceb2f887a2b6fbbad67ac5ea7
“A verified chain proves an edit would be DETECTED, not that an edit is impossible: the storage layer under this chain accepted 4 of 4 test mutations against a sacrificial file. Self-attested; the SLH-DSA seal over each decision is the FIPS-205 algorithm in software custody, not a CMVP-validated module.”
See Claims & Boundaries → for the full public-language limits, and the Evidence Pack Schema → for the auditor-facing verification model this certificate is built from.