Skip to content

Vauban Pay

Post-quantum, HTTP-native, algebraically composable payment receipt-layer.

Vauban Pay (vauban-zkpay) is the Starknet-first reference implementation of a chain-agnostic payment grammar built on the Vauban Claim Algebra (VPSF). It treats every payment as a typed, composable cryptographic Claim — anchored by STARK proofs, selectively disclosable, and verifiable end-to-end over plain HTTP.

Status — Phase MVP in progress

This protocol is not production-ready. Specification v0.3 (canonical, post-adversarial-review) ships with explicit stage gates. Phase MVP target: Q4 2026. Mainnet target: Q4 2027 after Tier-1 audit closure.

What it is

Vauban Pay isn't a new payment rail. It's a receipt layer that sits above existing rails (Starknet first, multi-chain Phase 4+) and gives every payment a typed cryptographic identity:

  • A PaymentIntent is a VPSF Claim sextuplet (Subject, Predicate, Evidence, TemporalFrame, RevelationMask, Anchor)
  • A SettlementReceipt, RefundClaim, DelegationGrant are sibling Claims sharing the same grammar
  • All Claims compose via 5 typed operators: (conjunction, same-subject) · (delegation) · (aggregation) · (restriction) · ¬ (revocation)
  • Proofs are post-quantum (Stwo Circle STARK over M31), wire format is x402 V2 (Linux Foundation), settlement extends VaubanSettlement.cairo with anchoring to ProofChainAnchor.cairo (L3 Madara)

What it isn't

  • Not a consumer payment app. Stripe stays Stripe. Vauban Pay targets institutional receipt composability, audit trails, and post-quantum compliance.
  • Not multi-chain today. Phase 0-3 is Starknet-first reference implementation. Per-chain adapters (EVM, Solana, Bitcoin) are Phase 4+ deliverables — testnet target Q3 2027.
  • Not a privacy pool. Privacy is a wallet-level property delivered through STRK20 (Phase 2a) and VPP ML-KEM-768 stealth (Phase 2b, post audit Stage 1).

Five design axes

Vauban Pay combines five properties ; the design intent is their conjunction, not any single one:

  1. Post-quantum native ; Stwo Circle STARK M31, no SNARK trusted setup
  2. HTTP-native wire format ; x402 V2 Linux Foundation (PAYMENT-REQUIRED / PAYMENT-SIGNATURE / PAYMENT-RESPONSE)
  3. Algebraic Claim composability ; the VPSF/VCA grammar over industry-standard chains
  4. Starknet settlement ; Phase 0-3 reference implementation ; per-chain adapters Phase 4+
  5. Institutional compliance pathway ; ClaimExporter (SD-JWT-VC / BBS-2023 / mDoc) [ROADMAP ; Phase 2b]

Where to start

Project status legend

Marker Meaning
HARD Required, MVP delivery
INTERFACE Trait/port, default backend MVP, alternatives phase-gated
[ROADMAP] Not implemented today, dependency on stated phase
VERIFIED Claim cross-checked against codebase or upstream source
WIP Work-in-progress upstream — Vauban tracks but doesn't fork