x402 V2 / Vauban Claim Algebra / FIPS 204

Cryptographic proof layer for regulated AI and agent payments

Post-quantum, EU-compliant, audit-grade. No facilitator round-trip needed. Three independent axes over one shared payment_hash.

x402 V2 (Linux Foundation) · eIDAS Art. 46 · MiCA Art. 80 · AMLR Art. 56 · DORA Art. 14 · EU AI Act Art. 12 · NIST IR 8547. STARK receipts produce machine-verifiable records that satisfy record-keeping obligations under each framework without bespoke instrumentation.

Architecture

Three independent verification axes, one shared anchor

Each axis is produced and verified independently. All three bind to the same payment_hash and action_ref.

Axis 1 -- STARK proof of payment conditions

Vauban

Circle STARK (Stwo M31) receipt proves amount, currency, payer attestation, and nullifier without revealing them. Post-quantum by construction. No trusted setup. Bound to the same payment_hash as the other axes.

~100KB receipt 32-byte nullifier post-quantum

Axis 2 -- Hybrid post-quantum signature

Independent implementation

ES256K + ML-DSA-65 (FIPS 204) over canonical JCS bytes per RFC 8785. NIST IR 8547 transition-compliant. EU PQC Roadmap-aligned. Dual signature: one classical, one lattice-based -- both required for acceptance.

~3.3KB receipt FIPS 204 NIST IR 8547

Axis 3 -- Work-receipt binding

Independent implementation

action_ref = SHA-256(JCS(preimage)) per RFC 8785. Pure 32-byte hash binding the payment to whatever the agent produced after. No ZK overhead. Verifiable by any HTTP client without a prover.

32-byte hash RFC 8785 JCS
Compliance

What regulators actually need

Vauban Pay produces machine-verifiable receipts that map directly to record-keeping obligations in four regulatory frameworks.

EU AI Act Art. 12

Logging obligations for general-purpose AI

Art. 12 requires general-purpose AI systems to log operations with sufficient granularity for post-hoc audit. Vauban Pay's STARK receipt provides a tamper-evident, cryptographically bound record of each payment action.

MiCA Art. 76

Record-keeping for crypto asset service providers

MiCA Art. 76 mandates that CASPs maintain records of all services and transactions for five years. The composite receipt (STARK + hybrid-PQC signature + action-ref) provides a self-contained, verifiable record that survives long-term storage.

DORA (EU 2022/2554)

Operational resilience for financial services

DORA requires financial entities to maintain resilient ICT systems and retain logs for forensic investigation. Vauban Pay receipts are offline-verifiable: no live RPC call needed to confirm a historical payment.

NIST IR 8547

Post-quantum cryptographic transition

NIST IR 8547 documents the deprecation timeline for classical algorithms against quantum adversaries. Axis 2 uses ML-DSA-65 (FIPS 204) alongside ES256K. Axis 1 (Circle STARK) is post-quantum by construction.

Open standard

Reproducible across four independent implementations

Each coalition member independently produced a fixture against the same payment_hash and action_ref. No shared code.

Vauban

Rust -- STARK proof (Stwo M31 Circle STARK)

Independent implementation

Python -- Hybrid-PQC (ES256K + ML-DSA-65 FIPS 204)

Independent implementation

Node.js -- action-ref-verify (RFC 8785 JCS)

Independent implementation

JCS substrate (4-impl cross-verification)

x402 Foundation contributor Open pull requests: PR #2412 (canonicalisation substrate)  ·  PR #2413 (STARK Axis 1)
Wire format

Receipt structure: one verifiable artifact, ten fields

Every Vauban Pay payment produces a receipt_core block as the PAYMENT-RESPONSE payload. All ten fields are JCS-sorted (RFC 8785), hashed to expected_core_digest, and bound to the same payment_hash and action_ref used by the other verification axes.

PAYMENT-RESPONSE / receipt_core stark-vauban-pay-v1 -- vector 0001-baseline
{
  "payment_hash":   "2ed186ebc669...b3670f580",  // SHA-256(settlement preimage); shared with all axes
  "action_ref":     "10d8a38c01d8...35880c2c1",  // SHA-256(JCS(work preimage)) per RFC 8785
  "amount":         50000,                        // microunits; 50000 = 0.05 USDC
  "currency":       "USDC",
  "payer_pseudonym":"a3f2c1d4...bcdef01",         // Poseidon(secret, domain, salt); never raw address
  "merchant_id":    "b4e5d6f7...b3c4d5",
  "timestamp_ms":   1747843200000,                // UNIX ms; pinned per x402#2326 v3
  "proof_scheme":   "stark-vauban-pay-v1",
  "proof_blob_b64": "...",                        // serialised Stwo Circle STARK M31 proof
  "canon_version":  "1.0"                         // present when MiCA Art. 80 retention applies
}

Reference implementation

Rust 5th-impl runner. Validates 53/53 substrate vectors + 19/19 per-chain vectors. Matches every published independent coalition vector set. Five independent JCS implementations cross-validated against the same canonical byte sequence.

Starknet Sepolia ; live

The first live receipt-core emission on Starknet Sepolia. The on-chain PaymentReceiptEmitted event carries the canonical receipt_core_hash (SHA-256(JCS(receipt_core))) ; any buyer can independently re-derive the digest off-chain and compare against the value on Voyager.

Design partner pilot

Early access for regulated institutions

Vauban Pay is in Phase 0 design partner selection. We are looking for EU-regulated AI providers, payment service providers, and fintech platforms subject to EU AI Act, MiCA, or DORA obligations who need audit-grade payment receipts for AI agent operations. No production deployment yet; design partners shape the specification and get first integration access.

Email hello@vauban.tech

No web form ; direct email keeps the conversation auditable on both sides. We aim for a human reply within two working days. For founders : if you prefer Signal or a video call, mention it in the message.