Integration Ports¶

Vauban Pay exposes four Rust traits as ports (three HARD/INTERFACE for MVP, one ROADMAP). Each port is an audit boundary: Phase 5 audit can target traits separately.

Port summary¶

Trait	Status	Default backend	Phase	Gate
`Claim`	HARD	`vauban-claim` v0.1.0	MVP	VPSF stable (ADR-021 v2)
`ShieldingBackend`	INTERFACE	`Transparent` → `Strk20` → `Vpp`	progressive	SDK (2a) ; VPP audit Stage 1 (2b)
`HumanityGate`	INTERFACE opt	`Null` or `Glacis`	MVP	Glacis SBT mainnet contracts
`PaymentSigner`	INTERFACE	`VaubanAuthSigner` + chain adapters	MVP + Phase 4	FIPS 206 / per-chain adapter delivery
`ClaimExporter`	`[ROADMAP]`	future: SD-JWT-VC / BBS-2023 / mDoc	Phase 2a target ; Phase 2b hard deadline Q2 2027	R4 mitigation (interop)

`Claim` — HARD, MVP¶

pub trait Claim: Send + Sync {
    fn subject(&self) -> SubjectId;
    fn predicate(&self) -> &Predicate;
    fn evidence(&self) -> &EvidenceScheme;
    fn temporal_frame(&self) -> TemporalFrame;
    fn revelation_mask(&self) -> &RevelationMask;
    fn anchor(&self) -> &Anchor;
    fn content_hash(&self) -> Poseidon252Hash;
    fn verify(&self, ctx: &VerificationContext) -> Result<(), ClaimError>;
}

PaymentIntent, SettlementReceipt, RefundClaim, DelegationGrant all implement Claim. So do HumanityClaim (Glacis), BrainDecisionClaim (Brain), SprintSealClaim (Citadel), VfProofGradeClaim (Vauban Finance per ADR-ECO-027). Same trait. Same composition operators. Same audit surface.

`ShieldingBackend` — INTERFACE, progressive¶

pub trait ShieldingBackend: Send + Sync {
    fn shield(&self, intent: &PaymentIntent) -> Result<ShieldedClaim, ShieldError>;
    fn unshield(&self, claim: &ShieldedClaim, key: &UnshieldingKey) -> Result<PaymentIntent, ShieldError>;
    fn observe(&self, claim: &ShieldedClaim, mask: &RevelationMask) -> Result<Observed, ShieldError>;
}

Backend	Phase	Detail
`Transparent`	MVP	No shielding. Plain CBOR PaymentIntent on wire. Acceptable for institutional flows where settlement metadata is OK to expose to merchant/auditor.
`Strk20Backend`	Phase 2a (Q1 2027)	Wallet-side STRK20 SDK consumption. strkBTC included as first-class privacy currency from day 1 (E3 correction post strkBTC Live 2026-05-12).
`VppBackend`	Phase 2b (Q2 2027)	VPP ML-KEM-768 stealth + ShieldedClaim envelope. Hard gate: VPP Audit Stage 1 closed 0 Critical. PQ-strict mode for regulated jurisdictions.

STRK20 vs privacy pool

Per spec v0.3 E4 correction: STRK20 is a wallet-level token standard with privacy built-in (deployed Starknet mainnet 2026-03-10), NOT an external privacy pool protocol. Vauban Pay consumes STRK20 as a wallet-side SDK library.

Sovereignty exit: if the STRK20 SDK remains early-access, Vauban can ship its own implementation (vauban-strk20-impl) based on the published STRK20 construction (eprint.iacr.org/2026/474).

`HumanityGate` — INTERFACE, optional, MVP¶

pub trait HumanityGate: Send + Sync {
    fn check(&self, subject: &SubjectId) -> Result<HumanityClaim, HumanityError>;
}

Backend	Detail
`Null`	Default, no humanity check. Used for M2M agent payments + non-regulated flows.
`Glacis` (V1 admin-attest)	Default `GlacisGate` path. Per-app SBT lookup via `VaubanPayBindings.pseudonym_of(wallet)` (`0x07d32bd4...`) with optional `GlacisVerifierV2.is_human(nullifier)` cross-check (`0x056733f3...`). Trust anchor: Glacis admin signer (V1). Shipped in production for `Glacis ∧ Rempart` flow (commit `10c2d317`). The supported country list is on-chain (`CaRegistry` `0x014da7d3...`) ; discovered dynamically, never hardcoded in vauban-zkpay.
`Glacis` (V2 trustless)	Opt-in via `GLACIS_PATH=v2` env var or `GlacisGate::with_v2_trustless()`. Cross-checks `GlacisVerifierProven.get_proven_program_hash()` (`0x03bc67bf...`) against the pinned canonical program hash (`0x4f2c8cd2...`). Trust anchor: Starknet sequencer + Stwo proof. Mainnet live 2026-05-18 per glacis-protocol ADR-018 unfreeze. V1 remains default until a vauban-zkpay-specific cost/latency bench validates V2 inside the x402 batch flow. Same coverage as V1 (shared `CaRegistry`).

Merchants opt in by setting accepts_humanity_gate: true in PAYMENT-REQUIRED. Clients respond with PaymentIntent ∧ HumanityClaim (same-subject HARD INVARIANT — composition uses ∧, not coercion).

`PaymentSigner` — INTERFACE, MVP + Phase 4¶

See x402.md — Customizable PaymentSigner adapters.

Key adapter discipline (per ADR-ECO-031 chain-agnostic invariant): no chain-specific imports in core. Per-chain signers live in adapter sub-crates only.

`ClaimExporter` — `[ROADMAP]`, Phase 2b hard deadline¶

// Phase 2b deliverable, NOT yet implemented mai 2026
pub trait ClaimExporter: Send + Sync {
    fn to_sd_jwt_vc(&self, claim: &dyn Claim) -> Result<SdJwtVc, ExportError>;
    fn to_bbs_2023(&self, claim: &dyn Claim) -> Result<Bbs2023Cred, ExportError>;
    fn to_mdoc(&self, claim: &dyn Claim) -> Result<MdocCred, ExportError>;
}

This trait is the R4 mitigation lever. Without it, all institutional positioning ("eIDAS 2.0 / SD-JWT-VC / BBS-2023 / mDoc compliance") is aspirational.

Phase	Deliverable
Phase 2a (Q1 2027 target)	Scaffold trait + SD-JWT-VC export path (RFC 9901, selective disclosure JWT)
Phase 2b (Q2 2027 hard deadline)	BBS-2023 (W3C Cryptosuite, pairing-based selective disclosure signatures) + mDoc (ISO/IEC 18013-5, mobile credential / EUDI wallet) export complete

Pre-Phase 2b external comms discipline: institutional positioning copy prefixed [ROADMAP — interop dependency] until landing. No unqualified eIDAS / EBSI claim before Q2 2027.

Failure mode: Phase 2b end without ClaimExporter complete = institutional pitch eIDAS blocked, repositioning to pure crypto-native institutional without regulator interop. Triggers ADR-ECO follow-up.

Why "ports" not "modules"¶

Each trait is a modular audit boundary. The Phase 5 assurance scope separates the code audit (Cairo + Rust crates + wire format), the Stwo-cairo verifier audit (no upstream Tier-1 audit exists), and the theorem review + formal verification (Lean 4 / EasyCrypt) plus the regulatory posture (eIDAS / ANSSI).

The trait boundary lets the auditor scope precisely. Stwo audit doesn't blow up if Vauban changes the ClaimExporter. ClaimExporter review doesn't touch the prover internals.

This is also the sovereignty exit boundary: each backend can be forked or reimplemented independently as a disaster-recovery measure (see Roadmap & Gates).

Cross-references¶

ADR-ECO-015 — PQ cryptographic audits pre-mainnet (audit envelope mandate)
ADR-ECO-031 — Chain-agnostic invariant (PaymentSigner adapter discipline)
R4 — Interop risk (ClaimExporter Phase 2b hard deadline)
VPP audit gate — the VppBackend depends on VPP audit Stage 1 closing

Integration Ports¶

Port summary¶

Claim — HARD, MVP¶

ShieldingBackend — INTERFACE, progressive¶

HumanityGate — INTERFACE, optional, MVP¶

PaymentSigner — INTERFACE, MVP + Phase 4¶

ClaimExporter — [ROADMAP], Phase 2b hard deadline¶