tech.vauban/pay-mcp

Check a merchant's proven service history (an x402 STARK-receipt history document, e.g. https://demo.pay.vauban.tech/x402/v1/history). Fetches history_url, validates the document, and verifies a sample of entries: L1 = structure + per-entry invariants + JCS canonicalization; L2 = each sampled settlement transaction is read from Starknet Sepolia and must be SUCCEEDED (a visible entry must carry a value transfer or a recognized receipt event). Four verdicts, NEVER conflated: - PROVEN_SAMPLE: document valid, sampled entries verify at the announced level. - REFUTED: an element contradicts itself or the chain -- the response names it. - NO_RECORD: no proven history at this URL. Indeterminate, NOT negative -- this is the state of most merchants today. - UNREACHABLE: transport failure; says nothing about the merchant. An RPC failure during L2 degrades the level to L1 and says so; it never becomes REFUTED. Full STARK re-verification (L3) is not run here; the response carries the public docker command.

JCS (RFC 8785) canonicalize a JSON object then compute its SHA-256 hash. Returns base64-encoded canonical bytes and the hex digest.

Make a payment on Starknet Sepolia testnet. Call it with no arguments to get a real, sponsored settlement: we fund the testnet payment, so you need no wallet, no account and no STRK. Returns the transaction hash of YOUR payment plus a Voyager link, and you can read it back from any Sepolia RPC you trust. Pass amount_wei (a decimal string in STRK-wei) to choose the amount, within the published cap. The payee is fixed by the sponsor, so this is a funded demo and not a faucet. If you would rather pay from your own account, set PAY_MCP_SEPOLIA_ACCOUNT_ADDRESS + PAY_MCP_SEPOLIA_PRIVATE_KEY and this tool switches to your signer ; in that mode it emits a receipt hash through the PaymentDemoEmitter contract, which moves NO value and is not proof of a settled payment.

Fetch a resource gated behind x402 and complete the payment flow to obtain it -- the x402 CLIENT walk, which none of the other tools here perform. GET url: if it answers 200 directly, the resource was free (outcome no_payment_required -- not a failure, x402 gates specific endpoints, not the whole internet). If it answers 402, parses the PAYMENT-REQUIRED manifest, downloads a STARK proof from proof_url (defaulted to the published demo proof only when url's host is demo.pay.vauban.tech; REQUIRED for any other host -- never guessed), gunzips it in memory, and POSTs it back to url. v0 HONESTY LIMIT: there is no public prover at v0, so the proof submitted is always PRE-GENERATED and published by the merchant, never produced by this agent from its own payment. A 'paid' outcome carries proof.honesty stating exactly what the resulting 200 proves (a real STARK verification, really bound to the settlement) and what it does NOT prove (that this agent spent its own funds or generated its own proof). Four outcomes, never conflated: no_payment_required (free), paid (200 after proof -- content + receipt + manifest + honesty label), refused (402 again after the proof was submitted -- the server's own reason, verbatim: a result, not an exception), unreachable (transport failure or an unrecognized HTTP status -- says nothing about the merchant). A missing proof_url on a non-demo host that requires payment returns a plain input error instead, since no request was ever sent to guess at. STANDARD x402 v2 (since 0.7.0): if the 402 carries the x402 foundation's PaymentRequired document (standard base64 of JSON, x402Version 2) with an exact offer on a Starknet network, this tool pays it the standard way instead: the configured Starknet account signs a SNIP-9 authorization for exactly that transfer, the merchant's facilitator settles it and pays the gas, and the same GET is retried with PAYMENT-SIGNATURE. A 'paid' outcome then carries standard{scheme, network, payTo, amount, asset, payer,…

Create a DelegationGrant authorization object. Builds the grant with canon_version 'x402-jcs-v1.0.0', JCS-hashes it and returns the grant hash.

Verify a SettlementReceipt. Two modes: 1. Local JCS mode: provide receipt + expected_hash. Computes JCS+SHA-256 and compares. 2. On-chain mode: provide tx_hash. Reads the transaction from Starknet Sepolia and recognizes TWO distinct, never-conflated outcomes: a sponsored settlement (a real STRK value transfer -- returns execution status, block number, amount_wei, sender, recipient) or a PaymentDemoEmitter receipt-hash emission (moves NO value -- returns the reconstructed receipt and its JCS hash, as before). A reverted transaction, a transaction that does neither, or a tx_hash that does not exist all return verified: false with an explicit reason -- never a guess. Exactly one of (receipt + expected_hash) or (tx_hash) must be provided.