Re: The growing number of "x402" documents

The DISPATCH path is useful if you want the IETF to work on these
specifications.
>From your response, it seems that you have already engaged the Independent
Submission Editor to submit these as informational documents.
These are two completely different paths with different processes and
potential outcomes.
That path you need to take depends on your goal; can you clarify your goal
with these drafts?

Regards,
 Rifaat


On Mon, May 25, 2026 at 11:12 AM [email protected] <research=
[email protected]> wrote:

> Dear John, and thank you to the list for surfacing this clearly,
>
> We appreciate the directness, and the underlying concern is entirely
> legitimate: the IETF's credibility as an endorsement signal matters and
> should not be diluted. A factual account of our position follows.
>
> Track and intent:
> The six drafts from Vauban Research (draft-vauban-x402-*) are submitted on
> the Independent Submission Editor track with Informational intent, per RFC
> 4846. No claim of Working Group endorsement is made or implied in any
> document, commit, or external communication. If any artifact contains
> language inconsistent with ISE conventions, we would welcome specific
> citations so we can correct them promptly.
>
> Who we are :
> Vauban Research is a French legal entity with 18 months of documented
> development history across nine products (payments, finance, governance, ML
> security auditing, Starknet infrastructure).
> Governance decisions are tracked through a council-quorum framework with
> public ADR records.
> We are not a filing exercise in search of legitimacy; we are a
> multi-product engineering operation with pre-existing institutional
> relationships that preceded our IETF participation.
>
> Relationship to x402 Foundation:
>  We are coalition participants, not a competing standards body. Our drafts
> address layers the V2 wire protocol does not yet specify: a cryptographic
> receipt format for on-chain ZK-proof settlement (STARK M31, Circle IOP), a
> payment lifecycle state machine, a delegation-binding extension, a
> post-quantum signature discipline (FIPS 204 ML-DSA-65), and a
> claim-algebraic composition grammar.
> None of these redefine the PAYMENT-REQUIRED / PAYMENT-SIGNATURE /
> PAYMENT-RESPONSE exchange; they specify what a verifiable receipt looks
> like above that exchange.
> The settlement asset, whether STRK20, USDC, or any other, is a
> configuration parameter; the receipt format is asset-neutral by design.
>
> Artifacts available for review: We maintain a public conformance
> repository (github.com/vauban-org/x402-stark-receipts-conformance, Apache
> 2.0) with CI-validated interoperability vectors.
> The ADOPTERS.md is currently empty, which we prefer over a list inflated
> with pre-arranged entries. A
>  live on-chain demo contract on Starknet Sepolia
> (`0x044dd87a94a801cf775d4c5e4b6703102d4e97e1cd1d0a8879341219ae4f19ff`)
> provides a chain-verifiable anchor beyond the JSON layer.
> An IACR ePrint companion paper targeting FC27 is in preparation
>
> On DISPATCH :
>  We do not oppose a DISPATCH discussion. If the community judges a Working
> Group the appropriate home for payment receipt and lifecycle
> standardisation, we would participate and are open to discussing a liaison
> arrangement with the x402 Foundation TSC should they consider it useful.
> We would be glad to initiate contact via the appropriate DISPATCH process
> if that is the preferred path.
>
> Regards,
> Vauban Research / Vauban Pay (pay.vauban.tech)
> [email protected]
>
>