Re: The growing number of "x402" documents

Hi Rifaat,

Thanks for the clarification on the two paths ; helpful to make our goal explicit

Our intent for the current batch is publication via the Independent Submission Editor as Informational documents per RFC 4846
we are establishing a stable reference for implementers while inviting community review without seeking IETF Working Group endorsement at this stage.

That said, some drafts in the family are more general than the x402 STARK receipt specifics and could benefit from broader IETF process if community interest materialises.
In particular :

- draft-vauban-x402-vpsf-algebra-01 (claim algebra over receipt types, applicable beyond x402)
- draft-vauban-x402-lifecycle-fsm-01 (payment lifecycle FSM, format-agnostic)

these 2 feels like candidates that a DISPATCH discussion could productively examine.

For the more product-specific drafts (STARK receipts, post-quantum discipline, Starknet anchor, delegation binding), ISE remains the right fit ithink

I Would be happy to engage DISPATCH on the two general drafts if the community signals interest and i remain open to specific feedback in either direction.

Regards,
Vauban Research ([email protected])

Sent with [Proton Mail](https://proton.me/mail/home) secure email.

On Monday, May 25th, 2026 at 6:41 PM, Rifaat Shekh-Yusef <[email protected]> wrote:

> 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] <[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]