Post-quantum receipts: a field guide to ML-DSA-65 evidence

A post-quantum receipt is the cryptographic record of an AI transaction, signed with NIST-standard post-quantum algorithms so the evidence trail remains valid after the arrival of a cryptographically relevant quantum computer. This page is the working reference for how Hive constructs, signs, and verifies them.

Why receipts go post-quantum

Most regulated AI transactions today are receipted with classical signatures: ECDSA over P-256, RSA-2048, or Ed25519. Those are durable against today's adversaries but every one of them breaks under Shor's algorithm running on a sufficiently large quantum computer. NIST and the U.S. government now treat that arrival as a planning-horizon event, not a theoretical one.

The threat model that matters is harvest-now-decrypt-later: an adversary collects encrypted traffic and signed evidence today and decrypts or forges it once a quantum computer is available. A receipt issued in 2026 may need to be defensible in 2036. If its signature uses a primitive that has been broken in the interim, the entire evidence trail is suspect.

Post-quantum signatures fix this. Hive-PQ receipts use ML-DSA-65, the lattice-based signature scheme NIST standardized as FIPS 204 in August 2024. Each receipt also carries a ML-KEM-768 ciphertext (FIPS 203) so any encrypted artifacts bound to the receipt are protected by the same post-quantum margin.

The receipt envelope

A Hive receipt is a canonical JSON envelope with the following required fields:

The dual signature — classical Ed25519 plus post-quantum ML-DSA-65 — is deliberate. It lets receipts be verified by classical-only consumers today while remaining defensible after migration. We call this the crypto-agile receipt envelope.

Signing — ML-DSA-65 (FIPS 204)

ML-DSA-65 is a module-lattice signature scheme. Its claimed security level is NIST Category 3 — roughly equivalent to AES-192 against quantum adversaries. Public keys are 1952 bytes, signatures are 3309 bytes. The signing operation takes about 0.4 ms on a modern CPU and verification about 0.2 ms.

For Hive receipts the signing surface is the canonical CBOR encoding of the envelope minus the sig_dsa and sig_classical fields. We define canonical encoding strictly to avoid signature non-determinism: keys are sorted lexicographically, integers use shortest-form encoding, and floats are forbidden.

Key encapsulation — ML-KEM-768 (FIPS 203)

ML-KEM-768 is the post-quantum key-encapsulation mechanism Hive uses for receipt-bound payloads. Its NIST Category 3 parameters give a 1184-byte public key and 1088-byte ciphertext. Encapsulation produces a 32-byte shared secret which Hive uses as a symmetric key for any AES-256-GCM payload bound to the receipt.

For receipts that do not carry an encrypted payload, the kem_ct field is still populated against a per-issuer KEM key. This serves as a forward-secrecy beacon: if the issuer rotates its KEM key, all prior receipts retain their signatures but new bindings cannot be forged.

MAPET physical-entropy seeding

Algorithmic randomness is not enough for sovereign-grade evidence. Hive's MAPET (Multi-Axis Physical Entropy Tabulation) protocol pulls entropy from a quorum of physical sources — radio-frequency noise, hardware photodiode jitter, accelerometer fluctuation — and aggregates them into the mapet_seed field. The standard Wave-Lattice profile uses six axes; the cosmic RogueWave-Lattice profile uses sixteen.

The point is not the randomness itself — ML-DSA-65 is fine with a CSPRNG seed — but the auditable provenance of the randomness. Regulators want evidence that the receipt was not generated against a manipulated entropy stream. The MAPET seed is logged to a public consensus surface and can be replayed against the validator timestamps recorded in the receipt.

Offline verification

Every Hive receipt is verifiable offline against the reference verifier. The verifier is open-source, deterministic, and ships as a single-binary CLI:

$ hive-verify receipt.json
profile         : pq
sig_classical   : OK (Ed25519)
sig_dsa         : OK (ML-DSA-65, FIPS 204)
kem_binding     : OK (ML-KEM-768, FIPS 203)
mapet_quorum    : OK (6 of 6 axes, validators a1..a6)
settlement      : OK (Base 8453 tx 0x9f3a...)
freshness       : OK (issued 2026-05-07T13:08Z, age 4m 12s)

The verifier has no network dependencies. It reads the receipt envelope, the issuer's published ML-DSA-65 public key, and (for the kem_binding check) the issuer's ML-KEM-768 public key. Both keys can be cached.

EU AI Act and NIST alignment

Article 12 of the EU AI Act requires high-risk AI systems to maintain automatic logs sufficient to retrace operation. Article 13 requires transparency about system capabilities. Article 15 requires accuracy, robustness, and cybersecurity. A post-quantum receipt is a single artifact that can satisfy all three: a tamper-evident log entry that retraces the transaction, declares the operating profile, and is signed with a primitive whose security margin is anchored to NIST-published standards.

For U.S. regulated workloads, Hive receipts use only NIST-published primitives (FIPS 203, FIPS 204, AES-256-GCM, SHA-256), which keeps the evidence trail aligned with FedRAMP cryptographic baselines and Treasury FSOC guidance on AI in financial services.

Pricing

Hive prices the receipt, not the seat. Per-call profiles are settled in USDC on Base 8453. There is no subscription floor.