x402 Endpoint Conformance
and Reliability Audit

P1-01 · Bazaar schema rejects the endpoint's own info (method enum)

Severity: blocking

Where: live 402 response, extensions.bazaar in the decoded PaymentRequired object

Observed

The route accepts POST with a JSON body. The advertised info.input correctly declares:

{"type": "http", "method": "POST", "bodyType": "json", "body": {"query": "example"}}

The schema shipped in the same block declares:

"method": {"type": "string", "enum": ["GET", "HEAD", "DELETE"]}

Validating info against schema (JSON Schema Draft 2020-12) produces one error:

$.input.method: 'POST' is not one of ['GET', 'HEAD', 'DELETE']

Why it matters

A facilitator validates info against schema before it catalogues the resource. A block that fails its own schema is rejected at that gate. The rejection is silent: nothing is returned to the operator, the endpoint keeps serving 402 normally, and the only visible symptom is that the resource never appears in the catalogue.

The open source validator reports bazaar_ok: true for this block, because it checks that the required keys are present and non-empty strings. It does not run the info against schema validation. A green CI run does not clear this defect.

Reproduce it yourself

pip install jsonschema >/dev/null
python3 - /tmp/payment-required.json <<'PY'
import json, sys
from jsonschema import Draft202012Validator
block = json.load(open(sys.argv[1]))["extensions"]["bazaar"]
Draft202012Validator.check_schema(block["schema"])
for e in Draft202012Validator(block["schema"]).iter_errors(block["info"]):
    print("$." + ".".join(str(p) for p in e.path) + ":", e.message)
PY

Fix

Replace the method enum with the body-method variant and require the body fields the specification requires for body methods:

"method":   {"type": "string", "enum": ["POST", "PUT", "PATCH"]},
"bodyType": {"type": "string", "enum": ["json", "form-data", "text"]},
"body":     {"type": "object", "required": ["query"]}

and change input.required to ["type", "method", "bodyType", "body"].

How you prove it is closed

Re-run the reproduction snippet above. Zero errors printed. The re-test included in this audit does exactly this, plus a fresh live probe.

P2-01 · payTo in the manifest disagrees with payTo in the live challenge

Severity: important

Where: /.well-known/x402 versus the live 402 challenge

Observed

Both are valid addresses and both are checksummed. They are not the same address.

Why it matters

A buyer that compares discovery metadata against the live quote before signing sees two different recipients for one resource. That is the shape of a compromised or misconfigured deployment, and a spending policy is entitled to treat it as one. The live challenge is the authoritative source, so a buyer that never reads your manifest will pay normally. A buyer that does read it has a reason to stop.

Fix

Pick one internal source of truth for the recipient address and render both surfaces from it. If the recipient changed deliberately, update the manifest in the same deploy, and publish the change with an effective date.

P2-02 · Display price copied into the atomic amount field

Severity: important

Where: accepts[0].amount

Observed

Advertised price is 0.01 USDC. The challenge carries:

"amount": "0.01"

USDC on Base (0x8335...2913) reports decimals() = 6, verified on chain during this audit. The atomic value for 0.01 USDC is therefore 10000.

Why it matters

amount is a digit string in atomic units. "0.01" is not a digit string. A strict parser rejects the quote. A lenient parser that coerces to an integer reads 0, which is a quote for nothing and will not settle. Neither outcome produces an error message you can see from your side.

Fix

"amount": "10000". Derive it as round(price * 10 ** decimals) at build time, not by hand, and take decimals from the asset contract rather than from an assumption.