Payfetch methodology

The guarantees the client makes, exactly what it sends and stores, and what it does not protect against.

Methodology: Payfetch · Trust Score · Token Safety

This page states what Payfetch guarantees and, just as plainly, what it does not. Payfetch is open source and the code is the final word: the README's Security and Disclosure section is the canonical version of everything here. Source and full docs: github.com/forum-labs/payfetch.

What the client guarantees

Default caps: per-call $1.00, per-day $2.00, per-host per-day $1.00, lifetime off (the wallet balance already bounds lifetime spend on-chain). All are yours to lower.

The pre-payment checks, and what a guard call sends

Payfetch can consult two Forum Labs checks before it pays: the Trust Score (is this endpoint reliable?) and Token Safety (is this asset a serial-rug risk?). Both call our own paid APIs, which is self-dealing we disclose here rather than bury. The default guard budget is zero, so by default the client uses only those products' free tier; any paid guard usage is opt-in and produces a receipt like any other spend. The trust check is on by default in advisory mode; the safety check is off by default.

While the trust guard is on, it makes one call per paid fetch, and that call is the client's only outbound egress to us. It sends the target endpoint with the query string stripped, plus a random per-install id. The query is stripped because a target URL's query can carry your own secrets. Server-side we store a hash of the input, never the raw target, and the install id is used for aggregate counting only, never per-install profiling or resale. The install id is a random value generated on first run; delete your state file and it regenerates. Turn the guard off with guards.trust.enabled: false, and Payfetch makes no external call at all: no guard result, no network request, nothing dialed. That is the complete off switch.

Receipts: what is recorded, what is never stored

A receipt records the URL, method, and host; the outcome and any deny code; the pipeline steps traversed; the selected quote and a tally of rejected quotes; guard results; approval info; the payment (payer address, nonce, validity window, settled amount, transaction reference, and whether it confirmed); the budgets at decision time; and an HTTP summary. Key material, signatures, full payment payloads, response bodies, and request header values are never stored; a response body is recorded as a SHA-256 hash plus a byte count. Query strings are stored in the receipt, because it is your own audit trail on your own disk; guard calls, by contrast, strip the query. Nothing is rewritten; corrections append new records.

Optional outcome reporting (off by default)

Reporting is off by default and changes nothing unless you turn it on. When you report an outcome, currently per-incident with the operator CLI (payfetch report <receiptId>, never an MCP tool, so the agent can neither file nor suppress a report), the client reports the outcome of a completed payment attempt (paid and delivered, or paid and not delivered), signed by your payment wallet and tied to the on-chain settlement. This is a fact about the seller's conduct that you are reporting. It is never a record of what you looked at, and lookups (guard checks, quotes, dry runs) are never retained per consumer.

A report sends exactly these fields and nothing else:

A report sendsA report never carries
the endpoint {method, url} with the query stripped; the outcome, derived from the receipt and never agent-supplied; structural checks (settlementConfirmed, a coarse HTTP status class, contentTypeOk, nonEmpty); the termsHash you paid under; the seller's payTo address, already on-chain; a coarse amountBand; the UTC day; and your payment wallet address plus an EIP-712 signature over the payload. the query string; request headers or bodies; the response body; the receiptId; the exact amount; the exact timestamp. The guard install id never rides the report path, so the report wallet and the guard install id are never joined.

A settled x402 payment is already public: payer, payee, amount, and time are on the chain. What a report adds is the outcome bit. Today the trust API verifies the signature (recover(sig) === payer), so a stranger cannot report on your behalf, but it does not yet prove the settlement, so reports are shown as unverified until they are settlement-matched in a later version. On very-low-traffic endpoints a seller may be able to infer that a report came from you, since the anonymity set is small; we mitigate with day granularity and bucketed publication, and we state the residual here rather than hide it. We will not monetize, publish, or attempt to deanonymize reporter wallets.

What Payfetch does not protect against

Forum Labs · Payfetch · Trust Score · Token Safety · Methodology · GitHub · ops@forum-labs.com · @shopforumlabs
© 2026 Forum Labs. Non-custodial software. You control the wallet and the spending policy. Not financial advice.