x402 Cryptographic Receipts: Format, Post-Quantum Discipline, and Starknet Anchor
draft-vauban-x402-consolidated-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Vauban Research | ||
| Last updated | 2026-05-29 | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Stream | ISE state | Submission Received | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vauban-x402-consolidated-00
Network Working Group F. Serafini, Ed.
Internet-Draft Vauban Research
Intended status: Informational 28 May 2026
Expires: 29 November 2026
x402 Cryptographic Receipts: Format, Post-Quantum Discipline, and
Starknet Anchor
draft-vauban-x402-consolidated-00
Abstract
The x402 V2 protocol defines HTTP-native payment flows but leaves
three gaps that block compliance use cases. First, the PAYMENT-
RESPONSE carries a facilitator-issued reference rather than a self-
contained, offline-verifiable cryptographic receipt; an auditor
cannot validate a retained receipt without contacting the
facilitator. Second, classical signatures alone (ES256K) do not
satisfy the post-quantum migration horizon set by NIST SP 800-208,
ANSSI, BSI, and EU eIDAS 2.0 for high-value or long-retention
material. Third, off-chain receipts alone do not provide ledger-
anchored finality required by frameworks such as MiCA Art. 76
(settlement record-keeping) and EU AI Act Art. 12 (transparency-and-
documentation).
This document consolidates three previously separate extensions into
a single specification. It defines (a) a negotiable receipt-format
extension with three variants (Stwo Circle STARK proof, hybrid ES256K
+ ML-DSA-65 dual-signature, classical ES256K fallback) over a JCS
canonical preimage discipline grounded in RFC 8785; (b) a two-axis
post-quantum discipline mapping hash-based proving and hybrid
signatures to the NIST PQC migration roadmap; and (c) a Starknet on-
chain anchor format with a canonical anchor tuple, Cairo event
layout, RPC endpoint convention, and block explorer reference for
human-readable audit.
Topics under active coalition discussion are explicitly out of scope:
the VPSF composability claim algebra, the payment lifecycle finite
state machine, and the delegation binding extension are deferred to
companion documents not included in this consolidated submission.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Serafini Expires 29 November 2026 [Page 1]
Internet-Draft x402-receipts May 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 November 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Status of This Document . . . . . . . . . . . . . . . . . 5
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. Receipt Format and Canonical Preimage . . . . . . . . . . . . 6
3.1. Receipt Format Enum . . . . . . . . . . . . . . . . . . . 6
3.2. HTTP Header Conventions . . . . . . . . . . . . . . . . . 8
3.3. Negotiation Semantics . . . . . . . . . . . . . . . . . . 8
3.4. Canonical Preimage Discipline . . . . . . . . . . . . . . 9
3.5. Preimage Schema and Worked Digest . . . . . . . . . . . . 10
3.6. Type Validation Requirements . . . . . . . . . . . . . . 10
3.7. Unicode Normalisation Profile . . . . . . . . . . . . . . 11
3.8. Field-Level CBOR Layout for stark-vauban-pay-v1 . . . . . 11
3.9. Variant Bodies for hybrid-pqc and classical-es256k . . . 13
3.10. Cross-Implementation Conformance Matrix . . . . . . . . . 14
3.11. Wire-Level Binding (action_ref) . . . . . . . . . . . . . 15
3.12. Compliance Receipt and RiskCheckResult Layering . . . . . 15
3.13. Error Taxonomy . . . . . . . . . . . . . . . . . . . . . 16
3.14. Extension Schemas in x402 Messages . . . . . . . . . . . 17
4. Post-Quantum Cryptographic Discipline . . . . . . . . . . . . 18
4.1. Threat Model: Quantum Adversary . . . . . . . . . . . . . 18
Serafini Expires 29 November 2026 [Page 2]
Internet-Draft x402-receipts May 2026
4.2. Proof System Layer Axis . . . . . . . . . . . . . . . . . 19
4.3. Signature Layer Axis . . . . . . . . . . . . . . . . . . 19
4.4. Migration Window Profile . . . . . . . . . . . . . . . . 20
4.5. NIST and Jurisdictional Alignment . . . . . . . . . . . . 20
5. Starknet On-Chain Anchor . . . . . . . . . . . . . . . . . . 21
5.1. Canonical Anchor Tuple . . . . . . . . . . . . . . . . . 21
5.2. Anchor Format Discipline . . . . . . . . . . . . . . . . 22
5.3. Settlement Event Layout . . . . . . . . . . . . . . . . . 23
5.4. felt252 Encoding Mask . . . . . . . . . . . . . . . . . . 23
5.5. RPC Endpoint Convention . . . . . . . . . . . . . . . . . 24
5.6. Reference Implementation: PaymentDemoEmitter . . . . . . 24
5.7. Block Explorer Canonical Reference . . . . . . . . . . . 25
5.8. Anchor Verification Algorithm . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6.1. Privacy Class Threat Model . . . . . . . . . . . . . . . 26
6.2. Replay Nullification . . . . . . . . . . . . . . . . . . 26
6.3. Canonical Preimage Validation Order . . . . . . . . . . . 27
6.4. Delegation Chain Bounds . . . . . . . . . . . . . . . . . 28
6.5. Downgrade Attack . . . . . . . . . . . . . . . . . . . . 28
6.6. Insecure Hybrid Composition . . . . . . . . . . . . . . . 29
6.7. ML-DSA-65 Side-Channel Exposure . . . . . . . . . . . . . 29
6.8. Migration Timing Risk . . . . . . . . . . . . . . . . . . 29
6.9. STARK Proof System Auditability . . . . . . . . . . . . . 30
6.10. Self-Hosted Infrastructure Assertion . . . . . . . . . . 30
6.11. RPC Endpoint Authenticity . . . . . . . . . . . . . . . . 31
6.12. Block Explorer Spoofing . . . . . . . . . . . . . . . . . 31
6.13. Event Collision and Selector Ambiguity . . . . . . . . . 32
6.14. Chain Reorganisation and Finality Window . . . . . . . . 32
6.15. Chain Identifier Confusion . . . . . . . . . . . . . . . 32
6.16. felt252 Mask and On-Chain Comparison . . . . . . . . . . 33
6.17. Facilitator Trust Boundary . . . . . . . . . . . . . . . 33
6.18. Retention-Property Determinism . . . . . . . . . . . . . 33
6.19. Timing Side-Channel Risks in STARK Proof Generation . . . 34
6.20. Open Research Items . . . . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8. Conformance Checklist . . . . . . . . . . . . . . . . . . . . 35
Known Adopters and Reference Implementations . . . . . . . . . . 37
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Normative References . . . . . . . . . . . . . . . . . . . . . 38
Informative References . . . . . . . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction
Serafini Expires 29 November 2026 [Page 3]
Internet-Draft x402-receipts May 2026
1.1. Problem Statement
The x402 protocol [X402-V2] defines HTTP-native payment flows using
three messages: PAYMENT-REQUIRED (402 response), PAYMENT-SIGNATURE
(client request), and PAYMENT-RESPONSE (facilitator confirmation).
The PAYMENT-RESPONSE carries a payment_hash and a facilitator-issued
settlement reference. Three gaps prevent the base protocol from
satisfying audit-grade and post-quantum compliance use cases:
* Off-line verifiability gap: a verifier must contact the
facilitator to confirm that the conditions of a specific payment
were met. EU AI Act Art. 12 (transparency-and-documentation) and
MiCA Art. 76 (settlement record-keeping) require evidence that is
self-contained at audit time.
* Post-quantum migration gap: ES256K signatures rely on the
discrete-logarithm hardness assumption and become forgeable under
Shor's algorithm once a sufficient quantum capability becomes
available. NIST [NIST-PQC-MIGRATION], ANSSI [ANSSI-PQC], BSI
[BSI-PQC], and EU eIDAS 2.0 [EIDAS-2] guidance converge on a
2030-2035 horizon for high-value or long-retention material.
* On-chain finality gap: an off-chain receipt does not confirm that
a settlement was committed to a public ledger. A regulator
examining a retained receipt cannot independently verify that the
settlement reached canonical confirmation at a specific block
height.
1.2. Scope
This document folds three previously separate Internet-Drafts into
one specification, addressing the three gaps in a single audit
surface:
* A negotiable receipt-format extension with three variants over a
JCS canonical preimage discipline (Section 3).
* A two-axis post-quantum discipline (proof-system layer and
signature layer) aligned with the NIST PQC migration roadmap
(Section 4).
* A Starknet on-chain anchor format with a canonical anchor tuple,
Cairo event layout, RPC endpoint convention, and block explorer
reference (Section 5).
Serafini Expires 29 November 2026 [Page 4]
Internet-Draft x402-receipts May 2026
1.3. Out of Scope
The following work, under active coalition discussion at the time of
writing, is deferred to companion documents and is not included in
this consolidated submission:
* Composability grammar for payment claims, including the algebra of
operators for combining cryptographic evidence across payment
lifecycle states. See [VPSF-ALGEBRA].
* Payment lifecycle finite state machine, including state-transition
validity rules and chain-reconstruction algorithm. See
[LIFECYCLE-FSM].
* Delegation binding extension, including cryptographic scope of
delegation receipts to granting principals. See
[DELEGATION-BINDING].
These topics are referenced in the present document only where
necessary for cross-context clarity; this document defines no
normative content for them.
1.4. Status of This Document
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. The three folded
extensions have been the subject of public coalition review at
[X402-2326], [X402-2357], [X402-2398], [X402-2411], [X402-2412],
[X402-2413], [X402-2434], [X402-2440], and [X402-2459].
2. Conventions and Definitions
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Receipt format: A string token identifying which cryptographic
receipt variant a facilitator produces. See Section 3.1.
JCS: JSON Canonicalization Scheme, defined in [RFC8785]. Produces a
deterministic byte representation of a JSON value by applying
recursive key sorting and value normalisation.
action_ref: A 32-byte opaque digest binding a payment receipt to a
Serafini Expires 29 November 2026 [Page 5]
Internet-Draft x402-receipts May 2026
work-layer event, derived by SHA-256 over the UTF-8 JCS encoding
of a canonical preimage object. See Section 3.11.
payment_hash: A hash of the payment conditions committed to by the
payer, as defined in the x402 V2 base specification [X402-V2].
NFC: Unicode Normalization Form C, as defined in [UAX15].
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. See Section 4.2.
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
only if every component signature verifies independently. See
Section 4.3.
Anchor: An on-chain record that commits a payment settlement to a
public ledger, identified by a canonical anchor tuple
(Section 5.1) and verifiable by any party with read access to the
chain.
Conforming emitter: A smart contract that satisfies the settlement
event layout defined in Section 5.3 and emits that event for each
settled payment.
3. Receipt Format and Canonical Preimage
This section defines the negotiable receipt_format extension, its
three variants, the HTTP negotiation surface, and the JCS canonical
preimage discipline that binds a receipt to a work-layer event. It
harmonises material from the three folded source drafts into a single
normative surface.
3.1. Receipt Format Enum
The receipt_format field identifies which cryptographic receipt
variant a facilitator has produced. The value is a string token from
the registry described in Section 7:
Serafini Expires 29 November 2026 [Page 6]
Internet-Draft x402-receipts May 2026
+=====================+=================================+=========+
| Token | Description | Approx. |
| | | size |
+=====================+=================================+=========+
| stark-vauban-pay-v1 | Stwo Circle STARK over payment- | ~100 KB |
| | condition witness (amount, | |
| | currency, payer attestation, | |
| | nullifier). Post-quantum sound | |
| | at the proof layer. Offline | |
| | verifiable. | |
+---------------------+---------------------------------+---------+
| hybrid-pqc | ES256K + ML-DSA-65 ([FIPS204]) | ~3.3 KB |
| | dual-signature over JCS- | |
| | canonical receipt core. | |
| | Receipt survives Q-Day if | |
| | either single algorithm is | |
| | broken. | |
+---------------------+---------------------------------+---------+
| classical-es256k | ES256K signature only. Default | ~0.5 KB |
| | fallback for clients that do | |
| | not require post-quantum or | |
| | zero-knowledge properties. | |
+---------------------+---------------------------------+---------+
Table 1
Each variant corresponds to evidenceType: "cryptographic" in the
[X402-2322] compliance taxonomy. The signature_algorithm
discriminator used in the bazaar evidenceShape maps as follows:
+======================+=====================+
| receipt_format token | signature_algorithm |
+======================+=====================+
| stark-vauban-pay-v1 | "stark-m31-stwo" |
+----------------------+---------------------+
| hybrid-pqc | "es256k+ml-dsa-65" |
+----------------------+---------------------+
| classical-es256k | "es256k" |
+----------------------+---------------------+
Table 2
Facilitators MAY introduce additional tokens by registering them in
the x402 Receipt Format registry. Tokens not present in the registry
MUST be treated as "classical-es256k" by verifiers that do not
recognise them.
Serafini Expires 29 November 2026 [Page 7]
Internet-Draft x402-receipts May 2026
The three variants correspond to three orthogonal properties; a
deployment selects the property it requires:
* proof-of-payment-conditions: the stark-vauban-pay-v1 receipt
proves amount, currency, payer attestation, and nullifier without
revealing them. The STARK proof is the deliverable.
* receipt-integrity-under-quantum: the hybrid-pqc receipt carries
two independent signatures; the receipt remains verifiable if one
signature algorithm is broken.
* work-receipt-binding: all three variants carry an optional
action_ref field (32-byte opaque digest per Section 3.11).
Binding to the work layer is a property of the preimage
derivation, not of the receipt format itself.
3.2. HTTP Header Conventions
A resource server or facilitator SHOULD include X-Payment-Options in
the 402 Payment Required response to advertise which receipt_format
variants it can produce:
X-Payment-Options: receipt_format="stark-vauban-pay-v1, hybrid-pqc, classical-es256k"
The value is a comma-separated ordered list of receipt_format tokens
from most-preferred to least-preferred. The server declares its
capabilities; the client selects from this list. If X-Payment-
Options is absent, the client MUST assume the facilitator can produce
only classical-es256k.
The facilitator MUST include X-Receipt-Format in the PAYMENT-RESPONSE
to state which variant it emitted:
X-Receipt-Format: stark-vauban-pay-v1
The verifier uses this header to select the correct receipt parser
before attempting to deserialise or verify the receipt body. If X-
Receipt-Format is absent, the verifier MUST assume classical-es256k.
A facilitator that lists stark-vauban-pay-v1 in X-Payment-Options
MUST also be capable of producing classical-es256k as a fallback.
Listing a variant without fallback capability is a protocol
violation.
3.3. Negotiation Semantics
Normal negotiation path:
Serafini Expires 29 November 2026 [Page 8]
Internet-Draft x402-receipts May 2026
1. Client receives a 402 response with X-Payment-Options.
2. Client selects the highest-preference variant it can verify from
the list.
3. Client SHOULD signal its selection by including receipt_format in
the PAYMENT-SIGNATURE request payload.
4. Facilitator produces the receipt in the selected variant and sets
X-Receipt-Format on the PAYMENT-RESPONSE.
If the client cannot verify any variant in X-Payment-Options, or if
X-Payment-Options is absent, the client MUST fall back to classical-
es256k. The facilitator MUST honour this fallback.
If a client REQUIRES a specific receipt format (for example, a
regulator requiring an offline-verifiable STARK receipt for EU AI Act
Art. 12 purposes), it MUST include receipt_format in the PAYMENT-
SIGNATURE request extensions with required: true. If the facilitator
cannot produce the requested variant, the facilitator MUST return
HTTP 402 with error UnsupportedReceiptFormat rather than silently
downgrading. The downgrade-attack mitigation in Section 6.5 requires
this discipline.
3.4. Canonical Preimage Discipline
The canonicalisation rules used by this extension are grounded in
[RFC8785] (JCS), as exercised and cross-validated through the x402
canonicalisation conformance set [X402-CANON]. The digest
construction is:
JCS_hash = SHA-256(UTF-8(JCS(object)))
The wire-format version marker jcs-rfc8785-v1 identifies this rule
set in the canon_version field. Four normative rules apply:
1. Timestamps are encoded as integers (timestamp_ms, milliseconds
since Unix epoch). The field name timestamp carrying an RFC 3339
string MUST NOT be used.
2. Field names are compared as byte strings, sorted in [RFC8785]
lexicographic order.
3. Arrays preserve their order; reordering produces a different
digest.
4. Type validation is performed before canonicalisation; coercion is
forbidden.
Serafini Expires 29 November 2026 [Page 9]
Internet-Draft x402-receipts May 2026
3.5. Preimage Schema and Worked Digest
The canonical action_ref preimage object contains the following
fields, sorted lexicographically per [RFC8785] Section 3.2.3:
{
"action_type": "<string>",
"agent_id": "<string>",
"scope": "<string>",
"timestamp_ms": <integer>
}
The JCS output for the shared coalition preimage is:
{"action_type":"sanctions_screen","agent_id":"did:web:agent-7.example.com","scope":"counterparty-due-diligence","timestamp_ms":1747728000000}
The action_ref digest is:
action_ref = SHA-256(UTF-8(JCS(preimage)))
= 10d8a38c01d8672176aa6e5209a368fde3e1831640d69e15283142b35880c2c1
This worked example is byte-identical across the eight-language
conformance matrix described in Section 3.10.
3.6. Type Validation Requirements
Implementations MUST reject preimage objects containing:
* Float values for timestamp_ms: 1747728000000.0 MUST be rejected;
only integer JSON numbers are valid. Conformance vector 0002-ms-
precision-trap demonstrates the failure mode where a float
representation produces no parsing error but an incorrect digest.
Rejection MUST occur before canonicalisation.
* Missing canonical fields: if any of action_type, agent_id, scope,
or timestamp_ms is absent, the preimage MUST be rejected before
canonicalisation. Vector 0012-missing-canonical-field covers this
case.
* Duplicate keys: if the JSON object contains duplicate key names,
the preimage MUST be rejected at parse time. Accepting last-wins
or first-wins semantics creates interoperability ambiguity.
Vector 0010-duplicate-keys covers this case.
Serafini Expires 29 November 2026 [Page 10]
Internet-Draft x402-receipts May 2026
3.7. Unicode Normalisation Profile
[X402-CANON] deliberately applies no Unicode normalisation in the
canonicaliser, so that NFC and NFD are distinct canonical inputs.
This extension imposes a stricter profile on the action_ref preimage:
it requires NFC and rejects non-NFC input. This is a profile
narrowing, not a contradiction of [X402-CANON].
Implementations MUST normalise all string values in the preimage to
Unicode Normalization Form C (NFC) per [UAX15] BEFORE JCS
canonicalisation. Implementations MUST reject input where any string
value in the preimage is encoded in NFD, NFKC, or NFKD form.
Acceptance of non-NFC input is a conformance violation. Verifiers
MUST NOT perform implicit re-normalisation; the input MUST already be
NFC for the digest to be reproducible across runtimes.
Rationale: a verifier receiving an NFD-encoded preimage would compute
a different digest than one receiving the NFC equivalent, silently
breaking receipt verification without a parsing error. macOS HFS+
historically stored filenames in NFD decomposed form, and database
collations vary across deployments; this is not a hypothetical edge
case.
Vector 0011-unicode-normalisation demonstrates the NFD divergence
failure mode.
3.8. Field-Level CBOR Layout for stark-vauban-pay-v1
The receipt body for the stark-vauban-pay-v1 variant is CBOR-encoded
per [RFC8949] canonical CBOR (Section 4.2.1). The top-level CBOR map
contains the following fields:
Serafini Expires 29 November 2026 [Page 11]
Internet-Draft x402-receipts May 2026
+===============+========+=================================+
| Key | Major | Description |
| | type | |
+===============+========+=================================+
| canon_version | text | Canonicalisation rule |
| | string | identifier; "jcs-rfc8785-v1" |
| | | for this version. |
+---------------+--------+---------------------------------+
| proof | byte | The serialised Stwo Circle |
| | string | STARK proof bytes. |
+---------------+--------+---------------------------------+
| public_inputs | byte | The serialised public inputs to |
| | string | the proof verifier. |
+---------------+--------+---------------------------------+
| payment_hash | byte | SHA-256 of the canonical |
| | string | payment conditions, 32 bytes. |
+---------------+--------+---------------------------------+
| action_ref | byte | OPTIONAL. 32-byte opaque digest |
| | string | per Section 3.11. Omitted (not |
| | | zero-valued) when no work- |
| | | receipt binding is asserted. |
+---------------+--------+---------------------------------+
| nullifier | byte | 32-byte nullifier preventing |
| | string | double-spend. |
+---------------+--------+---------------------------------+
| circuit_id | text | Identifier for the circuit |
| | string | version; "vauban-pay-v1" for |
| | | this version. |
+---------------+--------+---------------------------------+
Table 3
The proof attests to a circuit that verifies the following
predicates:
* Payment amount matches the signed PaymentRequirements.amount.
* Currency asset address matches PaymentRequirements.asset.
* Payer attestation is valid (subject to merchant attestation-gate
configuration).
* Nullifier is unique (no replay for this nullifier in the
settlement ledger).
Serafini Expires 29 November 2026 [Page 12]
Internet-Draft x402-receipts May 2026
The serialised receipt is base64url-encoded (no padding) per
[RFC4648] Section 5 when transmitted in the PAYMENT-RESPONSE
extension envelope. The canonical CBOR bytes layout is fixed by the
conformance vectors at [VAUBAN-CONFORMANCE]; implementations MUST be
byte-for-byte compatible with the published vectors.
When a stark-vauban-pay-v1 receipt is anchored on Starknet, the
felt252 masking operation described in Section 5.4 MUST be applied
before writing or comparing the action_ref value in keys[1] of the
on-chain event.
3.9. Variant Bodies for hybrid-pqc and classical-es256k
The hybrid-pqc receipt body is a JSON object [RFC8259] with the
following top-level fields, JCS-canonical [RFC8785]:
* receipt_core: JSON object; the canonical payload signed by both
algorithms.
* signature: ES256K signature over SHA-256(UTF-
8(JCS(receipt_core))), base64url-encoded.
* pqc_signature: ML-DSA-65 ([FIPS204]) signature over the identical
canonical bytes, base64url-encoded.
* kid_es256k: Key identifier for the ES256K key in the facilitator's
JWKS endpoint.
* kid_mldsa65: Key identifier for the ML-DSA-65 key in the
facilitator's JWKS endpoint.
Both signatures MUST cover the byte-identical canonical byte string.
Verifiers MUST confirm both signatures independently. A verifier
that can only verify ES256K SHOULD still check pqc_signature length
and structure for plausibility.
The classical-es256k receipt body is a JWS Compact Serialization
string [RFC7515]. The JWS payload contains the canonical
payment_hash and optionally action_ref. This is the default fallback
for clients that do not require zero-knowledge or post-quantum
properties.
Serafini Expires 29 November 2026 [Page 13]
Internet-Draft x402-receipts May 2026
3.10. Cross-Implementation Conformance Matrix
The JCS canonical preimage discipline of this extension is exercised
through eight independent runners across eight languages. Five are
validated byte-for-byte against published upstream JCS RFC 8785
libraries at the time of publication; three are pure-stdlib reference
runners published in the conformance vectors repository with CI
execution pending.
+============+==================================+===================+
| Language | Library or runner | Validation |
| | | status |
+============+==================================+===================+
| Python | rfc8785@0.1.4 (Trail of Bits) | validated 11/11 |
| | | byte-for-byte |
+------------+----------------------------------+-------------------+
| JavaScript | canonicalize@3.0.0 (Erdtman + | validated 11/11 |
| | Rundgren) | byte-for-byte |
+------------+----------------------------------+-------------------+
| Go | gowebpki/jcs v1.0.1 | validated 11/11 |
| | | byte-for-byte |
+------------+----------------------------------+-------------------+
| Java | cyberphone/json-canonicalization | validated 11/11 |
| | (RFC 8785 reference) | byte-for-byte |
+------------+----------------------------------+-------------------+
| Rust | serde_jcs 0.2.0 (l1h3r) via | validated 11/11 |
| | vauban-x402-jcs-conformance | byte-for-byte |
+------------+----------------------------------+-------------------+
| PHP | runners/runner.php (pure stdlib, | reference, CI- |
| | PHP 8.0+) | pending |
+------------+----------------------------------+-------------------+
| Ruby | runners/runner.rb (pure stdlib, | reference, CI- |
| | Ruby 3.0+) | pending |
+------------+----------------------------------+-------------------+
| C# | runners/runner.cs (pure stdlib, | reference, CI- |
| | .NET 8) | pending |
+------------+----------------------------------+-------------------+
Table 4
Aggregate cross-validation: 15/15 byte-for-byte agreements across the
three ALLOW/DENY/REFER fixture vectors published at [X402-2434],
established against the first five runners.
The conformance vector suite is published at https://github.com/
vauban-org/x402-stark-receipts-conformance under Apache 2.0. The
Vauban Research-maintained crates vauban-x402-jcs-conformance@0.1.0,
vauban-x402-canonical@0.1.0, and vauban-x402-wire@0.1.0 (crates.io);
Serafini Expires 29 November 2026 [Page 14]
Internet-Draft x402-receipts May 2026
the Python package vauban-x402-stark-receipt@0.1.0 (PyPI); and the
npm package @vauban-pay/substrate@0.1.0 are published as Apache 2.0
reference implementations.
Implementers SHOULD NOT introduce a new runner without first
executing all eleven published vectors byte-for-byte against an
existing validated runner.
3.11. Wire-Level Binding (action_ref)
The action_ref field is a 32-byte opaque digest that binds a payment
receipt to a work-layer event. It is the seam between the payment
layer (this document) and the work layer (the application that
consumes the payment). The digest is derived by SHA-256 over the
UTF-8 JCS encoding of the canonical preimage object defined in
Section 3.5.
The encoding of action_ref on the wire depends on the carrier:
* In JSON payloads (hybrid-pqc, classical-es256k), action_ref is
base64url-encoded with no padding per [RFC4648] Section 5.
* In CBOR payloads (stark-vauban-pay-v1), action_ref is a 32-byte
byte string (Section 3.8).
* On the Starknet anchor, action_ref is felt252-masked per
Section 5.4 before being written to keys[1] of the settlement
event.
The action_ref field is OPTIONAL in all three variants. When
omitted, the receipt asserts payment without asserting a work-layer
binding. A receipt MUST NOT carry a zero-valued action_ref to signal
absence; absence is signalled by omission.
Where a deployment also participates in the composite trust-query
layer [X402-2440], the same action_ref digest doubles as the trust-
query anchor. The trust-query layer is referenced here only for
cross-context clarity; this document defines no normative content for
it.
3.12. Compliance Receipt and RiskCheckResult Layering
Two distinct layers exist around a payment receipt and MUST NOT be
conflated:
Serafini Expires 29 November 2026 [Page 15]
Internet-Draft x402-receipts May 2026
* The internal compliance_receipt carries the facilitator's
compliance decision over the payment (ALLOW, DENY, REFER). It is
an internal artefact of the facilitator's risk pipeline. Its
fixture form is defined at [X402-2434].
* The consumer-facing RiskCheckResult is the wire-format signal
returned to the client. It conveys the outcome necessary for the
client to proceed, without exposing the facilitator's internal
compliance reasoning.
A facilitator MUST NOT place internal compliance_receipt material in
the consumer-facing RiskCheckResult surface. A verifier MUST NOT
treat the presence of a RiskCheckResult as equivalent to a
cryptographic payment receipt; the two answer different questions
(was the payment permitted under policy, versus did the payment
settle cryptographically).
3.13. Error Taxonomy
A facilitator or verifier rejecting a receipt or a PAYMENT-SIGNATURE
SHOULD signal the reason via the X-Receipt-Reject-Reason response
header. Seven tokens are defined, each mapped to an HTTP status code
[RFC9110]:
Serafini Expires 29 November 2026 [Page 16]
Internet-Draft x402-receipts May 2026
+==========================+========+==============================+
| Token | HTTP | Meaning |
| | status | |
+==========================+========+==============================+
| MalformedClaim | 400 | The receipt or preimage is |
| | | syntactically invalid. |
+--------------------------+--------+------------------------------+
| PaymentRequired | 402 | No valid payment is |
| | | associated with the request. |
+--------------------------+--------+------------------------------+
| UnsupportedReceiptFormat | 402 | A required: true receipt |
| | | format cannot be produced |
| | | (Section 3.3). |
+--------------------------+--------+------------------------------+
| NullifierReplay | 409 | The nullifier is already |
| | | present in the settlement |
| | | ledger (Section 6.2). |
+--------------------------+--------+------------------------------+
| Expired | 410 | The receipt timestamp_ms |
| | | exceeds the configured age |
| | | threshold. |
+--------------------------+--------+------------------------------+
| StructuralInvalid | 422 | The receipt parses but fails |
| | | schema or canonical-preimage |
| | | validation. |
+--------------------------+--------+------------------------------+
| HumanityRequired | 403 | The deployment requires a |
| | | humanity attestation the |
| | | request did not satisfy. |
+--------------------------+--------+------------------------------+
Table 5
A facilitator MUST NOT return a generic 400 without an X-Receipt-
Reject-Reason token when one of the defined tokens applies. The
token set is closed for this version; new tokens require registration
alongside the receipt-format registry.
3.14. Extension Schemas in x402 Messages
The receipt_format extension appears in each of the three x402
messages. The following fields are defined for the extension object:
* In PAYMENT-REQUIRED (the 402 response): supported (ordered array
of tokens the facilitator can produce) and default (the token used
when the client expresses no preference).
Serafini Expires 29 November 2026 [Page 17]
Internet-Draft x402-receipts May 2026
* In PAYMENT-SIGNATURE (the client request): receipt_format (the
token the client selects) and required (boolean; when true, the
facilitator MUST either honour the token or reject with
UnsupportedReceiptFormat).
* In PAYMENT-RESPONSE (the facilitator confirmation): receipt_format
(the token emitted), receipt (the serialised receipt body in the
variant encoding of Section 3.8 or Section 3.9), and action_ref
(OPTIONAL, the wire-encoded binding digest per Section 3.11).
The X-Payment-Options and X-Receipt-Format headers (Section 3.2)
carry the same information at the HTTP layer for clients that
negotiate before parsing the message body. Where both the header and
the body extension are present, they MUST agree; a verifier
encountering disagreement MUST reject the message with
StructuralInvalid.
4. Post-Quantum Cryptographic Discipline
This section defines a two-axis post-quantum discipline. The proof-
system axis (Section 4.2) governs the soundness assumption of any
proof carried by a receipt; the signature axis (Section 4.3) governs
the integrity of any signature over a receipt. The two axes are
independent: a deployment may satisfy one without the other, and the
migration profile (Section 4.4) states which combination is required
for which risk class.
4.1. Threat Model: Quantum Adversary
This document assumes an adversary capable of executing Shor's
algorithm against classical public-key primitives and Grover's
algorithm against unstructured search. The adversary holds the
harvest-now-decrypt-later capability: every receipt published today
is recordable and can be attacked later, once a sufficient quantum
capability becomes available. A receipt emitted under a statutory
retention obligation may therefore have to survive an adversary that
did not exist at issuance time.
Three forgery vectors are relevant:
* ES256K signature break under Shor's algorithm. The security of
ES256K reduces to the hardness of the elliptic-curve discrete
logarithm, which Shor's algorithm solves in polynomial time. A
classical-only receipt becomes forgeable once this capability
exists.
Serafini Expires 29 November 2026 [Page 18]
Internet-Draft x402-receipts May 2026
* Hash collision under Grover's algorithm. Grover provides only a
quadratic speedup against unstructured search; SHA-256 retains an
effective 128-bit pre-image and collision resistance against a
quantum adversary, which remains adequate for the digest
constructions in this document.
* Proof-system soundness break. A proof system whose soundness
reduces to an algebraic assumption (pairings, discrete logarithms,
factorisation) may lose soundness under a quantum adversary
independently of the signature layer.
4.2. Proof System Layer Axis
A receipt variant that claims post-quantum soundness at the proof
layer MUST use a proof system whose soundness reduces to the
collision and second-preimage resistance of a cryptographic hash
function rather than to an algebraic assumption. STARK proof systems
satisfy this requirement; the stark-vauban-pay-v1 variant uses such a
system.
Implementations MUST NOT present a receipt as post-quantum sound at
the proof layer when the proof is produced by Groth16, by PLONK, or
by any pairing-based SNARK construction over BN254, BLS12-381, or any
other pairing-friendly curve. These constructions rely on
assumptions that do not survive the threat model of Section 4.1, and
labelling such a proof post-quantum sound is a conformance violation.
The hash-based property is preserved across faithful adapter
implementations of a reference prover. It breaks under naive
substitution of an algebraic proof system; see Section 6.9 for the
auditability considerations.
4.3. Signature Layer Axis
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 (ES256K) and one post-quantum (ML-
DSA-65 per [FIPS204]). This is the hybrid-pqc construction.
A verifier MUST verify both component signatures independently and
MUST reject the receipt if either component fails. Both signatures
MUST cover the byte-identical canonical byte string produced by the
discipline of Section 3.4. A construction in which the two component
schemes sign different canonical messages does not provide the
intended security property and MUST NOT be presented as a hybrid
signature; see Section 6.6.
Serafini Expires 29 November 2026 [Page 19]
Internet-Draft x402-receipts May 2026
The hybrid construction provides defence in depth: the receipt
remains unforgeable as long as at least one component scheme remains
unbroken. It is not a transitional measure to be discarded at the
moment ML-DSA-65 is universally deployed; retaining the classical
component guards against an undiscovered weakness in the lattice
assumption, and retaining the post-quantum component guards against
Shor.
4.4. Migration Window Profile
This document profiles the 2025-2030 migration window. Within this
window both verification paths SHOULD be supported, providing a five-
year overlap during which counterparties migrate at their own pace.
* For deployments under a statutory retention obligation (for
example MiCA Art. 80, AMLR Art. 56, or DORA Art. 14), hybrid-pqc
is REQUIRED for new receipts. Long-retention material is exactly
the class exposed to the harvest-now-decrypt-later adversary.
* For deployments without such an obligation, hybrid-pqc is
RECOMMENDED.
* After 2030, classical-es256k SHOULD be deprecated for new receipt
issuance. The exact deprecation date follows applicable NIST,
ANSSI, BSI, and eIDAS guidance (Section 4.5); this document does
not fix a single date, because the authoritative horizon is set by
the named bodies and may move.
A facilitator in a regulated sector SHOULD publish its migration plan
in advance of any deprecation step that affects external
counterparties, so that those counterparties are not excluded without
notice.
4.5. NIST and Jurisdictional Alignment
The discipline of this section maps to published migration guidance:
* NIST PQC migration roadmap [NIST-PQC-MIGRATION] and the hybrid
composition principles for hash-based signature schemes in SP
800-208 [SP800-208], adapted here to the dual-signature hybrid-pqc
construction.
* ANSSI guidance on post-quantum migration [ANSSI-PQC], which
recommends hybrid classical-plus-post-quantum constructions during
the transition.
* BSI Technical Guideline TR-02102 [BSI-PQC].
Serafini Expires 29 November 2026 [Page 20]
Internet-Draft x402-receipts May 2026
* EU eIDAS 2.0 [EIDAS-2], which sets the trust-services horizon for
the European single market.
ML-DSA-65 is selected as the post-quantum signature component because
it is the NIST-standardised lattice signature at the security
category appropriate for long-retention financial material. ML-KEM
[FIPS203] is referenced for completeness as the companion key-
encapsulation standard; key establishment is out of scope for this
document, which addresses receipt integrity rather than transport
confidentiality.
5. Starknet On-Chain Anchor
This section defines the format and verification of an on-chain
settlement anchor on Starknet. The anchor closes the on-chain
finality gap of Section 1: it lets a verifier confirm, without
facilitator cooperation, that a settlement reached canonical
confirmation at a specific block height. The anchor is OPTIONAL; a
deployment that does not require ledger-anchored finality MAY omit
it.
5.1. Canonical Anchor Tuple
An on-chain settlement record is identified by a five-field tuple
embedded in the PAYMENT-RESPONSE extension envelope when on-chain
submission has been confirmed:
Serafini Expires 29 November 2026 [Page 21]
Internet-Draft x402-receipts May 2026
+==============+=========+==========+=============================+
| Field | Type | Required | Meaning |
+==============+=========+==========+=============================+
| chain_id | string | yes | Starknet chain identifier |
| | | | (Section 5.2). |
+--------------+---------+----------+-----------------------------+
| tx_hash | string | yes | Transaction hash, felt252 |
| | | | hex (Section 5.2). |
+--------------+---------+----------+-----------------------------+
| event_index | integer | yes | Zero-based index of the |
| | | | settlement event within the |
| | | | transaction receipt. |
+--------------+---------+----------+-----------------------------+
| block_number | integer | no | Block height of inclusion; |
| | | | omitted while the |
| | | | transaction is pending. |
+--------------+---------+----------+-----------------------------+
| kind | string | yes | Settlement class |
| | | | discriminant: "settlement", |
| | | | "refund", or "delegation". |
+--------------+---------+----------+-----------------------------+
Table 6
The anchor tuple identifies the transaction but not the emitting
contract; a verifier MUST additionally check the emitter address per
Section 5.8.
5.2. Anchor Format Discipline
chain_id is one of the Starknet-native identifiers "SN_MAIN"
(mainnet) or "SN_SEPOLIA" (Sepolia testnet). These are documented in
[STARKNET-DOCS] and are not IANA-registered tokens (Section 7).
tx_hash is a felt252 value encoded as a 66-character string: the
prefix 0x followed by 64 lowercase hexadecimal characters, zero-
padded on the left. Verifiers MUST compare tx_hash values as
normalised lowercase hex; an uppercase or unpadded form MUST be
normalised before comparison, not rejected.
event_index is zero-based. The kind discriminant maps to the three
settlement classes; the values derive from the lifecycle state names
of [LIFECYCLE-FSM] but require no separate registration in this
document.
Serafini Expires 29 November 2026 [Page 22]
Internet-Draft x402-receipts May 2026
The anchor object is embedded as an extension field of the PAYMENT-
RESPONSE only after on-chain submission has been confirmed. A
facilitator MUST NOT embed an anchor tuple for a transaction it has
merely broadcast; the tuple asserts inclusion, not submission.
5.3. Settlement Event Layout
A conforming emitter emits, for each settled payment, a Starknet
event with the following two-key, three-data structure:
+=========+=====================================================+
| Slot | Content |
+=========+=====================================================+
| keys[0] | Selector for the PaymentSettled event (or the |
| | equivalent ABI event name). |
+---------+-----------------------------------------------------+
| keys[1] | The felt252-masked action_ref digest (Section 5.4). |
+---------+-----------------------------------------------------+
| data[0] | The kind discriminant: 0x1 (settlement), 0x2 |
| | (refund), 0x3 (delegation). |
+---------+-----------------------------------------------------+
| data[1] | The felt252-masked low bits of payment_hash. |
+---------+-----------------------------------------------------+
| data[2] | Reserved. Emitters MUST write 0x0. Verifiers MUST |
| | NOT reject an anchor whose data[2] is non-zero. |
+---------+-----------------------------------------------------+
Table 7
The reserved-field discipline (data[2]) preserves forward
compatibility: a future revision may assign meaning to the slot, and
existing verifiers must not treat a populated slot as a validation
failure.
5.4. felt252 Encoding Mask
Starknet field elements are bounded below 2^252. A SHA-256 digest is
256 bits and therefore does not always fit in a single felt252. This
document fixes a deterministic truncation applied to any SHA-256
digest written to or compared against an on-chain felt252 slot:
hash_felt252 = sha256_bigint & ((1 << 251) - 1)
Serafini Expires 29 November 2026 [Page 23]
Internet-Draft x402-receipts May 2026
The mask retains the low 251 bits. Implementations MUST apply the
identical mask at both emission time (when writing keys[1] and
data[1]) and verification time (when recomputing the expected
values). The collision probability introduced by retaining 251 of
256 bits is negligible (on the order of 2^-251) and does not weaken
the binding for any practical adversary.
An implementation that omits the mask at verification time produces
false-negative verifications for receipts whose digest has non-zero
bits in positions 251 through 255; see Section 6.16.
5.5. RPC Endpoint Convention
Anchor verification requires read access to a Starknet JSON-RPC
endpoint. The methods used are starknet_getTransactionByHash,
starknet_getTransactionReceipt, and starknet_getBlockWithTxHashes, as
defined in [STARKNET-DOCS].
Verifiers MUST use TLS-authenticated endpoints and SHOULD prefer
endpoints they operate themselves (Section 6.10). The Vauban Pay
reference deployment operates a self-hosted Pathfinder [PATHFINDER]
full node at https://sepolia.rpc.vauban.tech/rpc/v0_10 (Sepolia,
Starknet JSON-RPC spec v0.10.2) and https://rpc.vauban.tech/rpc/v0_10
(mainnet). These endpoints are cited as one conformant
implementation; this specification mandates no specific endpoint
operator.
5.6. Reference Implementation: PaymentDemoEmitter
The PaymentDemoEmitter Cairo contract is deployed on Starknet Sepolia
at
0x044dd87a94a801cf775d4c5e4b6703102d4e97e1cd1d0a8879341219ae4f19ff.
It emits the settlement event layout of Section 5.3 and is the
reference against which the anchor verification algorithm
(Section 5.8) is exercised.
The contract is a demonstration surface only. It MUST NOT be used as
a production payment processor; it performs no value transfer and
applies no access control suitable for production. Its purpose is to
provide a stable, publicly browsable on-chain event that conforms to
Section 5.3, so that an independent verifier can reproduce the anchor
verification end to end.
The contract is browsable on Voyager (Section 5.7) at
https://sepolia.voyager.online/
contract/0x044dd87a94a801cf775d4c5e4b6703102d4e97e1cd1d0a8879341219ae4f19ff.
Serafini Expires 29 November 2026 [Page 24]
Internet-Draft x402-receipts May 2026
5.7. Block Explorer Canonical Reference
Voyager [VOYAGER] is the canonical human-readable audit surface for
Starknet mainnet and Sepolia in this document. Transaction and
contract URLs follow the patterns https://voyager.online/tx/<tx_hash>
and https://voyager.online/contract/<address> for mainnet, with the
sepolia.voyager.online host for the testnet.
The Voyager URL is supplementary. The normative anchor check is the
RPC verification of Section 5.8, not a browser visit.
Implementations MUST NOT cite any block explorer other than Voyager
as the canonical visual audit surface for Starknet; the specification
endorses no alternative explorer for this role. The spoofing risk of
relying on a browser visit alone is treated in Section 6.12.
5.8. Anchor Verification Algorithm
A verifier confirms an anchor by executing the following steps in
order. A verifier MUST NOT skip a step.
1. Validate chain_id against the deployment environment the verifier
is configured for; reject on mismatch (Section 6.15).
2. Retrieve the transaction receipt via
starknet_getTransactionReceipt for tx_hash.
3. Validate the emitter: confirm that
events[event_index].from_address equals a known-good emitter
address from an implementation-controlled list (Section 6.13).
4. Validate block_number against the receipt, where block_number is
present.
5. Compute the expected keys[1] by applying the felt252 mask
(Section 5.4) to the receipt's action_ref, and compare it against
the on-chain keys[1].
6. Compare data[1] against the felt252-masked low bits of
payment_hash as an OPTIONAL cross-check.
7. Validate the kind discriminant in data[0] against the tuple's
kind field.
8. Check the block finality status against the verifier's configured
threshold (Section 6.14); a verifier under a regulatory finality
obligation MUST require L1 acceptance rather than L2 acceptance
alone.
Serafini Expires 29 November 2026 [Page 25]
Internet-Draft x402-receipts May 2026
6. Security Considerations
6.1. Privacy Class Threat Model
The three receipt variants defined in Section 3 expose different
amounts of information to a verifier or third-party observer.
Implementations MUST select the variant whose disclosure profile
matches the deployment's privacy class.
The stark-vauban-pay-v1 variant proves payment conditions (amount,
currency, payer attestation, nullifier) without revealing the
witness. A verifier confirms that the conditions held without
learning their values. However, the action_ref digest is
deterministic given the preimage. If the preimage is known to an
adversary, the adversary can confirm whether a given payment was
bound to a specific work event. Implementations that require
unlinkability MUST use opaque, non-guessable agent_id and scope
values in the preimage. The nullifier set, when exposed to third
parties, allows correlation of repeated nullifier checks against
unrelated transactions; nullifier sets SHOULD be exposed only under
access controls aligned with the deployment's privacy policy.
The hybrid-pqc and classical-es256k receipts do not provide zero-
knowledge properties. They carry the receipt_core in cleartext as
JCS-canonical JSON. Parties sharing these receipts with third-party
verifiers SHOULD treat the full payment conditions as visible. A
regulator examining a hybrid-pqc receipt sees the full settlement
detail; a third-party logging service receiving a classical-es256k
receipt for delivery confirmation similarly sees the full detail.
The three variants do not represent a single security hierarchy; they
represent orthogonal disclosure profiles. A deployment requiring
both proof-condition privacy and post-quantum signature integrity MAY
combine a stark-vauban-pay-v1 proof with a hybrid outer signature in
the same envelope, provided both cover the byte-identical canonical
preimage.
6.2. Replay Nullification
The NullifierReplay error code, returned with HTTP 409, is the
primary mechanism for preventing double-spend. Facilitators MUST
maintain a nullifier store indexed by the settlement ledger and MUST
reject any PAYMENT-SIGNATURE whose nullifier is already present. The
store MUST be durable across facilitator restarts; an in-memory-only
store creates a replay window across process boundaries.
Serafini Expires 29 November 2026 [Page 26]
Internet-Draft x402-receipts May 2026
The nullifier is bound to the receipt via the canonical preimage and
the underlying STARK proof (for stark-vauban-pay-v1) or via the JCS-
canonical receipt_core (for hybrid-pqc and classical-es256k). An
adversary attempting to replay a settled payment MUST produce a fresh
nullifier; if the underlying cryptographic scheme is sound, the
adversary cannot do so without the witness material.
The timestamp_ms field in the action_ref preimage further bounds the
replay window. Facilitators SHOULD enforce a maximum timestamp_ms
age aligned with the maxTimeoutSeconds field in the PaymentRequired
response. Receipts whose timestamp_ms is older than the configured
threshold MUST be rejected with HTTP 410 Expired regardless of
nullifier state.
On-chain anchoring (Section 5) adds a second-layer replay defence. A
settled payment whose anchor tuple has been emitted on the canonical
chain is verifiable by any party; an adversary attempting to issue a
duplicate settlement after on-chain anchoring would produce a
divergent (payment_hash, action_ref) pair detectable by any verifier
with read access to the chain.
6.3. Canonical Preimage Validation Order
Implementations MUST validate the canonical preimage discipline of
Section 3.4 BEFORE acting on any receipt content. Accepting a
receipt whose action_ref was derived from a non-canonical preimage
(float timestamp_ms, missing fields, duplicate keys, non-NFC strings)
creates a binding gap: the receipt may appear structurally valid
while the work-layer binding is silently broken. A verifier that
processes receipt content before checking preimage validity cannot
assert the causal link between the payment and the work event.
The validation order is fixed:
1. Parse the receipt envelope and extract the canonical preimage
object.
2. Apply type validation per Section 3.4 (reject float timestamp_ms,
missing fields, duplicate keys).
3. Apply Unicode NFC validation per Section 3.4 (reject non-NFC
strings).
4. Compute the JCS canonical bytes and the SHA-256 digest.
5. Compare the computed digest against the action_ref field of the
receipt.
Serafini Expires 29 November 2026 [Page 27]
Internet-Draft x402-receipts May 2026
6. Only after digest match: verify cryptographic signatures or STARK
proof.
7. Only after signature or proof verification: act on receipt
content.
A verifier MUST NOT short-circuit any of these steps. Acceptance of
a non-canonical preimage by a verifier propagates the violation into
every downstream system that trusts the verifier's output.
6.4. Delegation Chain Bounds
The cryptographic scope of delegation receipts to granting principals
is defined in [DELEGATION-BINDING] (deferred to a companion
document). This consolidated document does not specify normative
content for delegation binding. A receipt produced by a delegated
agent under a DelegationGrant SHOULD include the granting principal's
identifier in the agent_id field of the action_ref preimage, and the
delegation scope in the scope field, so that a verifier with access
to the delegation policy can confirm the bounds. The exact
delegation policy schema, the verifier-side bounds-check algorithm,
and the cryptographic linkage between the delegation grant and the
derived receipt are out of scope for this document and are addressed
in the companion work.
A verifier of a non-delegated receipt MAY ignore the delegation
policy machinery entirely. A verifier of a delegated receipt without
access to the companion delegation specification MUST treat the
delegation chain as unbound and SHOULD NOT accept the receipt as
evidence of delegated authority.
6.5. 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 long-term
integrity exposed.
Mitigation: a client requiring post-quantum soundness MUST send
receipt_format with required: true in the PAYMENT-SIGNATURE
extension. 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.
Serafini Expires 29 November 2026 [Page 28]
Internet-Draft x402-receipts May 2026
6.6. 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 Section 4.3; both signatures MUST cover the byte-
identical JCS canonical preimage. The reference encoder produces a
single canonical byte string consumed by both signing operations.
6.7. ML-DSA-65 Side-Channel Exposure
ML-DSA-65 signing operations involve rejection sampling, secret-
dependent control flow, and 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 SHOULD be
selected from libraries that have undergone public side-channel
analysis since the publication of [FIPS204].
6.8. 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.
Mitigation: deployments SHOULD align their deprecation schedule with
applicable jurisdictional guidance ([NIST-PQC-MIGRATION],
[ANSSI-PQC], [BSI-PQC], [EIDAS-2]). The 2025-2030 hybrid deployment
window provides a five-year overlap during which both verification
paths SHOULD be supported. Facilitators in regulated sectors SHOULD
publish their migration plan in advance of any deprecation step
affecting external counterparties.
Serafini Expires 29 November 2026 [Page 29]
Internet-Draft x402-receipts May 2026
6.9. STARK Proof System Auditability
The post-quantum soundness claim for the stark-vauban-pay-v1 variant
relies on the collision and second-preimage resistance of the
underlying hash function and on the correctness of the prover-
verifier implementation. A flaw in the proof system implementation
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 Circle STARK M31 prover [STWO],
deployed operationally on Starknet mainnet since 2025, 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. The hash-
based property of the underlying proof system is preserved across
faithful adapter implementations; the property breaks under naive
substitution of an algebraic SNARK (Section 4.2 forbids this
substitution under the post-quantum soundness claim).
The post-quantum soundness claim is a security ceiling, not a
security floor; it states that no known quantum algorithm reduces the
proof system's soundness, not that the proof system is immune to
future cryptanalysis. This document makes no claim about the long-
term security of any specific proof system configuration beyond the
current state of the published analysis.
6.10. Self-Hosted Infrastructure Assertion
The reference Vauban Pay deployment operates a self-hosted Pathfinder
[PATHFINDER] Starknet full node at
https://sepolia.rpc.vauban.tech/rpc/v0_10 (Sepolia testnet, JSON-RPC
spec v0.10.2) and https://rpc.vauban.tech/rpc/v0_10 (mainnet). The
on-chain anchor format of Section 5 can be verified against these
endpoints or against any conformant Starknet JSON-RPC implementation
operated by a party the verifier trusts.
The specification does not mandate the use of any specific endpoint
operator. A verifier MAY operate its own Starknet full node, use a
third-party endpoint of its choice, or any combination of the two.
The protocol's anchor verification algorithm (Section 5.8) is
independent of the endpoint provider; it requires only that the
endpoint implement the Starknet JSON-RPC specification and that the
TLS chain be authenticated.
Verifiers SHOULD NOT depend on any single third-party endpoint
operator for anchor verification under regulatory audit obligations.
The audit-resilience property of an on-chain anchor (that an auditor
Serafini Expires 29 November 2026 [Page 30]
Internet-Draft x402-receipts May 2026
can re-verify at year N without facilitator cooperation) is
undermined if the verifier depends on a third-party endpoint that may
withdraw service, impose access controls incompatible with audit
timelines, or otherwise constrain re-verification. Verifiers
operating under MiCA Art. 76, DORA Art. 14, or comparable obligations
SHOULD operate their own Starknet read infrastructure or contract
with multiple independent endpoint operators with cross-checked
responses.
6.11. RPC Endpoint Authenticity
An anchor verification that relies on a network RPC endpoint is
subject to man-in-the-middle attack if the transport is not
authenticated. An adversary that controls the network path between
the verifier and the RPC endpoint may return fabricated event data,
causing the verifier to falsely confirm an anchor that was never
committed to the canonical chain.
Mitigation: verifiers MUST use TLS-authenticated RPC endpoints.
Verifiers SHOULD prefer endpoints they operate themselves or whose
TLS certificate chain they have independently pinned. Verifiers MUST
NOT accept RPC responses over unencrypted HTTP for anchor
verification purposes.
6.12. Block Explorer Spoofing
A Voyager URL included in an audit submission is a supplementary
human-readable convenience. An adversary controlling a domain
similar to voyager.online or sepolia.voyager.online may display
fabricated transaction data. Auditors relying solely on a browser
visit to a Voyager URL, without independently verifying the anchor
tuple via the Starknet JSON-RPC, cannot distinguish canonical chain
data from spoofed presentation.
Mitigation: the normative audit check is the anchor tuple
verification via the Starknet JSON-RPC, not the Voyager URL. Audit
frameworks MUST perform RPC verification as the authoritative step.
Voyager URLs are RECOMMENDED as a supplementary aid for human
reviewers; they MUST NOT be the sole verification artefact.
Implementations MUST NOT cite any block explorer other than Voyager
as the canonical visual audit surface for Starknet; the specification
does not endorse any alternative explorer for this role.
Serafini Expires 29 November 2026 [Page 31]
Internet-Draft x402-receipts May 2026
6.13. Event Collision and Selector Ambiguity
If two Cairo contracts deployed at different addresses emit events
with the same keys[0] selector and the same keys[1] digest, a
verifier that does not check the emitting contract address may accept
the wrong anchor. This is especially relevant when a chain hosts
multiple conforming emitters.
Mitigation: verifiers MUST validate that the event was emitted by the
expected contract address. The anchor tuple (Section 5.1) identifies
the transaction but not the emitting contract; verifiers MUST cross-
reference the events[i].from_address field in the
starknet_getTransactionReceipt response against the known emitter
address before accepting the event as a valid anchor. Conforming
emitters MUST be registered in an implementation-controlled list;
events from unregistered emitters MUST be rejected.
6.14. Chain Reorganisation and Finality Window
Starknet blocks achieve L2 finality when their state update is proven
and posted to the Ethereum L1 settlement layer. Prior to L1
finalisation, a block may in principle be reorganised. A verifier
that confirms a Starknet anchor at a block that has not yet reached
L1 finality accepts a non-final commitment.
Mitigation: for settlement records that require finality guarantees
under regulatory frameworks, verifiers SHOULD wait for the Starknet
block's state update to be confirmed on Ethereum L1 before treating
the anchor as final. The Starknet JSON-RPC exposes block status
fields that allow verifiers to distinguish pending, accepted-on-L2,
and accepted-on-L1 states [STARKNET-DOCS]. Verifiers MUST NOT treat
a pending or L2-only block as providing the same finality guarantee
as an L1-confirmed block. For non-regulatory use cases (for example,
low-value instant payments), L2 acceptance MAY be sufficient;
implementations MUST document their chosen finality threshold.
6.15. Chain Identifier Confusion
An anchor tuple carrying chain_id: "SN_SEPOLIA" references a testnet
where tokens have no economic value. A verifier that does not
validate the chain_id field against its expected deployment
environment may accept a testnet anchor as proof of mainnet
settlement.
Mitigation: verifiers MUST reject anchors whose chain_id does not
match the deployment environment they are configured to verify.
Production payment processors MUST be configured to accept only
chain_id: "SN_MAIN". Test environments that accept chain_id:
Serafini Expires 29 November 2026 [Page 32]
Internet-Draft x402-receipts May 2026
"SN_SEPOLIA" MUST be segregated from production verification
pipelines. The facilitator MUST include the chain_id in the anchor
tuple; a missing chain_id MUST be treated as a malformed anchor and
MUST be rejected.
6.16. felt252 Mask and On-Chain Comparison
The felt252 masking operation described in Section 5.4 is a
deterministic transformation, not a cryptographic weakening.
Implementations that omit the mask at verification time will silently
produce false-negative verification results for receipts whose
SHA-256 digest has non-zero bits in positions 251 through 255. Such
false negatives do not create a security vulnerability (they deny
valid receipts rather than accept invalid ones), but they create an
operational failure mode in production payment pipelines.
Implementations SHOULD test the mask against a receipt whose
action_ref digest has a known non-zero high bit before deploying to
production.
6.17. Facilitator Trust Boundary
The security model of this extension assumes facilitator integrity
for receipt issuance. A compromised facilitator can issue false
receipts regardless of the cryptographic variant. The extension does
not provide a mechanism to verify that the facilitator was itself
uncompromised at the time of issuance. Verifiers that require a
trust-minimised settlement proof SHOULD combine the stark-vauban-
pay-v1 receipt with a Starknet on-chain anchor per Section 5. The
combination reduces the trust assumption from "facilitator integrity
at issuance" to "facilitator integrity at the single-step anchor
emission to the canonical ledger". An auditor re-verifying in year N
then relies on the chain's canonical history, not on the
facilitator's continued availability.
6.18. Retention-Property Determinism
The canonical preimage discipline in Section 3.4 produces a digest
that two observers verifying at the same instant compute identically.
For receipts emitted under a regulatory framework with a statutory
retention obligation, the property MUST also hold across time: a
supervisor or auditor re-verifying in year N against a retained off-
VM manifest of the receipt MUST reproduce the same digest as the
original verifier did at issuance time.
This raises a versioning concern. If the canonical rule (JCS, type-
validation, field-name canonicalisation, Unicode normalisation
policy) is revised between issuance and re-verification, the retained
receipt becomes unreproducible under the then-current rule.
Serafini Expires 29 November 2026 [Page 33]
Internet-Draft x402-receipts May 2026
Verifier-side coercion of non-conforming inputs (rather than
rejection) further breaks re-verifiability because the coercion step
is verifier-local and is not replayed at audit time.
Producers emitting receipts under frameworks with statutory retention
obligations (MiCA Art. 80, AMLR Art. 56, DORA Art. 14) MUST
therefore:
* Include the canonicalisation version marker in a canon_version
field in the receipt preimage at emission time. The value MUST be
a registered x402 canonicalisation version identifier; the JCS
discipline validated in [X402-CANON] is identified by the wire-
format marker jcs-rfc8785-v1. A future verifier selects the
contemporaneous rule by this marker rather than applying the then-
current rule.
* Reject (not coerce) non-conforming inputs at the parse or schema-
validation step, preserving re-verifiability against the raw
retained object.
Producers emitting receipts outside such frameworks SHOULD include
canon_version as a good-discipline default; the field becomes a MUST
under any framework that imposes a statutory retention horizon.
6.19. Timing Side-Channel Risks in STARK Proof Generation
STARK proof generation for the stark-vauban-pay-v1 variant is
computationally intensive and its duration correlates with the
witness size. On shared infrastructure, an adversary observing proof
generation latency MAY be able to infer approximate witness content
(for example, payment amount magnitude or attestation complexity).
Mitigation: implementors SHOULD run proof generation in isolated
compute environments (dedicated VMs or sandboxed processes) and
SHOULD add randomised padding to the proof generation timeline where
latency is observable by external parties. Implementations operating
in regulated sectors SHOULD document their timing-side-channel
posture in the operational deployment documentation.
6.20. Open Research Items
The composition properties of payment claims across receipt formats,
lifecycle states, and delegation chains are under active
investigation in the companion documents [VPSF-ALGEBRA],
[LIFECYCLE-FSM], and [DELEGATION-BINDING]. The composition algebra
is not in scope for this document; implementations of the
consolidated receipt-format, post-quantum discipline, and on-chain
anchor SHOULD treat composition properties as working hypotheses
Serafini Expires 29 November 2026 [Page 34]
Internet-Draft x402-receipts May 2026
pending the publication of the companion specifications. A companion
paper covering the formal treatment is planned for submission to IACR
ePrint; implementors are directed there for the formal analysis once
published.
7. IANA Considerations
This document makes no request for IANA action.
The registry described as x402 Receipt Format is an internal registry
maintained by the x402 Foundation Technical Steering Committee, not
an IANA registry. The registration procedure is Specification
Required [RFC8126], with Designated Experts selected by the Technical
Steering Committee. No allocation in this document requires IETF
Review or Standards Action.
The chain identifier values "SN_MAIN" and "SN_SEPOLIA" are Starknet-
native identifiers documented in [STARKNET-DOCS]; they are not IANA-
registered tokens. The kind discriminant values ("settlement",
"refund", "delegation") derive from the lifecycle state names defined
in [LIFECYCLE-FSM]; they do not require separate IANA registration in
this specification.
Future per-chain adapter specifications that introduce new chain_id
values SHOULD define a registration mechanism within the x402
Foundation registry structure rather than reserving values through
IANA.
8. Conformance Checklist
An implementation claiming conformance to this consolidated
specification MUST satisfy the following, organised by section.
Receipt format (Section 3):
* Produce and parse all three receipt format tokens.
* Set X-Payment-Options on 402 responses listing supported tokens.
* Set X-Receipt-Format on all PAYMENT-RESPONSE messages.
* Fall back to classical-es256k when the client sends no
receipt_format preference.
* Return HTTP 402 with UnsupportedReceiptFormat when a client
requests a variant with required: true that the facilitator cannot
produce.
Serafini Expires 29 November 2026 [Page 35]
Internet-Draft x402-receipts May 2026
Preimage discipline (Section 3.4):
* Reject float values for timestamp_ms before JCS canonicalisation.
* Reject preimage objects with missing canonical fields before JCS
canonicalisation.
* Reject preimage objects with duplicate keys at parse time.
* Normalise all preimage string values to NFC per [UAX15] before JCS
canonicalisation, and reject non-NFC input.
* Pass every vector in the conformance suite at
[VAUBAN-CONFORMANCE].
Post-quantum discipline (Section 4):
* Cover the byte-identical JCS canonical preimage with both
component signatures of any hybrid-pqc receipt.
* Reject hybrid-pqc receipts where either component signature fails
to verify.
* Use a hash-based proof system for any receipt variant claiming
post-quantum proof-layer soundness.
On-chain anchor (Section 5):
* Produce a well-formed anchor tuple for each submitted settlement.
* Include chain_id, tx_hash, event_index, and kind in every anchor
tuple.
* Apply the felt252 mask consistently at both event emission time
and verification time.
* Validate the emitter contract address against the known-good
emitter address before accepting an event as a valid anchor.
* Reject anchors whose chain_id does not match the configured
deployment environment.
* Distinguish pending, L2-accepted, and L1-accepted block states and
apply the appropriate finality threshold for the use case.
* Cite Voyager as the canonical visual audit surface for Starknet,
and not cite any other explorer in audit submissions.
Serafini Expires 29 November 2026 [Page 36]
Internet-Draft x402-receipts May 2026
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.
Vauban Pay (https://pay.vauban.tech) maintains the reference
specification, the published conformance vectors (https://github.com/
vauban-org/x402-stark-receipts-conformance), the multi-language
runner matrix described in Section 3.10, and the on-chain reference
deployment. The Vauban Pay live demonstration [VAUBAN-DEMO] emits
compliant payloads at https://demo.pay.vauban.tech. The on-chain
anchor PaymentDemoEmitter is deployed on Starknet Sepolia at contract
0x044dd87a94a801cf775d4c5e4b6703102d4e97e1cd1d0a8879341219ae4f19ff
(Voyager-verified at https://sepolia.voyager.online/
contract/0x044dd87a94a801cf775d4c5e4b6703102d4e97e1cd1d0a8879341219ae4f19ff).
The Starknet RPC reference endpoint is a self-hosted Pathfinder
validator [PATHFINDER] at https://sepolia.rpc.vauban.tech/rpc/v0_10.
The published Vauban Pay packages across three ecosystems are:
* crates.io: vauban-x402-jcs-conformance@0.1.0, vauban-
x402-canonical@0.1.0, vauban-x402-wire@0.1.0
* PyPI: vauban-x402-stark-receipt@0.1.0
* npm: @vauban-pay/substrate@0.1.0
All packages are released under Apache 2.0.
Implementers SHOULD notify the contact at research@vauban.tech when
adopting this specification in production. Adoption notifications
include the production endpoint or product identifier, the emitted
canon_version value, the JCS implementation library and version, the
deployed emitter contract address with chain identifier (where
applicable), the RPC endpoint provenance (self-hosted versus third-
party), and a 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.
Acknowledgments
This consolidated document folds material developed across the x402
Linux Foundation V2 coalition review tracks [X402-2357], [X402-2398],
[X402-2411], [X402-2412], [X402-2413], [X402-2434], [X402-2440], and
[X402-2459]. The editor thanks the following contributors by name:
Serafini Expires 29 November 2026 [Page 37]
Internet-Draft x402-receipts May 2026
* FeedOracle, for the hybrid-PQC reference implementation and the
receipt-core fixture set landed at [X402-2411].
* andysalvo, for the action-ref-verify v0.3.0 conformance vectors
landed at [X402-2398], which materially shaped the JCS preimage
discipline profiled in Section 3.
* egoriklok, for the x402 maintainer review summary at [X402-2459],
which consolidated the substrate-and-axes architecture and
clarified the boundary between the receipt-format extension and
the deferred composability layer.
* The Vauban Research engineering team, for the collective drafting,
conformance-vector publication, multi-language runner matrix, on-
chain demo surface, and editorial discipline across the three
folded source drafts.
The JCS canonicalisation discipline referenced in Section 3.4 is
grounded in [RFC8785] and validated by independent runner
implementations against published conformance suites [X402-CANON].
The Stwo Circle STARK M31 prover [STWO] is the open-source reference
for the hash-based proving system underlying the stark-vauban-pay-v1
variant. The Starknet JSON-RPC specification [STARKNET-DOCS] and the
Pathfinder full node [PATHFINDER] provide the on-chain infrastructure
that the anchor format targets. The Voyager block explorer [VOYAGER]
provides the canonical human-readable audit surface.
References
Normative References
[FIPS204] National Institute of Standards and Technology, "Module-
Lattice-Based Digital Signature Standard (ML-DSA)", August
2024, <https://doi.org/10.6028/NIST.FIPS.204>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
Serafini Expires 29 November 2026 [Page 38]
Internet-Draft x402-receipts May 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[SP800-208]
National Institute of Standards and Technology,
"Recommendation for Stateful Hash-Based Signature
Schemes", October 2020,
<https://doi.org/10.6028/NIST.SP.800-208>.
Informative References
[ANSSI-PQC]
Agence nationale de la securite des systemes
d'information, "ANSSI Position Paper on Post-Quantum
Cryptography Migration", n.d.,
<https://cyber.gouv.fr/en/publications/anssi-views-post-
quantum-cryptography>.
[BSI-PQC] Bundesamt fur Sicherheit in der Informationstechnik, "BSI
Technical Guideline TR-02102 (cryptographic mechanisms)",
n.d., <https://www.bsi.bund.de/EN/Themen/Unternehmen-und-
Organisationen/Standards-und-Zertifizierung/Technische-
Richtlinien/TR-nach-Thema-sortiert/tr02102/
tr02102_node.html>.
Serafini Expires 29 November 2026 [Page 39]
Internet-Draft x402-receipts May 2026
[DELEGATION-BINDING]
"x402 V2 Delegation Binding (companion work, out of
scope)", n.d., <https://datatracker.ietf.org/doc/draft-
vauban-x402-delegation-binding/>.
[EIDAS-2] European Parliament and Council, "Regulation (EU)
2024/1183 amending Regulation (EU) No 910/2014 (eIDAS
2.0)", April 2024,
<https://eur-lex.europa.eu/eli/reg/2024/1183/oj>.
[FIPS203] National Institute of Standards and Technology, "Module-
Lattice-Based Key-Encapsulation Mechanism Standard (ML-
KEM)", August 2024,
<https://doi.org/10.6028/NIST.FIPS.203>.
[LIFECYCLE-FSM]
"x402 V2 Payment Lifecycle Finite State Machine (companion
work, out of scope)", n.d.,
<https://datatracker.ietf.org/doc/draft-vauban-x402-
lifecycle-fsm/>.
[NIST-PQC-MIGRATION]
National Institute of Standards and Technology, "Post-
Quantum Cryptography Migration Roadmap", n.d.,
<https://csrc.nist.gov/projects/post-quantum-
cryptography>.
[PATHFINDER]
"Pathfinder Starknet full node (eqlabs)", n.d.,
<https://github.com/eqlabs/pathfinder>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[STARKNET-DOCS]
"Starknet Documentation and JSON-RPC Specification", n.d.,
<https://docs.starknet.io>.
[STWO] "Stwo Circle STARK Prover (StarkWare Industries)", n.d.,
<https://github.com/starkware-libs/stwo>.
[UAX15] Unicode Consortium, "Unicode Normalization Forms", Unicode
Standard Annex #15, 2023,
<https://www.unicode.org/reports/tr15/>.
Serafini Expires 29 November 2026 [Page 40]
Internet-Draft x402-receipts May 2026
[VAUBAN-CONFORMANCE]
"Vauban STARK receipt conformance vectors (public)", n.d.,
<https://github.com/vauban-org/x402-stark-receipts-
conformance/blob/main/manifest.json>.
[VAUBAN-DEMO]
"Vauban Pay reference demonstration (Starknet Sepolia)",
n.d., <https://demo.pay.vauban.tech>.
[VOYAGER] "Voyager Starknet Block Explorer", n.d.,
<https://voyager.online>.
[VPSF-ALGEBRA]
"VPSF Claim Algebra for x402 Payment Receipts (companion
work, out of scope)", n.d.,
<https://datatracker.ietf.org/doc/draft-vauban-x402-vpsf-
algebra/>.
[X402-2322]
"x402 evidenceType taxonomy and composite trust-query
alignment (discussion thread)", n.d.,
<https://github.com/x402-foundation/x402/issues/2322>.
[X402-2326]
"x402 shared canonicalisation discipline (coalition
discussion thread)", n.d.,
<https://github.com/x402-foundation/x402/issues/2326>.
[X402-2357]
"x402 STARK Receipts Extension Proposal", n.d.,
<https://github.com/x402-foundation/x402/issues/2357>.
[X402-2398]
"action-ref-verify v0.3.0 conformance vectors", n.d.,
<https://github.com/x402-foundation/x402/pull/2398>.
[X402-2411]
"Hybrid-PQC receipt-core fixture set (Axis 2)", n.d.,
<https://github.com/x402-foundation/x402/pull/2411>.
[X402-2412]
"Canonicalisation substrate v0 fixtures (Axis 0, 53
vectors)", n.d.,
<https://github.com/x402-foundation/x402/pull/2412>.
[X402-2413]
"stark-vauban-pay-v1 v0 fixtures (Axis 1)", n.d.,
<https://github.com/x402-foundation/x402/pull/2413>.
Serafini Expires 29 November 2026 [Page 41]
Internet-Draft x402-receipts May 2026
[X402-2434]
"risk-check-attestation-sample v0 (compliance-receipt
fixture, ALLOW/DENY/REFER)", n.d.,
<https://github.com/x402-foundation/x402/pull/2434>.
[X402-2440]
"Composite trust-query normative layer (Axis 4)", n.d.,
<https://github.com/x402-foundation/x402/pull/2440>.
[X402-2459]
"x402 maintainer review summary (egoriklok)", n.d.,
<https://github.com/x402-foundation/x402/pull/2459>.
[X402-CANON]
"x402 canonicalisation substrate v0 conformance vectors
(53 vectors, Axis 0)", n.d.,
<https://github.com/x402-foundation/x402/pull/2412>.
[X402-V2] "x402 Linux Foundation V2 Working Group", n.d.,
<https://github.com/x402-foundation/x402>.
Author's Address
F. Serafini (editor)
Vauban Research
Email: research@vauban.tech
URI: https://pay.vauban.tech
Serafini Expires 29 November 2026 [Page 42]