]> Vauban Research

research@vauban.tech https://pay.vauban.tech

Applications Independent Submission x402 HTTP payment receipt post-quantum PQC cryptographic hash-based STARK ML-DSA FIPS 204 hybrid signature migration eIDAS ANSSI This document specifies a post-quantum cryptographic discipline for x402 STARK receipts. The discipline applies on two layers : (a) proof integrity via hash-based proving systems (the Stwo Circle STARK M31 reference implementation), which are post-quantum sound under standard cryptanalytic assumptions, and (b) signature integrity via the hybrid ES256K + ML-DSA-65 dual-signed receipt variant (). It maps the hybrid-pqc receipt variant of the x402 STARK Receipt Format Extension () to the NIST PQC migration roadmap and to the EU eIDAS 2.0, ANSSI, and BSI migration timelines for the 2025-2030 window. Reference runners are published as the vauban-x402-jcs-conformance and vauban-x402-canonical Rust crates. Companion documents are (receipt format) and (composability grammar).

Introduction Classical payment receipts signed under elliptic-curve schemes such as ES256K become forgeable under a sufficiently capable quantum adversary. The base x402 PAYMENT-RESPONSE () uses ES256K as its default signature scheme. Under the present specification, a PAYMENT-RESPONSE retained for audit purposes in year N is verifiable today, but its long-term integrity depends on the absence of a quantum computer capable of executing Shor's algorithm against secp256k1. NIST timelines (), ANSSI guidance (), and BSI guidance () converge on a 2030-2035 horizon for the migration of high-value or long-retention cryptographic material away from classical-only signatures. This document defines a two-axis post-quantum cryptographic discipline for x402 receipts that addresses the long-term integrity gap. The first axis applies at the proof-system layer : the stark-vauban-pay-v1 variant of uses Stwo Circle STARK M31 (), a hash-based proving system whose soundness rests on the collision and second-preimage resistance of cryptographic hash functions rather than on algebraic hardness assumptions broken by Shor's algorithm. The second axis applies at the signature layer : the hybrid-pqc variant of composes ES256K and ML-DSA-65 () signatures over the identical JCS canonical preimage, producing a receipt that remains verifiable if either single algorithm is broken. This document positions the discipline as the recommended profile for x402 deployments that operate under statutory retention obligations (for example, MiCA Art. 80 or EU AI Act Art. 12 transparency-and-documentation duties). The discipline does not modify the wire format defined in or the composability grammar defined in ; it constrains the choice of cryptographic primitives and the negotiation discipline that producers and verifiers SHOULD apply to satisfy post-quantum soundness for the 2025-2030 migration window and beyond. This document is an Independent Submission. It is not the product of an IETF Working Group. It is published for community review and to establish a stable reference for implementors.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

Post-Quantum Sound:

A cryptographic construction whose security holds against an adversary in possession of a large-scale quantum computer (specifically, an adversary capable of executing Shor's algorithm against discrete logarithm and integer factorisation problems, and Grover's algorithm against unstructured search). A construction is post-quantum sound if no known quantum algorithm reduces its security below an operationally acceptable level. SHA-256, as used in hash-based proving systems, is post-quantum sound at 128-bit security under Grover (which provides at most a quadratic speedup against generic preimage search).

Hash-Based Proof System:

A succinct proof system whose soundness reduces to the collision and second-preimage resistance of an underlying cryptographic hash function rather than to algebraic assumptions (pairings, discrete logarithms, factorisation). STARK proof systems are hash-based. SNARK proof systems based on pairings (BN254, BLS12-381) are not hash-based.

ML-DSA:

Module-Lattice-Based Digital Signature Algorithm, standardised in . This document references the ML-DSA-65 parameter set, which provides 192-bit classical security and an estimated 128-bit security against quantum adversaries per NIST's category-3 classification.

Hybrid Signature:

A composite signature scheme that produces two or more independent signatures over the same canonical message under disjoint cryptographic assumptions. A hybrid signature is valid if and only if every component signature verifies independently. The hybrid construction is secure against an adversary that breaks any proper subset of the component schemes.

Migration Window:

The temporal interval between the publication of post-quantum standards (NIST FIPS 204, August 2024) and the deprecation of classical-only signatures under applicable regulatory frameworks. For this document, the migration window spans 2025 to 2030, with deprecation horizons varying by jurisdiction.

Backwards Compatibility:

The property that a receipt produced under this discipline is verifiable by an implementation that supports only classical primitives, provided the classical component of the receipt is well-formed and independently verifiable. The hybrid receipt variant satisfies backwards compatibility ; the STARK proof system at the proof layer is independent of signature backwards compatibility.

Threat Model : Quantum Adversary

Assumed Capability The threat model assumes an adversary in possession of a large-scale, fault-tolerant quantum computer capable of executing Shor's algorithm against classical public-key primitives and Grover's algorithm against unstructured search problems. The timeline for the availability of such a machine is uncertain ; NIST guidance () and ANSSI guidance () recommend migration planning for high-value or long-retention cryptographic material on a 2030-2035 horizon, with concrete migration steps starting in 2025. The adversary is assumed to have : Access to public-key material (signature verification keys) for all receipts ever published. The ability to record receipts in transit and at rest indefinitely (the "harvest-now-decrypt-later" assumption). No access to private signing material held by facilitators ; key compromise is treated separately in .

Receipt Forgery Vectors Three forgery vectors are relevant for x402 receipts under the quantum threat model :

ES256K Signature Break ES256K signatures are based on the discrete logarithm problem over the secp256k1 elliptic curve. Shor's algorithm reduces the discrete logarithm problem to polynomial time on a quantum computer. An adversary with a sufficiently large quantum computer can recover the private signing key from the public verification key, and thereafter forge arbitrary receipts under the compromised key. This vector affects every receipt signed under ES256K, retroactively, once the adversary's quantum capability becomes available.

Hash Collision Under Grover The JCS canonical preimage discipline () and the receipt content addressing in both rely on SHA-256. Grover's algorithm provides at most a quadratic speedup against unstructured search, reducing the effective security of a 256-bit hash output from 128 bits classical to 128 bits quantum against second-preimage attack. SHA-256 therefore remains post-quantum sound at the 128-bit security level for the use cases of this document (preimage chaining and content addressing). No mitigation is required at the hash layer for the receipt formats specified in .

Algebraic Proof System Soundness Break SNARK proof systems whose soundness rests on bilinear pairings (BN254, BLS12-381, or equivalent) are vulnerable to Shor's algorithm in the same manner as ES256K : the underlying discrete-logarithm hardness assumption is broken. A SNARK-based receipt becomes forgeable once the adversary can recover trapdoor material from the proving key. This vector does not affect STARK proof systems, which rely only on hash-function security.

Out-of-Scope Threats The following threats are out of scope for this document : Key encapsulation mechanism analysis ; ML-KEM () is treated in the NIST guidance but does not apply to receipt signature integrity. Quantum-secure channel establishment (TLS, x402 transport layer) ; this document concerns receipt integrity at rest, not transport. Side-channel attacks against signing implementations ; see for hardening guidance specific to constant-time ML-DSA-65 implementations.

Two-Axis PQC Discipline The post-quantum cryptographic discipline for x402 STARK receipts operates on two orthogonal layers. A deployment selects one or both axes based on its threat model and regulatory environment.

Proof System Layer

Hash-Based Proving Requirement The proof system underlying a receipt variant MUST be hash-based for the variant to be considered post-quantum sound at the proof layer. The stark-vauban-pay-v1 variant of satisfies this requirement by using the Stwo Circle STARK M31 prover (). Stwo Circle STARKs construct succinct proofs from Merkle commitments and a hash-based polynomial-IOP transformation ; the soundness reduction relies on the collision and second-preimage resistance of the underlying hash function (Blake2s in the Stwo reference implementation), neither of which is broken by Shor's algorithm.

Forbidden Proof System Families Implementations claiming post-quantum soundness at the proof layer MUST NOT use any of the following proof system families : Groth16, PLONK, or any SNARK construction based on bilinear pairings over BN254, BLS12-381, or equivalent curves. Bulletproofs or any range proof construction whose soundness reduces to the discrete logarithm problem. Any proof system whose security analysis explicitly invokes the algebraic group model or generic group model without additional hash-based safeguards. A facilitator that advertises a stark-vauban-pay-v1-tier receipt MUST in fact use a hash-based proof system. A facilitator that internally uses a pairing-based SNARK and labels the result as a STARK receipt is in violation of this discipline and MUST NOT claim conformance.

Signature Layer

Hybrid Composition Requirement A receipt variant that claims post-quantum soundness at the signature layer MUST carry two independent signatures over the identical JCS canonical preimage () : one classical signature (ES256K) and one post-quantum signature (ML-DSA-65 per ). The hybrid-pqc variant of satisfies this requirement. A verifier processing a hybrid-pqc receipt MUST : Confirm that both signature (ES256K) and pqc_signature (ML-DSA-65) cover the byte-identical JCS canonical preimage. Verify each signature independently against the corresponding public key referenced by kid_es256k and kid_mldsa65. Reject the receipt if either signature fails to verify. A receipt with a valid ES256K signature and an invalid ML-DSA-65 signature MUST be rejected under the hybrid discipline ; partial verification is not equivalent to verification.

Classical Fallback Discipline The classical-es256k variant of carries only an ES256K signature and is NOT post-quantum sound at the signature layer. Deployments operating under statutory retention obligations SHOULD treat the classical-es256k variant as a legacy interop format only, and SHOULD migrate to hybrid-pqc or stark-vauban-pay-v1 before the relevant deprecation horizon. The classical fallback remains valid for non-retention deployments where the threat model permits.

Migration Window Profile During the 2025-2030 migration window, the recommended profile is : For deployments under statutory retention obligations : hybrid-pqc REQUIRED ; classical-es256k rejected for new receipts ; existing classical-es256k receipts re-stamped as hybrid-pqc on first re-presentation to a supervisor (re-stamping mechanism is implementation-specific and out of scope here). For deployments without statutory retention obligations : hybrid-pqc RECOMMENDED ; classical-es256k ACCEPTED for interop with non-PQ-ready counterparties. Post-2030, classical-only signature variants SHOULD be deprecated for new receipt issuance. The exact deprecation date is jurisdiction-dependent and SHOULD follow the applicable NIST, ANSSI, BSI, or eIDAS guidance.

Receipt Format Mapping The two-axis discipline defined in this document maps to the receipt variants of as follows.

Proof System Layer Mapping Variant Proof system Post-quantum sound at proof layer? stark-vauban-pay-v1 Stwo Circle STARK M31 (hash-based) Yes hybrid-pqc None (signature-only variant) Not applicable classical-es256k None (signature-only variant) Not applicable

Signature Layer Mapping Variant Signature scheme Post-quantum sound at signature layer? stark-vauban-pay-v1 Facilitator-specific outer signature Implementation-dependent hybrid-pqc ES256K + ML-DSA-65 (hybrid) Yes classical-es256k ES256K only No The two layers are orthogonal. A stark-vauban-pay-v1 receipt provides proof-layer post-quantum soundness ; if the deployment also requires signature-layer post-quantum soundness for the outer signature, it SHOULD combine the STARK proof with a hybrid signature in the same receipt envelope. This combination is permitted by provided both the proof and the hybrid signature cover the identical canonical preimage.

PQ-Readiness Negotiation The receipt-format negotiation defined in is the carrier for PQ-readiness signalling. A facilitator advertising post-quantum soundness MUST list hybrid-pqc or stark-vauban-pay-v1 (or both) in the X-Payment-Options header. A client requiring post-quantum soundness MUST include receipt_format with required: true in the PAYMENT-SIGNATURE extension, naming the required variant. A facilitator that lists hybrid-pqc in X-Payment-Options but cannot in fact produce a valid ML-DSA-65 signature is in protocol violation. Conformance testing for PQ-readiness SHOULD include emission of a hybrid-pqc receipt and independent verification of both component signatures by a third-party verifier.

NIST PQC Migration Alignment

NIST Migration Roadmap The post-quantum cryptography migration roadmap published by NIST () defines a multi-stage transition from classical public-key primitives to standardised post-quantum primitives. Key milestones relevant to x402 receipt integrity : August 2024 : publication of (ML-DSA), (ML-KEM), and FIPS 205 (SLH-DSA). Implementations may begin production deployment. 2025 : recommended start of hybrid deployment for high-value or long-retention systems. 2030-2035 : recommended completion of migration ; classical-only systems SHOULD be deprecated for new deployments. The hybrid-pqc variant of aligns with the NIST hybrid deployment recommendation. The stark-vauban-pay-v1 variant addresses the proof-system layer in parallel and is independent of the signature migration timeline.

EU and Member State Alignment The EU eIDAS 2.0 regulation () introduces requirements for qualified electronic signature schemes that anticipate the post-quantum transition. National guidance documents from ANSSI () and BSI () publish concrete migration timelines for cryptographic primitives used in regulated sectors. A facilitator operating in an EU jurisdiction SHOULD : Publish a migration plan for ES256K to ML-DSA-65 (or a successor scheme endorsed by the applicable national authority) aligned with the relevant jurisdictional timeline. Issue hybrid-pqc receipts as the default variant for any payment context subject to long-term retention (MiCA Art. 80, AMLR Art. 56, DORA Art. 14, or sector-specific obligations). Document the post-quantum readiness of its receipt infrastructure in its qualified-trust-service-provider attestations where applicable.

NIST SP 800-208 Hybrid Composition Guidance NIST provides hybrid composition guidance for hash-based signature schemes. While SP 800-208 focuses on stateful hash-based signatures (LMS, XMSS), the composition principles for hybrid construction are relevant to the hybrid-pqc variant of . Implementations SHOULD : Compose the two component signatures over the identical canonical message, not over a transformed version of the message. Treat the hybrid signature as a single object for serialisation purposes, with both component signatures present in every well-formed receipt. Reject any receipt where one of the two component signatures is absent, malformed, or fails verification. The composition pattern in the hybrid-pqc variant follows these principles.

Implementation Evidence

Hash-Based Proof System Reference The Stwo Circle STARK M31 prover () is the reference implementation of a hash-based proof system suitable for the stark-vauban-pay-v1 variant of . The prover has been operationally deployed on Starknet mainnet since 2025 and is the proving substrate for the reference deployment documented in (Sepolia demo at demo.pay.vauban.tech). The Vauban Pay reference adapter for Stwo Circle STARK M31 is published as an Apache 2.0 Rust crate within the Vauban zkpay workspace. The adapter exposes a chain-agnostic proof backend interface ; the hash-based property of the underlying proof system is preserved across adapter implementations.

JCS Preimage Discipline Reference The JCS canonical preimage discipline used by all three receipt variants is implemented in the vauban-x402-jcs-conformance Rust crate (). The crate provides conformance vectors and a runner that has been cross-validated byte-identical against four other independent JCS implementations (Python, TypeScript, Go, Java) as documented in . The canonical Claim Algebra encoder used to construct the preimage objects covered by the hybrid signature is implemented in the vauban-x402-canonical crate (). Both crates are published under Apache 2.0 on crates.io.

ML-DSA-65 Implementation Status Production-quality ML-DSA-65 implementations exist in the open-source cryptographic library ecosystem (notably pq-crystals/dilithium and oqs-rust). At the time of publication of this document, a dedicated Vauban Pay crate wrapping ML-DSA-65 for the hybrid-pqc receipt variant is planned for delivery in Phase 2 of the Vauban Pay roadmap. Until then, implementations of the hybrid-pqc variant relying on third-party ML-DSA-65 crates remain conformant provided the crate implements faithfully. The third-party FeedOracle hybrid-PQC reference implementation listed in (Axis 2 fixture set ) is the operational reference for the hybrid-pqc variant.

Security Considerations

Implementation Downgrade Attack An adversary in a network position between the client and the facilitator MAY attempt to strip hybrid-pqc from the X-Payment-Options header, forcing the client to fall back to classical-es256k. The resulting receipt is not post-quantum sound, leaving the long-term integrity exposed. Mitigation : a client requiring post-quantum soundness MUST send receipt_format with required: true in PAYMENT-SIGNATURE extensions, naming the required variant. A facilitator that cannot honour the request MUST return HTTP 402 with UnsupportedReceiptFormat rather than silently downgrading. Verifiers SHOULD cross-check the X-Receipt-Format header on the PAYMENT-RESPONSE against the client's required variant and reject mismatches.

Insecure Hybrid Composition A naive hybrid signature implementation that signs different canonical messages with the two component schemes does not provide the intended security property : an adversary who breaks ES256K can produce a forged classical signature, and the verifier may accept the receipt if the verification logic treats the two signatures as covering disjoint content. Mitigation : implementations MUST follow the composition principles described in : both signatures MUST cover the byte-identical JCS canonical preimage. The reference encoder in produces a single canonical byte string consumed by both signing operations.

ML-DSA-65 Side-Channel Exposure ML-DSA-65 signing operations involve rejection sampling, secret-dependent control flow, and floating-point or arithmetic operations whose timing may leak secret-key material to a co-located adversary. Side-channel analysis of lattice-based signatures is an active research area. Mitigation : ML-DSA-65 signing implementations used in production facilitator infrastructure MUST be constant-time and MUST be hardened against the classes of side-channel attack documented in the implementation's threat model. Implementors SHOULD select ML-DSA-65 libraries that have undergone public side-channel analysis (for example, libraries audited by the post-quantum cryptography community since the publication of ).

STARK Proof System Auditability The post-quantum soundness claim for STARK proof systems relies on the collision and second-preimage resistance of the underlying hash function. A flaw in the prover-verifier implementation, or in the polynomial-IOP transformation, may produce false-positive verifications independent of the hash function's strength. Mitigation : implementations SHOULD use a reference STARK prover that has undergone public audit ; the Stwo prover () is the reference for this document. Implementations that fork or modify the reference prover SHOULD re-audit the modifications against the original soundness analysis before production deployment.

Migration Timing Risk Premature deprecation of classical signature support may exclude legitimate counterparties that have not yet migrated to post-quantum infrastructure. Conversely, late migration leaves long-retention receipts exposed to retroactive forgery once a quantum adversary becomes available. Mitigation : deployments SHOULD align their deprecation schedule with the applicable jurisdictional guidance (, , , ). The 2025-2030 hybrid deployment window described in provides a five-year overlap during which both classical and post-quantum verification paths SHOULD be supported. Facilitators operating in regulated sectors SHOULD publish their migration plan in advance of any deprecation step affecting external counterparties.

IANA Considerations This document has no IANA actions. It defers to the x402 Receipt Format registry established in for the registration of the hybrid-pqc and stark-vauban-pay-v1 tokens that the discipline specified in this document maps onto. Future extensions introducing additional post-quantum receipt variants SHOULD register the corresponding tokens in that registry and reference this document for migration profile alignment.

Acknowledgments The author thanks the participants in the x402 Linux Foundation coalition for the shared canonicalisation discipline and the hybrid-PQC receipt fixture set contributions documented in and . The author thanks the NIST Post-Quantum Cryptography working group for the standardisation of , , and the migration guidance referenced throughout this document. The author thanks the StarkWare Industries team for the publication of the Stwo Circle STARK M31 prover () as an open-source reference for hash-based proving systems.

Known Adopters and Reference Implementations This appendix documents reference implementations and adopters of this specification confirmed at the time of publication. The list is informational and will be updated in subsequent revisions as additional implementations are reported.

Primary Maintainer Vauban Pay (https://pay.vauban.tech) maintains the reference post-quantum receipt specification, the published conformance vectors (https://github.com/vauban-org/x402-stark-receipts-conformance), and the reference implementations listed below. The PQC discipline integrates ML-DSA-65 (NIST FIPS 204) for hybrid signatures and the Stwo Circle STARK M31 prover () for hash-based receipt integrity.

Reference Implementation Matrix The conformance vector suite maintains an 8-implementation reference matrix across Python, JavaScript, Go, Java, Rust, PHP, Ruby, and C#. The first five are validated byte-for-byte against upstream JCS RFC 8785 libraries ; the last three are published as pure-stdlib reference runners pending CI execution. Detailed validation status is documented in _attestations/2026-05-25-vauban-8-impl-extended.md in the conformance vectors repository. The published Vauban Pay packages across 3 ecosystems : vauban-x402-jcs-conformance@0.1.0, vauban-x402-canonical@0.1.0, vauban-x402-wire@0.1.0 on crates.io (including the vauban-x402-pqc-signer crate skeleton for ML-DSA-65 signature integration) ; vauban-x402-stark-receipt@0.1.0 on PyPI ; @vauban-pay/substrate@0.1.0 on npm.

Adoption Process Implementers SHOULD notify the IETF contact at research@vauban.tech when adopting this specification in production. Adoption notifications include the post-quantum signature scheme implemented (FIPS 204 ML-DSA parameter set, hybrid mode if applicable), the STARK prover and hash function configuration, the canonical preimage discipline emitted, and the contact for follow-on coordination. Reported adopters will be listed in the next revision of this appendix following a verification step against the conformance vector matrix.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology European Parliament and Council Agence nationale de la securite des systemes d'information Bundesamt fur Sicherheit in der Informationstechnik

References

Normative References (Normative references are listed in the document header.)

Informative References (Informative references are listed in the document header.)