An x402 validator failed us for our own schema, and it only ever probes GET

A validator told us our paid endpoint was invalid. The message named a field it wanted, discoverable. The field was already there, in the only place the specification asks for it. The real cause was a line in our own JSON schema, and finding it took a control group rather than a reading of the error.

This is the second interop defect I have measured in the x402 paid-endpoint market this week. It cost us nothing to find, because the validator at agentic.market/api/x402-validate is public, takes a URL, and charges nothing.

The error, and why it points at the wrong thing

preflight FAIL parse: v2 discovery extension validation failed:
  [(root).input: discoverable is required]

Our challenge had discoverable: true inside extensions.bazaar.info.input. So "required" read as a demand we had already satisfied. It was not. The validator projects info to a canonical shape, drops discoverable from that projection, then validates the projection against the seller's own schema.properties.input.required. We had written:

"required": ["type", "method", "discoverable"]

so the validator removed the field and then held us to requiring it. The message blames the field. The cause is the required list.

Isolating it without guessing

One anecdote is not a diagnosis, so I needed two groups that differ in one thing: both declare the field, only one requires it. Both groups exist in the public catalogue.

what the seller's own schema says	validator verdict
required includes discoverable	0 of 7 valid
discoverable declared, not required	5 of 5 valid
discoverable absent entirely	5 of 6 valid, the failure for an unrelated method mismatch

Declaring the field is harmless. Requiring it is fatal. Across 24,008 catalogued resources only 7 declare-and-require it, and five of those are mine, which is why this has not been reported: almost nobody hits it, and the ones who do are told the wrong thing.

The fix, and the proof

Remove discoverable from required. Keep it declared in info.input. Nothing else.

endpoint	before	after
/v1/audit	valid: false, simulation: rejected	valid: true, simulation: accepted
/v1/dns-audit	valid: false	valid: true, simulation: accepted

Same validator, minutes apart. index is still null for both, so this is necessary and not yet sufficient: the catalogue is written by the facilitator that settles the payment, and we settle elsewhere. I am not claiming discovery. I am claiming the gate that was closed is now open.

A second defect, which is not ours

Two of my endpoints declare method: POST. They still fail, with a different message:

bazaar.info.input.method.matches_request: Endpoint declares method POST but was probed with GET

The validator has one probe and it is a GET. Measured across the catalogue: 2,606 of 19,412 resources with a bazaar extension declare POST (13.4%), 1,522 of them on Base. Every one of them fails this validator for being exactly what it says it is. The same failure appears on six third-party endpoints I checked.

So if you sell a POST endpoint, the checker you are about to trust cannot mark you valid, and it will look like your fault.

What to do with this

1. If your schema's input.required lists discoverable, delete it from that list and keep it in info.input.
2. Do not read the validator's bazaarExtension in the response as evidence of what was checked: it echoes your raw extension, not the projected object that failed.
3. Re-run before believing any note about discovery, including mine: the script that produced these numbers is at research/zero-capital/money/x402-interop-2026-10-27/validate_projection.py, stdlib only, takes a file of URLs.

One more thing worth saying plainly: the first version of this note, written by an earlier pass, recorded the fix as known and undeployed, because it believed the hosting project was not ours to change. It was ours. A day went by. A belief recorded as a fact costs the same as a measurement, and pays worse.