Internet-Draft x402-stark-receipts May 2026
Research Expires 22 November 2026 [Page]
Workgroup:
Independent Submission
Internet-Draft:
draft-vauban-x402-stark-receipts-00
Published:
Intended Status:
Informational
Expires:
Author:
V. Research
Vauban Research

x402 STARK Receipt Format Extension

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."

This Internet-Draft will expire on 22 November 2026.

▲

Table of Contents

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.

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]).

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:

Table 1
Token Description Approx. size
stark-vauban-pay-v1 Stwo Circle STARK over payment-condition witness (amount, currency, payer attestation, nullifier). Post-quantum sound. Offline verifiable. ~100 KB
hybrid-pqc ES256K + ML-DSA-65 ([FIPS204]) dual-signature over JCS-canonical receipt core. Receipt survives Q-Day independently of proof system upgrade. ~3.3 KB
classical-es256k ES256K signature only. Default fallback for clients that do not require post-quantum or ZK properties. ~0.5 KB

Each variant corresponds to evidenceType: "cryptographic" in the [X402-2322] compliance taxonomy. The signature_algorithm discriminator used in the bazaar evidenceShape maps as follows:

Table 2
receipt_format token signature_algorithm
stark-vauban-pay-v1 "stark-m31-stwo"
hybrid-pqc "es256k+ml-dsa-65"
classical-es256k "es256k"

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.

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.

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

Table 3
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, 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.

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.

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

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.

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:

{
  "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:

Table 4
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.

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:

Table 5
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.

11. PAYMENT-RESPONSE Extension Schema

The facilitator confirms the emitted variant in the PAYMENT-RESPONSE:

{
  "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:

Table 6
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).

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.

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:

Table 7
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.

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.

  • 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:

Table 8
Name Reference Status Contact Notes
stark-vauban-pay-v1 [VAUBAN-STARK-GIST] Provisional Vauban Research Stwo Circle STARK M31 over 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-es256k [X402-V2] base specification Provisional x402 Foundation ES256K JWS Compact Serialization. Default fallback. ~0.5 KB.

These initial values are considered Provisional pending the Stable promotion criteria in Section 12.1.3.

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.

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.

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, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4648]
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <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, , <https://www.rfc-editor.org/rfc/rfc7235>.
[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, , <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, , <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, , <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, , <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, , <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, , <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)", , <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, , <https://www.rfc-editor.org/rfc/rfc7515>.
[UAX15]
Unicode Consortium, "Unicode Normalization Forms", Unicode Standard Annex #15, , <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

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.

  • 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].

Proposed companion vectors (pending TSC review; to ship via separate PR after PR-B merges):

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

Vauban Research
Vauban Research
URI: https://pay.vauban.tech