x402 STARK Receipt Format Extension
draft-vauban-x402-stark-receipts-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-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vauban-x402-stark-receipts-00
Independent Submission V. Research
Internet-Draft Vauban Research
Intended status: Informational 21 May 2026
Expires: 22 November 2026
x402 STARK Receipt Format Extension
draft-vauban-x402-stark-receipts-00
Abstract
The x402 PAYMENT-RESPONSE carries a facilitator-issued settlement
reference but does not provide a self-contained, offline-verifiable
payment-condition proof. A verifier must today contact the
facilitator to confirm whether a specific amount, currency, and payer
attestation were satisfied at the time of payment. This gap prevents
compliance with EU AI Act Art. 12 (transparency and documentation)
and MiCA Art. 76 (settlement record-keeping) in automated payment
pipelines.
This document defines the receipt-format extension for x402 V2. The
extension introduces a negotiable receipt format selection mechanism
that allows resource servers, facilitators, and clients to agree on
which cryptographic receipt variant to produce and verify, without
altering the core PAYMENT-RESPONSE wire structure. Three variants
are defined: a Stwo Circle STARK proof of payment conditions (post-
quantum sound, offline verifiable), a hybrid ES256K + ML-DSA-65 dual-
signature receipt (receipt integrity under quantum adversary), and a
classical ES256K fallback. A canonical preimage discipline using JCS
([RFC8785]) ensures cross-implementation digest consistency.
This specification reflects three-implementation consensus
established in [X402-2357].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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."
Research Expires 22 November 2026 [Page 1]
Internet-Draft x402-stark-receipts May 2026
This Internet-Draft will expire on 22 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
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Receipt Format Enum . . . . . . . . . . . . . . . . . . . . . 5
4. HTTP Header Conventions . . . . . . . . . . . . . . . . . . . 6
4.1. X-Payment-Options (402 response, server to client) . . . 6
4.2. X-Receipt-Format (PAYMENT-RESPONSE, facilitator to
client) . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Negotiation Semantics . . . . . . . . . . . . . . . . . . . . 7
5.1. Normal Negotiation Path . . . . . . . . . . . . . . . . . 7
5.2. Fallback Behaviour . . . . . . . . . . . . . . . . . . . 7
5.3. Mandatory-Format Signalling . . . . . . . . . . . . . . . 8
6. Error Taxonomy . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. HTTP Status Code Mapping . . . . . . . . . . . . . . . . 8
6.2. X-Receipt-Reject-Reason Format . . . . . . . . . . . . . 9
7. Canonical Preimage Discipline . . . . . . . . . . . . . . . . 9
7.1. timestamp_ms Is the Canonical Field Name . . . . . . . . 10
7.2. Preimage Schema . . . . . . . . . . . . . . . . . . . . . 10
7.3. Type Validation Requirements . . . . . . . . . . . . . . 11
7.4. Unicode Normalisation . . . . . . . . . . . . . . . . . . 11
7.5. Trailing Whitespace and Extra Fields . . . . . . . . . . 12
8. Wire-Level Binding (action_ref): Pure 32-Byte Hash,
Layer-Agnostic . . . . . . . . . . . . . . . . . . . . . 12
9. PaymentRequired Extension Schema . . . . . . . . . . . . . . 12
10. PAYMENT-SIGNATURE Extension Schema . . . . . . . . . . . . . 14
11. PAYMENT-RESPONSE Extension Schema . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12.1. Registry: x402 Receipt Format . . . . . . . . . . . . . 15
12.1.1. Registry Fields . . . . . . . . . . . . . . . . . . 16
12.1.2. Naming Convention . . . . . . . . . . . . . . . . . 16
12.1.3. Status Transitions . . . . . . . . . . . . . . . . . 16
12.1.4. Initial Registry Values . . . . . . . . . . . . . . 17
13. Security Considerations . . . . . . . . . . . . . . . . . . . 18
Research Expires 22 November 2026 [Page 2]
Internet-Draft x402-stark-receipts May 2026
13.1. Canonical Preimage Validation Before Content
Processing . . . . . . . . . . . . . . . . . . . . . . . 18
13.2. Replay Attack Mitigation . . . . . . . . . . . . . . . . 18
13.3. Timing Side-Channel Risks in STARK Proof Generation . . 18
13.4. Privacy Implications of Receipt Sharing . . . . . . . . 18
13.5. Forward Secrecy Under Quantum Adversary . . . . . . . . 19
13.6. Facilitator Trust Boundary . . . . . . . . . . . . . . . 19
13.7. Retention-Property Determinism
(Cross-Observer-Across-Time) . . . . . . . . . . . . . . 19
13.8. Open Research Conjectures . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Variant-Specific Receipt Bodies . . . . . . . . . . 22
A.1. stark-vauban-pay-v1 . . . . . . . . . . . . . . . . . . . 23
A.2. hybrid-pqc . . . . . . . . . . . . . . . . . . . . . . . 23
A.3. classical-es256k . . . . . . . . . . . . . . . . . . . . 24
Appendix B. Conformance Checklist . . . . . . . . . . . . . . . 24
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
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 currently carries a payment_hash and a
facilitator-issued settlement reference. However, it does not
include a self-contained cryptographic receipt that a downstream
verifier can check offline, without contacting the facilitator.
This limitation creates a compliance gap in two regulatory
frameworks:
* EU AI Act Art. 12 requires that automated decision-making systems
maintain transparent, auditable records. A payment pipeline that
cannot produce an offline-verifiable receipt cannot satisfy this
requirement without a facilitator callback.
* MiCA Art. 76 requires settlement record-keeping for crypto-asset
service providers. A facilitator-issued reference alone is
insufficient when the verifying party is not the original payment
processor.
Research Expires 22 November 2026 [Page 3]
Internet-Draft x402-stark-receipts May 2026
The receipt-format extension addresses this gap by enabling
negotiation of three cryptographic receipt variants, each optimised
for a different compliance or security property. The extension is
additive: it does not modify the core PAYMENT-RESPONSE structure, and
it defaults safely to a classical ES256K fallback for implementations
that do not require ZK or post-quantum properties.
Three independent implementations established consensus on the
extension semantics and wire format in [X402-2357]:
* Vauban zkpay (Rust, Apache 2.0): STARK receipt generation and
verification
* FeedOracle Grounding Receipt v0.4: hybrid PQC dual-signature
* andysalvo action-ref-verify v0.3.0: canonical preimage conformance
suite
Conformance test vectors are published in [X402-2398] (9 vectors in
fixtures/action-ref-verify/v0/).
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.
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.
The following terms are used throughout this document:
Receipt format: A string token identifying which cryptographic
receipt variant a facilitator produces. See Section 3.
JCS: JSON Canonicalization Scheme, defined in [RFC8785]. Produces a
deterministic byte representation of a JSON value by applying
recursive key sorting and value normalization.
action_ref: A 32-byte opaque digest binding a payment receipt to a
work-layer event. Derived by SHA-256 over the UTF-8 JCS encoding
of a canonical preimage object. See Section 8.
payment_hash: A hash of the payment conditions committed to by the
payer, as defined in the x402 V2 base specification ([X402-V2]).
Research Expires 22 November 2026 [Page 4]
Internet-Draft x402-stark-receipts May 2026
Facilitator: An entity that processes x402 payment requests,
verifies payment conditions, and issues PAYMENT-RESPONSE messages.
The term is used as defined in [X402-V2].
NFC: Unicode Normalization Form C, as defined in [UAX15].
3. 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 defined in Section 12:
+=====================+==================================+=========+
| 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. | |
| | Offline verifiable. | |
+---------------------+----------------------------------+---------+
| hybrid-pqc | ES256K + ML-DSA-65 ([FIPS204]) | ~3.3 KB |
| | dual-signature over JCS- | |
| | canonical receipt core. Receipt | |
| | survives Q-Day independently of | |
| | proof system upgrade. | |
+---------------------+----------------------------------+---------+
| classical-es256k | ES256K signature only. Default | ~0.5 KB |
| | fallback for clients that do not | |
| | require post-quantum or ZK | |
| | 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:
Research Expires 22 November 2026 [Page 5]
Internet-Draft x402-stark-receipts May 2026
+======================+=====================+
| 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 defined in Section 12. Tokens not
present in the registry MUST be treated as "classical-es256k" by
verifiers that do not recognise them.
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 8). Binding
to the work layer is a property of the preimage derivation, not of
the receipt format itself.
4. HTTP Header Conventions
4.1. X-Payment-Options (402 response, server to client)
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.
Research Expires 22 November 2026 [Page 6]
Internet-Draft x402-stark-receipts May 2026
If X-Payment-Options is absent, the client MUST assume the
facilitator can produce only classical-es256k.
4.2. X-Receipt-Format (PAYMENT-RESPONSE, facilitator to client)
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.
5. Negotiation Semantics
5.1. Normal Negotiation Path
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 to the facilitator by
including receipt_format in the PAYMENT-SIGNATURE request payload
(see Section 10).
4. Facilitator produces the receipt in the selected variant and sets
X-Receipt-Format on the PAYMENT-RESPONSE.
5.2. Fallback Behaviour
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.
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.
Research Expires 22 November 2026 [Page 7]
Internet-Draft x402-stark-receipts May 2026
5.3. Mandatory-Format Signalling
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:
{
"extensions": {
"receipt-format": {
"info": {
"required": true,
"receipt_format": "stark-vauban-pay-v1"
}
}
}
}
If required is true and the facilitator cannot produce the requested
variant, the facilitator MUST return HTTP 402 with error
UnsupportedReceiptFormat (see Section 6) rather than silently
downgrading.
If required is false (or absent), the facilitator MAY downgrade to
the highest variant it supports.
6. Error Taxonomy
When the facilitator or resource server rejects a payment due to a
condition attributable to this extension, it SHOULD include the X-
Receipt-Reject-Reason header with a machine-readable semantic
discriminator. The header supplements the HTTP status code; it does
not replace it.
X-Receipt-Reject-Reason: NullifierReplay
6.1. HTTP Status Code Mapping
+========+==========================+===============================+
| Status | Reason token | Description |
+========+==========================+===============================+
| 400 | MalformedClaim | Malformed CBOR or invalid |
| | | JCS in the request body. |
| | | Parse failed before |
| | | validation. |
+--------+--------------------------+-------------------------------+
| 402 | PaymentRequired | Generic unmet payment |
| | | condition: amount mismatch, |
Research Expires 22 November 2026 [Page 8]
Internet-Draft x402-stark-receipts May 2026
| | | invalid proof, payer |
| | | attestation failed. |
+--------+--------------------------+-------------------------------+
| 402 | UnsupportedReceiptFormat | Client requested a |
| | | receipt_format with |
| | | required: true that the |
| | | facilitator cannot produce. |
+--------+--------------------------+-------------------------------+
| 409 | NullifierReplay | Nullifier already settled. |
| | | Double-spend attempt |
| | | detected. The PAYMENT- |
| | | RESPONSE MUST NOT be issued. |
+--------+--------------------------+-------------------------------+
| 410 | Expired | TemporalFrame window has |
| | | elapsed. The payment cannot |
| | | be settled. |
+--------+--------------------------+-------------------------------+
| 422 | StructuralInvalid | Claim structure violates the |
| | | VPSF sextuplet invariant. |
| | | Structurally unprocessable. |
+--------+--------------------------+-------------------------------+
| 451 | HumanityRequired | Merchant requires a |
| | | humanity-binding |
| | | attestation; payer is |
| | | anonymous and cannot satisfy |
| | | the requirement. |
+--------+--------------------------+-------------------------------+
Table 3
6.2. X-Receipt-Reject-Reason Format
The header value MUST be exactly one reason token from the table
above. Verifiers MUST treat unknown tokens as equivalent to the
corresponding HTTP status code with no additional semantics.
Facilitators SHOULD include the header on all non-2xx responses in
this extension's domain. The header is OPTIONAL on 5xx responses.
7. Canonical Preimage Discipline
This section records the three-implementation agreement reached in
[X402-2357] and confirmed by all three coalition fixtures.
Research Expires 22 November 2026 [Page 9]
Internet-Draft x402-stark-receipts May 2026
7.1. timestamp_ms Is the Canonical Field Name
The action_ref preimage object MUST use the field name timestamp_ms
with an integer value representing milliseconds since the Unix epoch
(1970-01-01T00:00:00 UTC). The field name timestamp (RFC 3339
string) MUST NOT be used as the canonical preimage field.
Rationale:
1. RFC 3339 strings permit multiple encodings for the same instant
(.000 suffix, Z vs +00:00, varying fractional precision) that
produce different JCS bytes even when semantically identical.
Vector 0009-field-name-load-bearing from [X402-2398] demonstrates
this failure mode.
2. The integer encoding is shorter in JCS canonical bytes, reducing
the preimage attack surface.
3. All three published fixtures already use timestamp_ms (epoch
integer).
7.2. Preimage Schema
The canonical action_ref preimage object contains the following
fields, sorted in [RFC8785] lexicographic order for JCS
canonicalisation:
{
"action_type": "<string>",
"agent_id": "<string>",
"scope": "<string>",
"timestamp_ms": <integer>
}
Implementations MUST sort keys lexicographically before serialising
([RFC8785] Section 3.2.3). 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
Research Expires 22 November 2026 [Page 10]
Internet-Draft x402-stark-receipts May 2026
7.3. 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. Vector 0002-ms-precision-
trap from [X402-2398] 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. See proposed vector 0012-missing-
canonical-field.
* *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. See
proposed vector 0010-duplicate-keys.
7.4. Unicode Normalisation
[RFC8785] (JCS) performs no Unicode normalisation on string values.
Two strings that are semantically equivalent but differ in Unicode
normalization form (for example NFC vs NFD per [UAX15]) will produce
different JCS bytes and therefore different digests.
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 a non-NFC form (NFD, NFKC, or NFKD).
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; this is not a hypothetical edge case.
See proposed companion vector 0011-unicode-normalisation (NFD
divergence test case) for a concrete failure mode demonstration.
Research Expires 22 November 2026 [Page 11]
Internet-Draft x402-stark-receipts May 2026
7.5. Trailing Whitespace and Extra Fields
Vector 0003-trailing-whitespace from [X402-2398] confirms that
trailing whitespace in string values is significant in JCS.
Implementations MUST NOT strip trailing whitespace before
canonicalisation.
Vector 0004-extra-field-ignored confirms that additional fields
beyond the canonical four MAY be present in the application preimage,
but MUST be sorted in JCS order and included in the digest if
present. The canonical binding covers whatever fields were
serialised.
8. Wire-Level Binding (action_ref): Pure 32-Byte Hash, Layer-Agnostic
The action_ref field in any receipt variant is an opaque 32-byte
digest. It MUST be encoded as base64url ([RFC4648] Section 5, no
padding) in JSON payloads and as raw bytes in CBOR payloads.
{
"action_ref": "ENijjAHYZyF2qm5SCaNo_ePhgxZA1p4VKDFCS1iAwsE"
}
The receipt format does not interpret the action_ref preimage. The
preimage derivation is defined by the work layer (see Section 7.2 for
the canonical formula). The receipt stores 32 opaque bytes and emits
them on demand.
Both stark-vauban-pay-v1 and hybrid-pqc receipts carry the same
action_ref bytes when bound to the same work event. This is the
binding seam: a verifier confirms that the payment (receipt) and the
work output (work-layer receipt referencing action_ref) are causally
linked without coupling the two proof systems.
The action_ref field is OPTIONAL in all three receipt variants. A
facilitator that does not support work-receipt binding MUST omit the
field rather than emit a zero-value or null.
The verifier MUST NOT require action_ref to be present. A missing
action_ref means no binding was asserted; it is not a validation
error.
9. PaymentRequired Extension Schema
When a resource server supports receipt-format negotiation, it
includes the extension in the PaymentRequired response body:
Research Expires 22 November 2026 [Page 12]
Internet-Draft x402-stark-receipts May 2026
{
"x402Version": 2,
"error": "Payment required",
"resource": {
"url": "https://api.example.com/compliance-check",
"description": "Sanctions screening service; STARK receipt required for EU AI Act Art. 12"
},
"accepts": [
{
"scheme": "exact",
"network": "eip155:8453",
"amount": "50000",
"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"payTo": "0xPaymentAddress",
"maxTimeoutSeconds": 60
}
],
"extensions": {
"receipt-format": {
"info": {
"supported": ["stark-vauban-pay-v1", "hybrid-pqc", "classical-es256k"],
"default": "classical-es256k"
}
}
}
}
The receipt-format extension fields in the PaymentRequired body are:
+===========+==========+==========+===============================+
| Field | Type | Required | Description |
+===========+==========+==========+===============================+
| supported | string[] | REQUIRED | Ordered list of |
| | | | receipt_format tokens the |
| | | | facilitator can produce; |
| | | | descending preference. |
+-----------+----------+----------+-------------------------------+
| default | string | OPTIONAL | Token to use if the client |
| | | | sends no receipt_format |
| | | | preference. MUST be present |
| | | | in supported. Defaults to |
| | | | "classical-es256k" if absent. |
+-----------+----------+----------+-------------------------------+
Table 4
Research Expires 22 November 2026 [Page 13]
Internet-Draft x402-stark-receipts May 2026
10. PAYMENT-SIGNATURE Extension Schema
A client that requires a specific receipt format signals its
preference in the PAYMENT-SIGNATURE request:
{
"extensions": {
"receipt-format": {
"info": {
"required": false,
"receipt_format": "hybrid-pqc"
}
}
}
}
The receipt-format extension fields in the PAYMENT-SIGNATURE body
are:
+================+=========+==========+===========================+
| Field | Type | Required | Description |
+================+=========+==========+===========================+
| receipt_format | string | OPTIONAL | The token the client |
| | | | requests. |
+----------------+---------+----------+---------------------------+
| required | boolean | OPTIONAL | If true, the facilitator |
| | | | MUST produce the |
| | | | requested variant or |
| | | | return HTTP 402 with |
| | | | UnsupportedReceiptFormat. |
| | | | Default: false. |
+----------------+---------+----------+---------------------------+
Table 5
11. PAYMENT-RESPONSE Extension Schema
The facilitator confirms the emitted variant in the PAYMENT-RESPONSE:
Research Expires 22 November 2026 [Page 14]
Internet-Draft x402-stark-receipts May 2026
{
"extensions": {
"receipt-format": {
"info": {
"receipt_format": "stark-vauban-pay-v1",
"receipt": "<base64url-encoded-receipt-body>",
"action_ref": "ENijjAHYZyF2qm5SCaNo_ePhgxZA1p4VKDFCS1iAwsE"
}
}
}
}
The receipt-format extension fields in the PAYMENT-RESPONSE body are:
+================+========+==========+=============================+
| Field | Type | Required | Description |
+================+========+==========+=============================+
| receipt_format | string | REQUIRED | The token identifying which |
| | | | variant was produced. |
+----------------+--------+----------+-----------------------------+
| receipt | string | REQUIRED | base64url-encoded receipt |
| | | | body. Format is variant- |
| | | | specific (see Appendix A). |
+----------------+--------+----------+-----------------------------+
| action_ref | string | OPTIONAL | base64url-encoded 32-byte |
| | | | work-receipt binding digest |
| | | | (Section 8). |
+----------------+--------+----------+-----------------------------+
Table 6
12. IANA Considerations
12.1. Registry: x402 Receipt Format
This document requests IANA to create a new registry named x402
Receipt Format in the x402 Protocol Extensions registry group (to be
established by the x402 Foundation TSC in coordination with IANA).
*Registration procedure*: Specification Required (per [RFC8126]
Section 4.6). A Designated Expert MUST review each registration
request to confirm the specification is publicly available, the token
follows the naming convention in Section 12.1.2, and no token
collision exists with a currently registered value.
Research Expires 22 November 2026 [Page 15]
Internet-Draft x402-stark-receipts May 2026
*Designated Experts*: The initial Designated Experts pool MUST be
selected by the x402 Foundation TSC at the time of registry creation.
The TSC MAY rotate Designated Experts by consensus. A minimum of two
active Designated Experts MUST be maintained at all times.
12.1.1. Registry Fields
Each registered value MUST include the following fields:
+===========+======================================================+
| Field | Description |
+===========+======================================================+
| Name | The receipt_format token string. MUST match |
| | [a-z][a-z0-9-]* (lowercase alphanumeric and hyphen). |
+-----------+------------------------------------------------------+
| Reference | URL to the specification or authoritative test |
| | fixture defining the wire format. |
+-----------+------------------------------------------------------+
| Status | One of: Stable, Provisional, Deprecated, Obsolete. |
+-----------+------------------------------------------------------+
| Contact | Name or organisation responsible for the |
| | registration. |
+-----------+------------------------------------------------------+
| Notes | Optional free-text notes on implementation or |
| | compatibility constraints. |
+-----------+------------------------------------------------------+
Table 7
12.1.2. Naming Convention
New receipt_format tokens SHOULD follow the pattern <scheme>-<vendor-
or-family>-vN (for example: stark-vauban-pay-v1, hybrid-pqc,
classical-es256k). The pattern is RECOMMENDED for clarity but not
enforced by the Designated Expert review. Tokens that deviate MUST
include a Notes explanation.
12.1.3. Status Transitions
* *Provisional to Stable*: requires (a) two independent
interoperable implementations whose conformance against the
reference specification has been demonstrated publicly, and (b)
the wire format has been stable for at least one year with no
backwards-incompatible changes. A Designated Expert MUST confirm
both conditions before updating status.
Research Expires 22 November 2026 [Page 16]
Internet-Draft x402-stark-receipts May 2026
* *Stable to Deprecated*: requires a vote by the x402 Foundation TSC
with public notice of at least six months before the status change
takes effect.
* *Deprecated to Obsolete*: occurs automatically twelve months after
the Deprecated status date, unless the TSC votes to extend the
deprecation period.
* *Obsolete*: verifiers MUST NOT accept receipts of Obsolete format
variants. Facilitators MUST NOT produce Obsolete variants.
12.1.4. Initial Registry Values
The following values are registered by this document:
+==========+===================+===========+==========+==============+
|Name |Reference |Status |Contact |Notes |
+==========+===================+===========+==========+==============+
|stark- |[VAUBAN-STARK-GIST]|Provisional|Vauban |Stwo Circle |
|vauban- | | |Research |STARK M31 over|
|pay-v1 | | | |payment- |
| | | | |condition |
| | | | |witness. |
| | | | |CBOR-encoded |
| | | | |body. ~100 KB.|
+----------+-------------------+-----------+----------+--------------+
|hybrid-pqc|[FEEDORACLE-GIST] |Provisional|FeedOracle|ES256K + ML- |
| | | | |DSA-65 |
| | | | |([FIPS204]) |
| | | | |dual- |
| | | | |signature. |
| | | | |JCS-canonical |
| | | | |JSON body. |
| | | | |~3.3 KB. |
+----------+-------------------+-----------+----------+--------------+
|classical-|[X402-V2] base |Provisional|x402 |ES256K JWS |
|es256k |specification | |Foundation|Compact |
| | | | |Serialization.|
| | | | |Default |
| | | | |fallback. ~0.5|
| | | | |KB. |
+----------+-------------------+-----------+----------+--------------+
Table 8
These initial values are considered Provisional pending the Stable
promotion criteria in Section 12.1.3.
Research Expires 22 November 2026 [Page 17]
Internet-Draft x402-stark-receipts May 2026
13. Security Considerations
13.1. Canonical Preimage Validation Before Content Processing
Implementations MUST validate the canonical preimage discipline
described in Section 7 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.
13.2. Replay Attack Mitigation
The NullifierReplay error code (Section 6.1) 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 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.
13.3. Timing Side-Channel Risks in STARK Proof Generation
STARK proof generation (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.
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.
13.4. Privacy Implications of Receipt Sharing
A stark-vauban-pay-v1 receipt proves payment conditions without
revealing the witness (amount, currency, payer attestation,
nullifier). However, the action_ref digest is deterministic given
the preimage. If the preimage is known to an adversary (for example,
because the agent_id and scope are public), 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.
Research Expires 22 November 2026 [Page 18]
Internet-Draft x402-stark-receipts May 2026
The hybrid-pqc and classical-es256k receipts do not provide zero-
knowledge properties. They carry the receipt_core in cleartext (JCS-
canonical JSON). Parties sharing these receipts with third-party
verifiers SHOULD be aware that the full payment conditions are
visible to the verifier.
13.5. Forward Secrecy Under Quantum Adversary
The hybrid-pqc variant is designed to preserve receipt integrity if
either ES256K or ML-DSA-65 is broken. However, it does not provide
forward secrecy: an adversary that records receipts today and breaks
ES256K or ML-DSA-65 in the future can verify the receipt. If forward
secrecy is required, the stark-vauban-pay-v1 variant provides post-
quantum sound proof-of-payment-conditions; however, the STARK proof
system itself is subject to future cryptanalysis. This document
makes no claim about the long-term security of any specific proof
system configuration.
13.6. 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 an on-chain settlement anchor (separate from this
extension).
13.7. Retention-Property Determinism (Cross-Observer-Across-Time)
The canonical preimage discipline in Section 7 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.
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.
Research Expires 22 November 2026 [Page 19]
Internet-Draft x402-stark-receipts May 2026
Producers emitting receipts under frameworks with statutory retention
obligations (for example, MiCA Art. 80, AMLR Art. 56, DORA Art. 14)
MUST therefore :
* Include the canonical rule version (canon_version field) in the
receipt preimage at emission time, so that a future verifier
selects the contemporaneous rule rather than the then-current one.
* 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. This
subsection aligns with the shared canonicalisation discipline section
under coordination at the x402 working group ([X402-2326]).
13.8. Open Research Conjectures
Section 10 of the Vauban zkpay specification contains research
conjectures about the composition properties of payment claims under
the Vauban Proof Stack Framework. These conjectures have not been
peer-reviewed at the time of this writing. Implementors SHOULD treat
them as working hypotheses. A companion paper is planned for
submission to IACR ePrint; readers are directed there for the formal
treatment once published.
14. References
14.1. Normative References
[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>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/rfc/rfc7235>.
Research Expires 22 November 2026 [Page 20]
Internet-Draft x402-stark-receipts May 2026
[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>.
[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>.
14.2. Informative References
[ANDYSALVO-GIST]
"andysalvo action-ref-verify v0.3.0", n.d.,
<https://gist.github.com/
andysalvo/763a410497454ce78be0fd9dae26a6b4>.
[FEEDORACLE-GIST]
"FeedOracle hybrid-PQC receipt fixture", n.d.,
<https://gist.github.com/
feedoracle/704ab891170e2b43050f6f0ae00e6923>.
[FIPS204] National Institute of Standards and Technology, "Module-
Lattice-Based Digital Signature Standard (ML-DSA-65)",
2024, <https://doi.org/10.6028/NIST.FIPS.204>.
[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>.
Research Expires 22 November 2026 [Page 21]
Internet-Draft x402-stark-receipts May 2026
[UAX15] Unicode Consortium, "Unicode Normalization Forms", Unicode
Standard Annex #15, 2023,
<https://www.unicode.org/reports/tr15/>.
[VAUBAN-STARK-GIST]
"Vauban STARK receipt interop fixture v0.1", n.d.,
<https://gist.github.com/seritalien/
f85ae82d3a1e9dd4ef303754ebdb39b9>.
[X402-2322]
"evidenceType cryptographic taxonomy and
signature_algorithm discriminator", n.d.,
<https://github.com/x402-foundation/x402/issues/2322>.
[X402-2326]
"Shared canonicalisation discipline (privacy_class and
receipt-format extensions)", 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 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>.
[X402-V2] "x402 Linux Foundation V2 Working Group", n.d.,
<https://github.com/x402-foundation/x402>.
Appendix A. Variant-Specific Receipt Bodies
Research Expires 22 November 2026 [Page 22]
Internet-Draft x402-stark-receipts May 2026
A.1. stark-vauban-pay-v1
The receipt body is CBOR-encoded ([RFC8949] canonical CBOR
Section 4.2.1). The STARK proof attests to a circuit that verifies:
* Payment amount matches the signed PaymentRequirements.amount.
* Currency asset address matches PaymentRequirements.asset.
* Payer attestation is valid (subject to merchant HumanityGate
configuration).
* Nullifier is unique (no replay for this nullifier in the
settlement ledger).
The canonical CBOR bytes layout for the stark-vauban-pay-v1 variant
is documented in the Vauban interop fixture ([VAUBAN-STARK-GIST]) and
the reference implementation at https://github.com/vauban-org/vauban-
zkpay (crate vauban-zkpay-x402 0.1.0, example crates/zkpay-
x402/examples/compute-fixture.rs). Wire format: [RFC8949] canonical
CBOR Section 4.2.1, base64url no-pad encoding per [RFC4648]
Section 5.
Implementations of the stark-vauban-pay-v1 variant MUST be
conformance test vector-compatible with [VAUBAN-STARK-GIST] as
published. Verifiers MUST use the published circuit parameters.
Out-of-band circuit versioning is outside the scope of this
extension; the stark-vauban-pay-v1 token is a stable identifier for
the v1 circuit.
A.2. hybrid-pqc
The 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.
Research Expires 22 November 2026 [Page 23]
Internet-Draft x402-stark-receipts May 2026
* kid_mldsa65: Key identifier for the ML-DSA-65 key in the
facilitator's JWKS endpoint.
Both signatures cover the 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 FeedOracle reference implementation is at [FEEDORACLE-GIST]
(standalone Python verifier, no facilitator callback).
A.3. classical-es256k
The 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 ZK or post-quantum properties.
Appendix B. Conformance Checklist
An implementation claiming conformance to this extension MUST:
* 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.
* 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 (Section 7.4).
* Pass all 9 vectors in fixtures/action-ref-verify/v0/ from
[X402-2398].
Research Expires 22 November 2026 [Page 24]
Internet-Draft x402-stark-receipts May 2026
Proposed companion vectors (pending TSC review; to ship via separate
PR after PR-B merges):
* 0010-duplicate-keys (Section 7.3)
* 0011-unicode-normalisation (Section 7.4)
* 0012-missing-canonical-field (Section 7.3)
On landing of this extension, the following IANA registry initial
values MUST be submitted per Section 12:
* Register stark-vauban-pay-v1 (Status: Provisional; Contact: Vauban
Research).
* Register hybrid-pqc (Status: Provisional; Contact: FeedOracle).
* Register classical-es256k (Status: Provisional; Contact: x402
Foundation).
Acknowledgments
The authors thank the x402 Foundation coalition contributors:
* FeedOracle (hybrid post-quantum signature implementation and ML-
DSA-65 key material ; retention-property clause for the shared
canonicalisation discipline [X402-2326] grounded in MiCA Art. 80,
AMLR Art. 56, DORA Art. 14)
* andysalvo (action-ref-verify conformance suite, baseline +
adversarial vectors)
* AlgoVoi (JCS substrate determinism cross-validation across four
published vector sets ; architectural skeleton of the shared
canonicalisation discipline [X402-2326])
* nobulex (arian-gogani ; bilateral-receipt evidence row in the
composite trust-query Axis 4 fixture under [X402-2322])
The three-implementation consensus thread [X402-2357] was
instrumental in stabilising the canonical preimage discipline defined
in Section 7. The shared canonicalisation discipline [X402-2326] co-
authored by AlgoVoi, FeedOracle, and Vauban Pay extended the rule to
cover cross-observer-across-time determinism for receipts emitted
under statutory retention obligations.
Author's Address
Research Expires 22 November 2026 [Page 25]
Internet-Draft x402-stark-receipts May 2026
Vauban Research
Vauban Research
Email: hello@vauban.tech
URI: https://pay.vauban.tech
Research Expires 22 November 2026 [Page 26]