> Public copy of the protocol frozen on 11 November 2026, before the first paid call. Internal approval notes, machine paths and internal log references are removed; nothing about the method was changed.

# X402-DELIVERY-001: do x402 sellers deliver what they charge for?

Status: **FROZEN** 2026-11-11, before the first purchase. Changes after the first purchase are crash fixes only, each
logged.

## Question
Of a random sample of live x402 sellers on Base, how many (a) deliver a usable response after payment, (b) send a
settlement receipt, (c) charge exactly the offered amount, and (d), where we can check independently, return a
correct and fresh answer?

## Budget and authority
- Limit for the test: **US$20**.
- Binding limits of the signed delegation (our buyer wallet's signed spending delegation): at most **0.10 USDC per
  payment** and **5.00 USDC in total**, only to sellers listed in our purchase log.
  The test therefore spends at most **US$4.50**.
- Every purchase goes through the existing buyer: Agent Trust preflight (ALLOW required), payTo pinned to the live
  offer, amount ≤ min(offer, 0.05 USDC). No other wallet, no other network, no other asset.

## Sample (fixed before buying)
1. Frame: the 220-host probe of 10.11 (our probe of 10 November 2026), class `402_ok`, live
   amount ≤ 50,000 atomic (0.05 USDC): 199 endpoints, one per host.
2. Exclude: URL templates, endpoints whose input needs personal data, credentials or free text about a person,
   endpoints that act on the world (send, post, trade, book, mint), adult or gambling content.
3. Shuffle the remaining list with `random.Random(1111)` and take endpoints in order until **30** pass a fresh
   unpaid 402 check (offer still Base USDC, amount and payTo as listed, input documented). Replacements and
   exclusions are logged with the reason.
4. The 30 sellers are added to our purchase log as one batch before the first purchase.

## Per endpoint: one paid call (a second only if the first fails before any charge)
Input: the seller's own documented example input (Bazaar `info.input`), else the smallest valid input.

| Check | Rule |
|---|---|
| C1 delivered | HTTP 200 and a non-empty body that parses as its declared type (JSON if JSON) |
| C2 receipt | `PAYMENT-RESPONSE` header present and decodes to a settlement with a tx hash |
| C3 charged = offered | On-chain USDC transfer from our wallet to the offer's payTo, amount equal to the offer (Base RPC / explorer); no charge without delivery is also recorded here |
| C4 schema | If the seller declares an output schema, the body conforms |
| C5 correct and fresh | Only for **checkable** endpoints, classed before the purchase: market prices vs an independent public reference (Coinbase or Kraken public API at the same minute, tolerance 1 %), timestamps within the seller's stated freshness or 15 min, deterministic utilities recomputed locally. Not checkable → reported as such, never guessed |

Charges without a receipt are reconciled from the wallet's on-chain history (as for CMC and BlockRun on 10.11).

## Stop rules
- Total spend reaches US$4.50 or the delegation's 5.00 total: stop.
- Agent Trust preflight returns anything but ALLOW: skip that endpoint, log, do not override.
- An offer asks more than the frame amount or 0.05 USDC: skip.
- Two consecutive buyer errors that are ours (not the seller's): stop and fix (crash fix only).

## Output (review date 13.11.2026)
One row per call (raw headers hashed, no secrets) and a summary table: rates of C1–C5 with counts and 90 % Wilson
intervals; per-seller rows anonymised.

## Honest limits
- 30 endpoints, one call each: a snapshot, not a rating of any seller.
- C5 covers only checkable endpoints; most utilities cannot be checked from outside.
- Our own example inputs may trigger seller bugs that ordinary buyers would not hit; reported per seller.