Post-Quantum Receipt Re-Anchoring

A receipt does not carry your document. It carries a fixed-size SHA-256 digest of the exact bytes that mattered, plus a signature over that digest.

The estate canonicalizes the {policy_parameters, output_payload} pair, hashes the canonical bytes with SHA-256, and places an Ed25519 proof inside audit_signature.proof. The signature is over SHA-256(proofOptions) || SHA-256(document), so it binds both the signing method and the bytes. This is a real property of receipts the estate produces today; the receipt verifier tool linked in the closing panel re-derives the digest client-side and checks the Ed25519 proof against it.

Ed25519 rests on the elliptic-curve discrete-log problem. A sufficiently large quantum computer runs Shor's algorithm against exactly that problem, and it does not matter that the signature was made years earlier.

The attack is retroactive. An attacker who recorded a receipt today gains nothing until a cryptographically relevant quantum computer exists, and then can forge an Ed25519 proof over modified bytes that no classical verifier of that era can distinguish from the original. Long-lived attestations such as compliance records, provenance chains and archival receipts are exactly the targets, because their value outlives the signature scheme they were signed with.

Re-anchoring appends a second, independent proof to audit_signature.proof. The original receipt bytes, the original digest, and every existing proof are never touched.

Each appended proof signs the identical SHA-256(proofOptions) || SHA-256(document) bytes the Ed25519 proof signs: same pipeline, second cryptosuite. The existing proof chaining already supports proof sets, so no new primitive is needed. Key generation for the second signature happens in your browser, the secret key lives in the tab for the session only, and if you refresh or close the tab it is gone forever with no recovery. The live re-anchor tool linked in the closing panel does the whole round trip as paste in, compute, download out, with nothing retained.

The estate's re-anchor path carries two post-quantum signatures, and each rests on a different mathematical assumption. Naming both matters: a future re-anchor to the other algorithm is then legible as the expected second half of what this page already described.

Hash-based SLH-DSA is the conservative choice: its security reduces to the hash function the estate already trusts everywhere else. Lattice-based ML-DSA-65 is the standards workhorse with smaller signatures. Carrying both in one proof set means the artifact layer stays verifiable even if one assumption ages badly.

The answer has three tiers, and collapsing any of them into the others would overstate or understate the truth. Unqualified phrases like "quantum-safe receipts" are avoided on this page by design.

1. Hash binding: yes. SHA-256, used throughout for canonicalization and digesting, has no known quantum break that threatens preimage or collision resistance at current parameter sizes. Grover's algorithm only halves the effective security margin, which SHA-256 already absorbs.
2. The Groth16 seal: no. Any zkVM-sealed receipt's proof rests on a BN254 pairing and a trusted setup, and both are broken by a sufficiently large quantum computer via Shor's algorithm against the underlying elliptic-curve discrete-log problem. Re-anchoring does not touch, re-seal, or claim to fix that layer.
3. The artifact-layer mitigation: what the second signature is and is not. The appended SLH-DSA and ML-DSA proofs add a second, independent, post-quantum-resistant attestation of the artifact, alongside the seal. They do not, and cannot, make the seal itself quantum-resistant.

Read the ordering from the bottom of the stack up: the digest layer holds, the sealing layer does not, and the re-anchor path hardens the artifact layer only. Any page or tool that offers a single-word answer to the quantum question is skipping at least one of these tiers.

One receipt, two verification surfaces: the classical leg and the post-quantum legs are both live estate tools you can open right now. Both are tagged on this page as what the estate does today, not as a design sketch.