A Real QuantumHandshake™ Certificate
Not a mockup, not a diagram — one real, live session, cryptographically sealed and anchored to consensus, shown here with its own signed evidence so you can check it yourself.
This isn’t a mockup. It’s one real session, sealed and shown in full.
A certificate shouldn’t ask you to take our word for it. It should give you a hash, a public key, and a way to check.
On 2026‑09‑03, a real session was established against a live gateway at quantumbank.live. QuantumHandshake™ negotiated a post-quantum channel, evaluated trust, signed the decision, and anchored it into consensus. What follows on this page is that session’s own evidence — the same fields the certificate itself carries, restyled for reading rather than for printing.
Self-attested · not a third-party audit opinion · not a CMVP / FIPS 140-3 validated module. The cryptography is genuine NIST post-quantum work, run and sealed by us. Independent validation is the next step, not a claim we are making today — see Verify it yourself below.
Every field below is read from this session’s own signed evidence.
Wallet addresses and session identifiers are shown the same way the certificate itself displays them — shortened for reading, not truncated for concealment.
quantumbank.live0x988146…556f1bC0F73AC4…830A46DCBA-150825-quantumbank.live-gateway-8A2DD0C48B9C41c6a88f61a66bcb3029bf3d9f3a7191b6686b754820dadfc318f9c046e17d96
Computed over the canonical session evidence — ID, session, trust result, cryptographic posture, anchors, and finality — then sealed with a FIPS-205 SLH-DSA signature so the digest itself can’t be swapped after the fact.
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 independent NIST-standard layers, not one algorithm doing everything.
Key exchange, session signatures, and evidence sealing are three separate cryptographic jobs in this session — each one covered by its own post-quantum algorithm, so a weakness in one layer doesn’t undo the other two.
Kyber-1024 + ChaCha20-Poly1305 — ML-KEM family (FIPS 203). Suite-enforced at the gateway with no fallback: every session in this configuration negotiates the same post-quantum profile, not a legacy option offered alongside it.
ML-DSA / Dilithium-compatible — measured for this exact session and signed by the BCQP gateway itself, binding the trust decision to a specific, non-reusable signature.
SLH-DSA-SHA2-128f (FIPS-205) — a hash-based post-quantum seal over the SHA-256 content digest, signed by the Covalence Quantum Vault on request. The private key is never released to this process.
An adversary can record today’s encrypted traffic and decrypt it years later once a quantum computer exists. This session is protected with NIST post-quantum standards, so the recording stays useless — the confidentiality and the signatures survive the quantum transition. For the full picture of this threat, see the HNDL explainer →
Six steps, each one leaving its own signed trace.
This is the same sequence the certificate’s own session-replay timeline walks through — shown here as a straight read, step by step, with this session’s real numbers.
Handshake
A post-quantum key exchange (Kyber-1024) establishes the encrypted channel. Round-trip: 4.55 ms.
Session DNA
The session is fingerprinted into a content-addressed hash (98b1e1df…d77fe6) that every later step references back to.
Trust decision
Identity, policy, and cryptographic posture are evaluated together. Result: ALLOW, in 120.51 ms.
State signature
The gateway signs the trust decision with an ML-DSA/Dilithium-compatible key, measured for this exact session — not a static, reused signature.
DCBA anchor
The signed decision is anchored into the ledger as DCBA-150825-quantumbank.live-gateway-8A2DD0C48B9C.
Consensus finality
A ten-validator quorum attests the anchor block: 10 of 10 signed, against a floor of 7. NSQC™ block #152055, finalized.
This session’s real finality block — not an illustration.
The trust decision above doesn’t stand on its own signature alone. It was attested by an independent ten-validator committee and finalized as a specific, numbered consensus block.
covalent-cluster-01 — checkpoint block #152055150801-150900.jsonFor how consensus and validator quorum work in full, see NSQC™ Consensus →
The same session, run on yesterday’s cryptography.
This isn’t a hypothetical comparison — it’s the algorithm choice actually enforced on this session, set against what a conventional gateway would have used instead.
Legacy cryptography
- RSA-2048 / ECDH / ECDSA.
- Harvestable today, decryptable later.
- Breaks under Shor’s algorithm once a cryptographically relevant quantum computer exists.
- Not used anywhere in this session.
This session’s actual profile
- ML-KEM (Kyber-1024) · ML-DSA · SLH-DSA.
- FIPS 203 / 204 / 205.
- Quantum-resistant key exchange, signatures, and evidence seal.
- Enforced by the gateway, with no fallback path.
Zero trust in us — the evidence is meant to be checked, not taken on faith.
Evidence assembled from the anchored BCQP-TX-v1 gateway record for this session, plus live NSQC finality posture. Two scope notes worth stating plainly, in the same language the certificate itself carries:
Self-attested · not a third-party audit opinion · not a CMVP / FIPS 140-3 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.