Skip to content

Overview

The problem

Payments today produce opaque receipts. A bank statement, a Stripe charge_id, an Ethereum tx hash — each is an identifier, not a proof. Auditors get raw data. Privacy-preserving merchants either ship metadata-leaking JSON or invent ad-hoc encryption schemes. Composing two receipts (e.g., "this payment came from a human, not a bot, and within compliance limits") requires bespoke off-chain integration, every time.

Three structural failures recur:

  1. No typed grammar. A "payment receipt" means whatever the merchant decided. There is no algebra over receipts — no way to say "settlement ∧ humanity-proof" and have a verifier accept it.
  2. No post-quantum path. Every major payment cryptosystem (SNARKs included) sits on hardness assumptions broken by Shor's algorithm. Institutional buyers (banks, eIDAS 2.0 stack, NIST PQC roadmap) are budgeting their migration. Today's receipts won't survive.
  3. No selective disclosure as a first-class primitive. Either you reveal everything (linkability) or you reveal nothing (no audit). The middle — "reveal amount range to auditor, nothing to others" — requires building it yourself.

The Vauban Pay answer

A payment is a typed Claim. A SettlementReceipt is a typed Claim. A RefundClaim, a DelegationGrant, a humanity attestation, a KYC pass — typed Claims, all sharing the same sextuplet structure:

Claim = (Subject, Predicate, Evidence, TemporalFrame, RevelationMask, Anchor)

You compose them with 5 typed operators. You bind them to STARK proofs (post-quantum). You serve them over HTTP (x402 V2). You anchor them to a chain (Starknet today ; chain-agnostic by invariant per ADR-ECO-031, multi-chain Phase 4+).

The verifier gets a proof of the predicate, never the underlying data. The merchant chooses the RevelationMask. The auditor sees what compliance requires. An unauthorized party sees nothing.

Why algebraic composition matters

The same Claim grammar describes:

  • "Wallet X paid Merchant Y the amount A, in window W" (PaymentIntent)
  • "Subject S is a unique human" (Glacis humanity attestation, in production)
  • "Subject S consented to share a derived attribute with verifier V" (Vauban-auth scope)
  • "Subject S authorized Agent A to spend up to N USDC for service P" (DelegationGrant, Phase Agentic Q2 2027)

Because the grammar is the same, the compositions are just typed expressions:

Use case Composition
Regulated merchant flow PaymentIntent ∧ HumanityClaim (same-subject HARD INVARIANT, MVP)
Batched settlement (gas-efficient) ⊕ K=10 PaymentIntents (~50% gas savings)
Auditor sees only revenue range SettlementReceipt ▷ AuditorMask
Agentic API access DelegationGrant → AgentPayment (Phase Agentic)
Refund cancels prior receipt ¬SettlementReceipt (nullifier set)

This is not a new ZK system. It's a typed algebra above existing ZK + post-quantum primitives. The value is in the grammar, not the proof system ; STARK is a commodity primitive used as a backend.

Why post-quantum, why now

Stwo (StarkWare's Circle STARK prover over M31) is production-deployed on Starknet mainnet since 2025-11-03 — currently powering ~20% of Starknet perp markets (VERIFIED). v2.0.0 (January 2026) shipped recursion. v2.2.0 (March 2026) is current.

For payment infrastructure that institutional buyers will hold for 5-10 years, this matters:

  • Post-quantum correctness by default — collision-resistant hashes only, no discrete-log assumption to break
  • No trusted setup — verifiable from genesis, no ceremony residue
  • Recursion-native — folding 10k Claims into one verification fits the algebraic-composition narrative

Vauban pins stwo=2.2.0 + stwo-cairo-adapter=1.2.2 with passing roundtrip tests. The Phase 5 audit scope includes a separate Stwo-cairo audit because no Tier-1 public audit exists upstream.

Why HTTP-native (x402 V2)

x402 (Linux Foundation, April 2026) is the standard for HTTP-native machine payments. Three headers carry the entire flow:

  • PAYMENT-REQUIRED — merchant returns 402 with terms (currency, amount, deadline, RevelationMask reference)
  • PAYMENT-SIGNATURE — client returns signed PaymentIntent CBOR + STARK proof
  • PAYMENT-RESPONSE — merchant returns SettlementReceipt CBOR (or refund)

Vauban Pay aligns to x402 V2 wire format. The internal X-Vauban-Payment header from v0.1/v0.2 is retired. Vauban targets co-author status for a "STARK Receipts Extension" sub-standard via the x402 Foundation TSC (per ADR-ECO-024).

What this gives the buyer

A composable, post-quantum, HTTP-native receipt layer that survives regulator audits (selective disclosure), bot abuse (humanity gates), agent delegation (capped grants), and the quantum-computing transition (STARKs, no SNARKs). The same grammar serves the human-merchant flow, the regulated-bank flow, and the M2M agent flow — without three parallel codebases.

Honest scope

What ships when, and what doesn't:

  • MVP (Q4 2026) — Transparent payments, x402 V2 alignment, ⊕ K=10 aggregation, ∧ humanity binding (same-subject HARD INVARIANT — C-1 limitation of VPSF v0.1.0)
  • Phase Shielded 2a (Q1 2027) — Strk20Backend (gate: SDK accessibility), strkBTC shielded upgrade, ClaimExporter SD-JWT-VC scaffold
  • Phase Shielded 2b (Q2 2027) — VppBackend ML-KEM-768 stealth (gate: VPP audit Stage 1 closed 0 Critical), ClaimExporter complete (BBS-2023, mDoc — hard deadline for institutional pitch)
  • Phase Agentic (Q2 2027) — DelegationGrant + cap circuits, CC agents pay-per-API
  • Phase Cross-Chain (Q3 2027+) — first non-Starknet adapter testnet
  • Phase Audit & Mainnet (Q4 2027) — Tier-1 + Stwo-cairo + theorem review

If a stage gate fails, the project does not silently continue. Each trigger mandates a documented review and a freeze-or-pivot decision. This is encoded in governance, not goodwill.