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.cairowith anchoring toProofChainAnchor.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) andVPPML-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:
- Post-quantum native ; Stwo Circle STARK M31, no SNARK trusted setup
- HTTP-native wire format ; x402 V2 Linux Foundation (
PAYMENT-REQUIRED/PAYMENT-SIGNATURE/PAYMENT-RESPONSE) - Algebraic Claim composability ; the VPSF/VCA grammar over industry-standard chains
- Starknet settlement ; Phase 0-3 reference implementation ; per-chain adapters Phase 4+
- Institutional compliance pathway ;
ClaimExporter(SD-JWT-VC / BBS-2023 / mDoc)[ROADMAP ; Phase 2b]
Where to start¶
- Builders → Architecture overview
- Standards / IETF reviewers → the x402 STARK Receipts draft and companion Internet-Drafts
- Roadmap → Roadmap & Gates
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 |