Receipt
Issued per check. An Ed25519-signed checkpoint with an inclusion proof for a leaf that commits to the request, the observed offer and the decision. Verified locally before your wallet signs.
Request one with require_route_bindingTrust
A record you can verify without trusting us.
Every qualifying check can return a signed receipt for exactly what the seller offered at that second: the URL, the method, the price, the recipient, the asset and the network. You verify it offline with a log key you pin yourself, and the log's checkpoints are anchored on a public chain so later edits to history become detectable.
Three outputs
Receipt, record, report.
Record
What you retain: the request, the full response, the receipt and the private reveal, kept outside the agent's reach. Plus the public log, the anchored checkpoints and the change alerts on the sellers you depend on.
Investigate with a retained recordReport
Published monthly from the same observations: how many listed endpoints answered, how fast, which changed price or recipient, by host. Nothing a seller pays for changes it.
Read the September reportReceipt
What a receipt contains
With require_route_binding: true a qualifying check returns a decision_binding with exactly these fields, and a pq_trust.transparency block with the receipt and the private reveal.
| Field | What it binds |
|---|---|
request.url, request.method, request.body_sha256 | The exact seller request 402Signal made: complete URL with its query, the method, and the hash of the request body bytes. No redirects, no normalization. |
quote_sha256 | The hash of the entire x402 challenge the seller returned: every accept option in order, the price, the recipient, the asset, the network, the facilitator data and supported extensions. |
selected_index | Which option in that challenge the check selected under your rules. |
observed_at, expires_at | When the challenge was received and when the observation stops being usable for signing (60 seconds by default, never extended by retries or approval). |
| Receipt | The public leaf hash, its Merkle inclusion proof, and the Ed25519-signed checkpoint of the append-only log at that moment. |
| Reveal | The private evidence behind the leaf's commitment: your request, the observed terms and the decision, plus the salt. It stays with you; the public log holds only the commitment. |
For MPP challenges the same check records the observed method, intent and terms (a charge amount, or session and subscription terms such as unit price and deposit); a signed binding is issued for x402 exact offers today. The full contract: proof-carrying route v1.
Verify
Verify a receipt offline
Verification never needs the network and never trusts a key that arrived in the same response. Pin the log verification key through your own configuration, then check the signature, the inclusion proof, the request binding, the observed terms and the expiry.
Node
import { verifyReceipt } from "@402signal/route-guard";
const result = verifyReceipt({
routeResponseJson, routeRequestJson, trustedLogVkey
});Python
from signal402.verify import verify_route_receipt
verify_route_receipt(route_response, pinned_log_vkey)In a browser: paste a retained record and a key you pin; nothing is uploaded. Before every payment the hooks do the same verification automatically and refuse to sign when the live challenge differs from the verified terms.
PQ Trust
The log and the anchor
Each receipt's leaf is appended to an append-only Merkle log. Its checkpoints are signed immediately with Ed25519. Cumulative checkpoints are later anchored on Algorand MainNet in a transaction authorized with Falcon-1024, a post-quantum signature, so a later rewrite of the log's history becomes detectable against the chain. A pending anchor is not a confirmed one.
The public log publishes commitments, minute-rounded timestamps and nonces. It publishes no request bodies, wallets, payment signatures or seller responses. Inspect it at /transparency or fetch the current checkpoint directly.
The anchor protects the checkpoint history. It does not back up your private records and it does not make the seller payment itself post-quantum secure.
Format
The Offer Evidence Record
The receipt is one instance of a versioned, protocol-independent record: what was requested, what was offered (price, recipient, asset, network, expiry, intent), when, observed by whom, signed how and anchored where. The format is documented so that a record outlives any one payment protocol, and it reserves room for a mandate reference so an AP2, Visa or Mastercard agent mandate can later sit in the same record beside an HTTP 402 challenge.
Read the Offer Evidence Record specification · The proposed x402 extension
Controls
Custody, keys and reviews
402Signal never holds wallet keys, never signs a seller payment and never retries one. The checking-fee treasuries are receive-only addresses pinned in code. The Ed25519 log key signs receipts on the service; the Falcon anchoring key lives on a separate machine with no public address. Automated checks run on every change, and the reviews completed so far are listed with their scope.
Security controls and reviews · Live status and monitoring method · Report a security issue
Limits
What the record cannot tell you
- It proves what the seller offered for that request at that second and what the check decided. It does not prove delivery, output quality, the seller's identity or intent, or the safety of every transaction a wallet might construct.
- It cannot recover a deleted private record. The public log holds a commitment, not your evidence. Keep the request, response, receipt and reveal in storage the agent cannot rewrite.
- It shows the rules the buyer submitted, not that a human approved them. Compare the submitted rules with your separately retained policy.
- It does not observe purchases that bypassed 402Signal and it is not an automatic agent-monitoring dashboard.
- The historical verifier checks the documented receipt format. It does not itself verify the later Falcon anchor; use the anchored checkpoint as a separate history reference.
The longer discussion of oversight · Investigating a purchase with a retained record