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).

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.

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, cross-axis binding via shared (payment_hash, action_ref)

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.

The current scaffold is tri-party (three confirmed emitters). The envelope schema is designed for N-party extension; a tetra-party configuration is anticipated once the risk-check extension referenced in x402 issue #2421 lands.

This is the composition-layer axis. The other axes (Axis 0 ; substrate, Axis 1 ; STARK, Axis 2 ; hybrid-PQC, Axis 3 ; work-receipt) contribute rows. Axis 4 defines the envelope that assembles and binds them under a single query surface.

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.