x402 proves a payment. Paxiom proves what the payment bought.

Paxiom binds payment, request, output, settlement metadata, and evidence into a single signed receipt that agents and developers can verify later — with only a public key.

RECEIPT v0 · FREE OFFLINE VERIFIER · OPEN SPEC · DEVELOPER PREVIEW

Run the Verifier Read the Spec Book a Pilot Sprint

Why this exists

A payment response is not proof of delivery.

x402 makes paid HTTP resources easy: an agent pays, the server answers. But the payment succeeding is not the same thing as evidence of what was delivered. A buyer or another machine may still need to know, after the fact:

what resource was paid for, and what request was bound to that payment;
what output was actually delivered;
whether settlement was independently verified or only claimed;
whether proof evidence was present;
whether a third party can re-verify the receipt later, offline.

Today, dozens of x402 services already sign their own output in their own ad-hoc format — Ed25519 here, HMAC there, EIP-712 elsewhere. There is no neutral receipt that any seller can emit and any agent can verify uniformly. Paxiom Receipts is a first, deliberately small draft of that shared object.

What the verifier does

Honest about what was checked — and what was only claimed.

Receipt v0 · Verifier CapabilityOffline

Verifies today

Receipt shape (schema)
Ed25519 signature
Canonical signing input
Output-hash binding
Request / payment binding fields
Settlement status vocabulary
Proof / evidence status vocabulary
Deterministic trust-state resolution

Not verified in v0

Onchain settlement
x402 facilitator records
Proof-source evidence (Load / Helios)
Arweave archive availability
Third-party receipt dialects

Planned adapters

Onchain settlement check
Facilitator-backed settlement
Proof-source verification
Receipt-format adapters

Claim boundary

Schema-valid is not receipt-verified. A receipt that merely claims an onchain settlement is reported as settlement_claimed_not_checked — never as fully verified, and never as verified_settled. Those items on the right are planned verifier adapters, not current v0 claims.

The verdict

One deterministic trust state.

Every verification returns exactly one trust state plus a per-check breakdown. The most common:

verified valid_signature_only settlement_claimed_not_checked output_hash_mismatch invalid_signature unsupported_format proof_not_provided error

The full set of fifteen states and the exact resolution order are documented in the spec. Read the trust states →

Try it

Run the reference verifier locally.

The verifier is a dependency-free reference implementation. Clone the repo and run it with Node — no keys, no accounts, no network calls.

Verify the signed example receipt against its delivered output:

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

Or run the local HTTP wrapper and call it:

node standards/receipts/v0/server/server.mjs

curl http://localhost:8787/health
curl http://localhost:8787/v1/receipt/demo

Runtime status

This is a reference / developer verifier that you run yourself. There is no public hosted endpoint yet: GitHub Pages serves this spec and these docs, but it does not run the Node verifier. A public runtime and x402 gating come later.

Read the spec

Everything is public and inspectable.

Verifier API endpoints, examples, and runtime status
Receipt v0 — README the format, shape, and claim boundaries
JSON Schema structure validation (structure only)
Canonicalization the exact bytes the signature covers
Trust states the fifteen verdicts and resolution order
OpenAPI the verifier HTTP API
Example receipt a cryptographically real Ed25519 fixture
llms.txt agent-facing summary and boundaries

Work with Paxiom

Make one x402-paid endpoint Paxiom-compatible.

A focused 3–5 day pilot sprint for a single paid endpoint.

map your current payment flow;
add request / output / payment binding;
emit a Paxiom-compatible receipt, or verify one;
add verifier tests;
document trust-state boundaries and the settlement/proof handoff.

Contact me about a pilot

Diligence

The technical prints.

The technical prints are the engineering binder behind Paxiom: service specs, status notes, proof-source research, and audit posture. They are not required reading to understand Paxiom Receipts, but they are available for builders and reviewers who want to diligence the architecture.

Open Technical Prints