Skip to content

Claim Algebra (VPSF)

Vauban Pay is built on top of the Vauban Proof Stack Framework (VPSF) — formally, the Vauban Claim Algebra (VCA). VPSF is a typed grammar for cryptographic Claims that compose across heterogeneous trust roots.

The IETF draft is draft-vauban-claim-algebra-00 (work in progress). The reference Rust implementation is the vauban-claim crate, Apache 2.0, Vauban-controlled.

The sextuplet

A Claim is the atomic primitive:

Claim = (Subject, Predicate, Evidence, TemporalFrame, RevelationMask, Anchor)
Field Meaning PaymentIntent example
Subject Stable cryptographic identity (wallet, enclave, artifact) payer_stealth_addr — stealth-derived from Vauban-auth
Predicate The mathematical statement asserted true "Owes amount of currency to merchant_pseudonym for service_id within deadline"
Evidence The cryptographic proof transforming the statement into certainty Stwo STARK proof + signature (ML-DSA-65 Phase 2+ / Ed25519 MVP)
TemporalFrame Validity window not_before (debounce) + expiry (replay window)
RevelationMask Which fields are public, which are committed, which are ZK Open / Commit / ZK / Encrypted per field
Anchor Immutable pointer (L3 tx, Merkle root, notarized hash) ProofChainAnchor.cairo L3 Madara

The point of the sextuplet is not that it's exhaustive — it's that it's the minimum required to express "X is verifiable, by whom, when, with what revealed, anchored where." Every Vauban Claim consumer (Glacis, Brain, Citadel, Bastion, vauban-auth, Paymaster, and vauban-zkpay) instantiates the same sextuplet.

Why this matters: hetero-root composability

Most verifiable-credential and proof systems are designed around a single trust root ; a TLS session, a biometric capture, a passport chip, a set of model weights, or a quorum of signers. The proof is specialised to that root.

Vauban's property is homogeneous grammar, heterogeneous roots: the same sextuplet expresses a Claim regardless of where its evidence is rooted. A verifier accepts, in a single composition:

(humanity attestation from ICAO passport) ∧ (delivery proof from TDX enclave) ∧ (payment intent with selective disclosure) ∧ (audit proof from Brain decision chain)

because they all instantiate the same sextuplet. The verifier checks the predicates it cares about ; the Claims do not depend on each other's roots.

Chain-agnostic by invariant (ADR-ECO-031)

vauban-claim core has no Starknet types, no Cairo imports, no Stwo imports. CI lint enforces it. Per-chain wiring lives in adapter sub-crates:

vauban-claim/                       # core, chain-agnostic, MANDATORY discipline
├── src/claim.rs                    # sextuplet (abstract)
├── src/composition.rs              # 5 operators (abstract)
├── src/builder.rs                  # construction (abstract)
├── src/validator.rs                # validation (abstract)
└── src/error.rs                    # error types (abstract)

vauban-claim-starknet/              # Starknet adapter (current reference impl)
├── src/anchor.rs                   # StarknetAnchor
├── src/evidence.rs                 # Stwo STARK evidence backend
└── src/primitives.rs               # Cairo / Madara / Poseidon helpers

vauban-claim-evm/                   # Phase 4+ (Q3 2027 testnet)
vauban-claim-solana/                # Phase 4+
vauban-claim-bitcoin/               # Phase 3+ conditional BitVM maturity
vauban-claim-offchain/              # federated / IPFS / Arweave

The Anchor enum and EvidenceScheme enum in core wrap adapter implementations via trait objects:

pub enum Anchor {
    Starknet(Box<dyn StarknetAnchorTrait>),
    Evm(Box<dyn EvmAnchorTrait>),
    Solana(Box<dyn SolanaAnchorTrait>),
    Bitcoin(Box<dyn BitcoinAnchorTrait>),
    OffChain(Box<dyn OffChainAnchorTrait>),
    L3Madara(Box<dyn L3MadaraAnchorTrait>),
    Custom(String, Vec<u8>),
}

pub enum EvidenceScheme {
    Stark(Box<dyn StarkProofTrait>),
    Snark(Box<dyn SnarkProofTrait>),
    BbsPlus(Box<dyn BbsPlusProofTrait>),
    Signature(SignatureScheme),
    Hmac(HmacProofTrait),
    Composite(Vec<EvidenceScheme>),
}

External communications discipline

Per ADR-ECO-031 §7 (Reserved Matter) and rules/governance/multi-chain-ambition-discipline.md:

  • Pre-Phase 4 framing (current): "Starknet-first reference implementation of chain-agnostic Vauban Claim Algebra"
  • NOT permitted: "Vauban is multi-chain" / "Multi-chain Vauban Pay live"
  • Phase 4 testnet: "Vauban Claim Algebra multi-chain — Starknet mainnet + [chain X] testnet"

Chain-agnostic milestone (ADR-ECO-031): the first non-Starknet adapter is a Phase 4+ deliverable (testnet target Q3 2027). Until then, Vauban Pay is the Starknet-first reference implementation.

The 5 composition operators

Claims compose via 5 typed operators. The next page (PaymentIntent & Composition) walks each one applied to payments.

Operator Glyph Semantic MVP status
Conjunction ∧ Both Claims valid, same subject MVP — HARD INVARIANT (C-1 limit)
Delegation → Principal authorizes agent for predicate Phase Agentic Q2 2027
Aggregation ⊕ Batch with all C_i included Sprint 663, Q3 2026
Restriction ▷ Narrow the RevelationMask MVP (built into Claim trait)
Revocation ¬ Invalidate via nullifier set MVP

The closure conjecture — that these 5 operators are closed under composition (any well-typed combination yields a verifiable Claim) — is the genuinely original Vauban research contribution (spec v0.3 §10.7). Preprint arXiv submission Phase MVP completion ; academic partner Phase 2 (with explicit acknowledgement of Goldreich-Krawczyk 1990 sequential ZK composition critique).

What VPSF doesn't claim

Honesty discipline (rules/core/evidence-discipline.md):

  • F1 — Grammar is not yet a type-system. Six brick instantiations are aligned in spirit, not formalized in a unified algebra. The closure proof is a conjecture, not a theorem.
  • F2 — Starknet-coupled today. Phase 0-3 is Starknet-anchored. The chain-agnostic invariant prevents internal coupling, but the public-facing settlement is one chain until Phase 4.
  • F3 — Regulator silence is not approval. GDPR / eIDAS 2.0 / DGFiP have not formally endorsed ZK substitutes. Vauban operates as demonstrator + lobby.
  • F4 — EDPB has no opinion on ZK selective disclosure. Minimization is conceptually served; formal confirmation pending.
  • F5 — zkML for full LLMs is not available in 2026. TEE + ZK hybrid is the bridge.
  • F6 — Vertical capture risk. vauban-zkpay is one instance of the grammar. If verticals capture engineering attention, the grammar atrophies.

Cross-references

  • ADR-ECO-004 — Vauban Proof Stack as foundational architecture
  • ADR-ECO-021 v2 — VPSF Tri-Synergy Pillar #4 elevation
  • ADR-ECO-031 — VPSF chain-agnostic invariant + Starknet-first reference
  • vauban-claim-rs — reference Rust implementation
  • draft-vauban-claim-algebra-00 — IETF draft