io.github.k-lueckePublished by GitHub account k-lueckev0.1.2Updated Nov 14, 2026
Verify and explain Ed25519 proof-bound receipts (paxiom.receipt.v0) for x402 APIs.
Verifies and explains Ed25519-signed paxiom.receipt.v0 receipts for x402-paid APIs, and reports paid on-chain settlement and seller preflight options.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/io.github.k-luecke%2Fpaxiom-receipts/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Add this to your client's mcpServers config.
{
"mcpServers": {
"paxiom-receipts": {
"type": "http",
"url": "https://api.paxiom.org/mcp"
}
}
}Status: v0 draft · developer preview · conformance target. Not a production standard, not a legal or compliance certificate.
x402 proves a payment. Paxiom proves what the payment bought.
A Paxiom receipt binds payment, request, output, settlement metadata, and optional evidence into a single signed, machine-verifiable object. It is provider-neutral: any x402-paid API can emit one, and any agent can verify one with only a public key.
This directory contains the public paxiom.receipt.v0 spec and the
zero-dependency @paxiom/receipts reference package:
src/issue.mjs, src/middleware.mjs, src/index.mjs, src/index.d.ts)src/verify.mjs, src/explain.mjs, src/client.mjs)bin/paxiom-receipt.mjs — keygen, issue, verify)mcp/server.mjs — verify_receipt, explain_receipt, issue_receipt, preflight_x402_seller, verify_receipt_live)npx @paxiom/receipts --help (or npx -p @paxiom/receipts paxiom-receipt verify <receipt.json> --output <output.json>)npx -y --package=@paxiom/receipts paxiom-receipt-mcphttps://api.paxiom.org):
POST https://api.paxiom.org/v1/receipt/verify — free offline verificationPOST https://api.paxiom.org/v1/x402/preflight — pre-payment x402 seller readiness, Circle USDC asset check, and payTo bait-and-switch scan ($0.01 USDC via x402 or X-API-Key)POST https://api.paxiom.org/v1/receipt/verify-live — live Base / Base Sepolia USDC settlement verification + Paxiom Ed25519 counter-attestation ($0.002 USDC via x402 or X-API-Key)x402 (and most receipt-issuing services today) prove that a payment happened. They do not, in a neutral and interoperable way, prove what was delivered in return. Every incumbent signs only its own output in its own ad-hoc format (Ed25519 here, HMAC there, EIP-712 elsewhere, SHA-256 trust-hash somewhere else). There is no shared receipt that binds payment + request + output + settlement + proof so that any agent can verify any seller uniformly. Paxiom v0 is a first, deliberately small draft of that shared object.
Does: binds payment, request, resource, output, settlement metadata, and optional evidence into one Ed25519-signed object with explicit, honest status fields.
Does NOT claim:
The verifier's job is to explain what was actually checked and what was only
claimed. Honesty about settlement is a core promise: a receipt that merely
asserts an onchain settlement the verifier did not confirm is reported as
settlement_claimed_not_checked, never as fully verified.
Schema-valid ≠ receipt-verified. The JSON Schema validates receipt shape only. It does not prove settlement, signature validity, output binding, or proof correctness. Those checks are performed by a Paxiom verifier and reported through trust states. A structurally valid receipt can still be
invalid_signature,output_hash_mismatch,settlement_claimed_not_checked, and so on.
The signature signs the canonical JSON of { receiptVersion, payload } — see
canonicalization.md. receiptHash is intentionally
not part of the signed payload in v0; the verifier derives it.
not_required · disabled · verify_only · claimed_not_checked ·
verified_settled · failed · unknown
claimed_not_checked means: the receipt carries settlement metadata, but the
Paxiom verifier did not independently check the chain or facilitator. A hosted
verifier may later upgrade this to verified_settled after an onchain or
facilitator-backed check.
See trust-states.md for the full verifier verdict set and
how settlement status maps to a verdict.
valid.receipt.json and settlement-claimed-not-checked.receipt.json are
cryptographically real: they were signed by a freshly generated Ed25519 key
whose private half was discarded. Each embeds its own raw public key
(base64, 32 bytes) so a verifier can check the signature with nothing else. No
real payment credentials, wallets, or API keys appear in any fixture — the payment
and request hashes are computed over harmless demo preimages.
To regenerate the fixtures (manual tool; fresh keypair each run, so this is non-deterministic and rewrites the committed vectors — see the script header):
A zero-dependency check (JSON validity, schema conformance, cross-file hash consistency, real Ed25519 signature verification, tamper detection, documented trust-state outcomes) runs with plain Node:
A dependency-free reference verifier ships alongside the spec. It is offline only — it verifies the local receipt object and never makes chain, facilitator, or network calls.
Exit codes: 0 when trustState === "verified", 1 for any other trust state,
2 for usage/IO errors. Result shape:
What it checks (and only this in v0): version gate → schema shape → Ed25519
signature over canonicalize({receiptVersion, payload}) → delivery.outputHash
vs supplied output → request/payment binding presence → honest settlement/evidence
interpretation → one deterministic trust state. It does not check onchain
settlement, facilitator responses, evidence retrieval, or foreign receipt formats.
Source: src/{canonicalize,hash,verify,explain}.mjs, CLI bin/paxiom-receipt.mjs.
Tests: node --test standards/receipts/v0/test/ (one case per trust state).
@paxiom/receipts)Any x402-paid Node/Fetch service can emit signed paxiom.receipt.v0 receipts with zero external dependencies:
Express / Node http.Server middleware is also exported via createReceiptMiddleware(options). Built-in TypeScript declarations (src/index.d.ts) are included with zero extra @types/* packages.
verifyResponseReceipt · preflightX402 · verifyReceiptLive)keygen · issue · verify)Agents (Claude Desktop, Cursor, Antigravity, MCP clients) can verify, explain, and issue receipts directly over stdio:
Tools exposed:
verify_receipt — deterministic trustState + per-check breakdown (supports trustedPaxiomPublicKeys)explain_receipt — human-readable verification report alongside structured resultissue_receipt — sign a paxiom.receipt.v0 receipt given privateKeyPem and delivery/payment metadatareceiptVersion is a hard gate: a verifier that does not recognise the exact
string returns unsupported_format. Future dialects (including adapters that map
non-Paxiom receipt formats into this shape) will bump the version or ship as
named adapters; v0 makes no forward-compatibility promise.
Source: standards/receipts/v0/README.md at commit d280432
Verify Paxiom Receipt (Offline)
Verify a paxiom.receipt.v0 cryptographic receipt (schema, Ed25519 signature, output SHA-256 JCS binding, expiry, and honest settlement/proof trust state). Deterministic and free; automatically trusts the host Paxiom counter-attestation public key when trustedPaxiomPublicKeys is omitted.
outputreceiptrequiredtrustedPaxiomPublicKeysExplain Paxiom Receipt Verdict
Verify a paxiom.receipt.v0 receipt and return a concise human/agent-readable trust-state breakdown and next-action guidance.
outputreceiptrequiredtrustedPaxiomPublicKeysGet Paxiom x402 Verifier & Preflight Info
Return Paxiom Receipt Verifier service metadata, published Ed25519 counter-attestation public keys, and x402 Base USDC payment terms for live on-chain settlement verification ($0.002 USDC) and pre-payment seller preflight ($0.01 USDC).
Takes no parameters.
90% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
Declare a license in the repository or the registry entry.
npm install @paxiom/receiptsimport { generateReceiptKeyPair, issueReceipt, verifyReceipt, verifyResponseReceipt, preflightX402, verifyReceiptLive, withPaxiomReceipt} from '@paxiom/receipts';{ "receiptVersion": "paxiom.receipt.v0", "payload": { "...": "..." }, "signature": { "algorithm": "ed25519", "keyId": "...", "publicKey": "...", "value": "..." }}standards/receipts/v0/ README.md # this file paxiom.receipt.v0.schema.json # JSON Schema (structure only) canonicalization.md # Paxiom v0 canonical JSON profile + signing input trust-states.md # verifier verdict enum + resolution order examples/ valid.output.json # delivered output bytes valid.receipt.json # REAL Ed25519 receipt -> `verified` (verify_only) output-mismatch.output.json # different output -> output_hash_mismatch vs valid.receipt.json settlement-claimed-not-checked.receipt.json # REAL Ed25519 receipt -> settlement_claimed_not_checkednode standards/receipts/v0/scripts/gen-fixtures.mjs standards/receipts/v0/examplesnode standards/receipts/v0/scripts/validate.mjs # run from repo rootnode standards/receipts/v0/bin/paxiom-receipt.mjs verify \ standards/receipts/v0/examples/valid.receipt.json \ --output standards/receipts/v0/examples/valid.output.json# -> ✓ VERIFIED (exit 0)
# machine-readable:node standards/receipts/v0/bin/paxiom-receipt.mjs verify <receipt.json> --output <output.json> --json{ "valid": true, "trustState": "verified", "checks": { "...": "..." }, "receiptHash": "0x…", "summary": "…" }import { generateReceiptKeyPair, issueReceipt, verifyReceipt, withPaxiomReceipt} from '@paxiom/receipts';
const keys = generateReceiptKeyPair({ keyId: 'seller-key-01' });
// Wrap any Fetch-style handler `(Request) => Promise<Response>` to attach `X-Paxiom-Receipt`:const handler = withPaxiomReceipt( async () => Response.json({ forecast: 'sunny', tempC: 23 }), { privateKey: keys.privateKeyPem, issuer: { name: 'weather-seller', uri: 'https://seller.example', keyId: keys.keyId }, serviceName: 'Weather Forecast API' });import { verifyResponseReceipt, preflightX402, verifyReceiptLive} from '@paxiom/receipts';
// 1. Pre-payment seller safety scan ($0.01 USDC via x402 fetch wrapper or X-API-Key):const scan = await preflightX402('https://seller.example/v1/query', { fetch: x402WrappedFetch, maxBudgetAtomic: '10000', expectedNetwork: 'base'});if (scan.verdict === 'block') throw new Error('Unsafe x402 quote');
// 2. Verify delivered X-Paxiom-Receipt header offline in 1 line:const delivery = verifyResponseReceipt(paidResponse, { output: parsedBody });
// 3. Confirm Base USDC Transfer log on-chain + obtain Paxiom counter-attestation ($0.002 USDC):const live = await verifyReceiptLive(delivery.receipt, { output: parsedBody, expectedPayTo: scan.report.selectedQuote.payTo, fetch: x402WrappedFetch});# 1. Generate an Ed25519 signing keypair (writes 0600 private key PEM + metadata JSON)node standards/receipts/v0/bin/paxiom-receipt.mjs keygen --out ./seller-key-01.private.pem --key-id seller-key-01
# 2. Sign a receipt binding output bytes + request + x402 payment metadatanode standards/receipts/v0/bin/paxiom-receipt.mjs issue \ --key ./seller-key-01.private.pem \ --key-id seller-key-01 \ --issuer-name "example-seller" \ --service-name "Demo Paid Endpoint" \ --resource "https://seller.example/v1/query" \ --output standards/receipts/v0/examples/valid.output.json \ --out ./issued.receipt.jsonnode standards/receipts/v0/mcp/server.mjs