Vauban Pay developer demo

Canonical JCS reproducer

Paste any JSON object below. The right panel shows the JCS-canonicalised bytes (RFC 8785 ; alphabetical key order, no whitespace, recursive sort) and the SHA-256 of those bytes.

This is the exact canonicalisation step used to produce expected_delegation_grant_hash and expected_settlement_receipt_hash in every Vauban Pay fixture. Five independent implementations (Rust, Python, Node.js, TypeScript, Go) produce the same bytes from the same JSON input.

RFC 8785 reference: rfc-editor.org/rfc/rfc8785. Implementation: TypeScript port of the JCS algorithm (alphabetical sort, deterministic number serialisation).

AP2 open_mandate_hash ; conformance validation

serde_jcs@0.2.0 (Rust) ; Vauban Pay implementation ; 3rd independent impl (AP2/issues/265, 2026-05-23)

The AP2 open_mandate_hash is defined as SHA-256(JCS_RFC8785(unsigned_mandate_body)). The same JCS canonicalisation rule that underpins x402 STARK receipts applies here ; different protocol, same derivation.

7 conformance vectors from AP2 issue #265 were verified byte-for-byte by the Vauban Pay Rust runner (runner-ap2-omh.rs) using serde_jcs@0.2.0. This makes Vauban Pay the 3rd independent implementation to verify these vectors.

Axis 0 ; Canonicalisation substrate

AlgoVoi (chopmob-cloud) ; 4 vector sets / 53 vectors / 37 pair invariants / 5-impl byte-for-byte

The substrate layer defines the single JCS canonicalisation rule (RFC 8785) that every coalition axis follows before hashing. Any JSON object passed into any axis is first serialised to deterministic bytes: alphabetical Unicode code-point key order at every nesting level, no whitespace, Unicode NFC normalisation on string values, float rejection (non-finite numbers are protocol errors), and deterministic number representation per RFC 8785 §3.2.2.

The four AlgoVoi-authored vector sets (53 vectors total, 37 pair invariants) serve as the normative conformance anchors. A conforming implementation must reproduce each pinned SHA-256 digest byte-for-byte. Five independent implementations across five languages and four non-overlapping author sets all pass 53/53 vectors and 37/37 pair invariants.

Regulatory retention obligations (MiCA Art. 80, AMLR Art. 56, DORA Art. 14) require auditors to pin a specific vector revision for multi-year reference. The in-tree mirror at fixtures/canonicalisation-substrate/v0/ provides that repo-tagged anchor in place of mutable gist URLs.

Vector provenance: each JSON file is a byte-for-byte mirror of the canonical AlgoVoi gist at the timestamp recorded in its published_at field. Provenance verification: gh api gists/<id> | diff - against the in-tree file. RFC 8785 reference: rfc-editor.org/rfc/rfc8785.

Vauban Pay (pay.vauban.tech) ; Rust, serde_jcs 0.2.0, Stwo Circle STARK M31

The STARK receipts layer introduces BoundReceipt<T>: a deterministic CBOR (RFC 8949) envelope that wraps any settlement receipt type and binds it to a action_ref work-proof computed via SHA-256(JCS(RFC 8785)) over the canonicalized action preimage. The envelope is compact by construction: the fixture vector encodes 197 bytes of canonical CBOR from a four-field settlement receipt plus a 32-byte action_ref.

The IETF Internet-Draft draft-vauban-x402-stark-receipts (submitted 2026-05-21) formalizes the encoding rules: receipt_core is JCS-canonicalized first, SHA-256 is computed over those bytes to produce the receipt_core_hash anchored on Starknet, and the BoundReceipt envelope carries both the raw receipt and the action_ref in a single CBOR-deterministic byte string that any compliant verifier can recompute offline.

Cross-axis binding is structural: the same payment_hash and action_ref appear verbatim in Axes 2 (FeedOracle hybrid-PQC), 3 (andysalvo work-receipt), and 4 (nobulex composite). One mutation to either field invalidates all axes simultaneously ; the Axis 1 CBOR envelope is the on-chain settlement anchor for the entire coalition fixture set.

Apache 2.0. Authored by Vauban Pay as the 5th-impl contributor to the x402-foundation coalition fixture set. The CBOR encoding uses ciborium 0.2 (Rust). The Stwo Circle STARK M31 prover is a stub reference in this fixture ; the production proof path is wired in Sprint 3+4 of the vauban-zkpay roadmap.

Verify a Vauban Pay receipt without trusting Vauban. Every cryptographic step runs in your browser ; the on-chain check calls Starknet directly. No server involved.

Bounded-spend authorization fixture vectors

Three vectors from fixtures/bounded-spend-authorization-sample/v0/vectors/ shipped at commit 1c35845. Each vector carries a DelegationGrant and a SettlementReceipt with pinned JCS hashes. Click "Reproduce" to recompute the hash client-side and compare.

The DelegationGrant authorises the agent to spend up to 1 USDC per transaction and 100 USDC per 24-hour rolling period, with a single listed merchant, in USDC on Starknet Sepolia.

Hybrid post-quantum receipt

FeedOracle (@feedoracle) ; ES256K + ML-DSA-65 dual signature, FIPS 204, NIST IR 8547 transition-compliant

Both classical (ES256K, secp256k1 ECDSA) and post-quantum (ML-DSA-65, FIPS 204 lattice-based) signatures are required for receipt acceptance ; an attacker must defeat both simultaneously to forge a valid receipt. Both signatures cover identical JCS-canonical bytes derived via SHA-256(JCS(RFC 8785)(receipt_core)), ensuring deterministic, implementation-independent verification.

The receipt core is canonicalized once and shared between both signature schemes. This avoids ambiguity: one canonical byte string, two independent cryptographic commitments. Offline verification against a public JWKS requires no facilitator callback.

Cross-axis binding is achieved via the same payment_hash and action_ref fields present in Axes 1, 3, and 4. A single mutation to either value invalidates all axes simultaneously, making multi-axis tamper evidence structurally guaranteed.

Apache 2.0. Contributed by FeedOracle to the x402-foundation coalition fixture set. Fixture structure follows the fixtures/<suite>/<version>/ convention established in PR #2398 (Axis 3, andysalvo). No changes to protocol code or repo CI dependencies.

Work-receipt binding

andysalvo (@andysalvo) ;  action_ref = SHA-256(JCS(preimage)), no ZK overhead, HTTP-client verifiable

The work-receipt axis is the simplest of the four coalition axes: a pure 32-byte SHA-256 digest of the JCS-canonicalised (RFC 8785) preimage object, producing the action_ref that binds a payment to whatever the agent produced after the payment was settled.

Deterministic by construction: the same preimage fields in any key order canonicalise to the same bytes, and the same bytes hash to the same 32-byte digest. Any HTTP client with a JSON parser and a SHA-256 primitive can reproduce and verify the digest independently, with no prover, no trusted setup, and no external dependency.

This axis defines the canonical action_ref value that the other axes bind to: Axis 1 (STARK) includes it in the proof statement; Axis 2 (Hybrid-PQC) signs over the pair (payment_hash, action_ref). One mutation to action_ref breaks the binding across all axes simultaneously.

Vectors derived from action-ref-verify v0.3.0 (Apache-2.0, andysalvo). No code changes, no added dependencies, no CI modifications ; conformance data only. Reproducible by any SHA-256 + RFC 8785 implementation.

Axis 4 ; Composite trust-query

nobulex (@arian-gogani) ; tri-party composite envelope, multi-emitter evidence rows. Preimage algorithm: AlgoVoi (@chopmob-cloud).

The composite trust-query is the multi-stakeholder evidence envelope: one query against (payment_hash, action_ref) returns N evidence rows, each from a distinct emitter, each independently signed and framework-declared.

This is the composition-layer axis. Axes 0, 1, 2, 3 contribute rows. Axis 4 defines the envelope that assembles and binds them under a single query surface.

Vauban Pay MCP server

mcp.vauban.tech/pay/mcp exposes 4 MCP tools over StreamableHTTP. Any MCP-compatible agent (Claude Code, CC/Preste SDK) can call them to run a complete x402 payment cycle: DelegationGrant authorization, bounded-spend payment emission, and cryptographic audit verification on Starknet Sepolia.

JWT Bearer auth via auth.vauban.tech (OAuth 2.1 PKCE). The server declares its resource metadata at /.well-known/oauth-protected-resource. Supported scopes: pay:read, pay:write, pay:admin.

Tool registry

Agent flow: 402 paywall → on-chain proof

{
  "mcpServers": {
    "pay": {
      "type": "http",
      "url": "https://mcp.vauban.tech/pay/mcp"
    }
  }
}

HTTP/1.1 402 Payment Required
X-Payment-Required: version=2,
  network=starknet-sepolia,
  recipient=0x044dd87a94a801c...,
  amount=50000,
  currency=USDC,
  scope=api.vauban.tech/pay/data

request_delegation_grant({
  delegator: "0x005f4802...",
  delegatee: "claude-code-agent",
  scope:
    "api.vauban.tech/pay/data",
  expires_at:
    "2026-05-23T04:00:00Z",
  cap_per_tx: 100000,
  cap_per_period: 1000000
})

{
  "canon_version":
    "x402-jcs-v1.0.0",
  "grant_hash":
    "a4f7e29b1c83d5f0...",
  "grant_jcs_b64":
    "eyJ0eXBlIjoiRGVs..."
}

make_payment({
  amount: 50000,
  currency: "USDC",
  recipient:
    "0x044dd87a...",
  scope:
    "api.vauban.tech/pay/data"
})

{
  "status": "submitted",
  "payment_hash":
    "4eacfd4049ca47af...",
  "tx_hash":
    "0x02919a45344660ce...",
  "voyager_url":
    "https://sepolia.voyager.online/tx/0x02919a..."
}

verify_receipt({ tx_hash: "0x02919a45344660ce..." })

// Result:
{
  "verified": true,
  "tx_hash":
    "0x02919a45344660ce8ca9cbd5ecf96afbc56664c67d...",
  "voyager_url":
    "https://sepolia.voyager.online/tx/0x02919a...",
  "on_chain_event": {
    "receipt_core_hash":
      "0x4eacfd4049ca47afc28a3c46d4d592d2e3237ca3...",
    "payment_amount": "50000",
    "currency_decoded": "USDC",
    "timestamp_ms": "1779527515000",
    "tx_emitter": "0x005f4802..."
  },
  "reconstructed_receipt": {
    "type": "SettlementReceipt",
    "canon_version": "x402-jcs-v1.0.0",
    "network": "starknet-sepolia",
    "contract_address": "0x044dd87a94a801cf..."
  },
  "computed_jcs_hash":
    "sha256:4eacfd4049ca47afc28a3c46d4d592d2e3237ca3...",
  "contract_address": "0x044dd87a..."
}

Live Sepolia receipt

The first PaymentReceiptEmitted event on Starknet Sepolia. The on-chain receipt_core_hash is SHA-256(JCS(receipt_core)). Any buyer can re-derive the digest off-chain and compare against Voyager.

Bounded-spend fixture vectors bind to this same payment_hash / action_ref pair via the cross_axis_binding field. The Axis 1 core digest is referenced in each vector's settlement_receipt.evidence.intent_proof_ref.claim_hash.