Bazaar auto-catalog: merchant sending the `bazaar` extension with successful mainnet settles is not cataloged in /discovery/merchants

[magdielduboy96-debug]

Hi — first, thanks for the facilitator and the transparency dashboard. The public analytics
endpoints are genuinely useful and this report is only possible because of them.

We run an x402 resource server (midax402.com) settling on Algorand MainNet through this
facilitator. We're seeing a reproducible gap between the analytics index and the Bazaar
discovery catalog, and we can't tell from the public API whether it's expected behaviour or
something missing on our side.

What we send

Our accepts[] entries follow the discovery shape (verified against a cataloged peer,
api.syraa.fun):

{
  "scheme": "exact",
  "network": "algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=",
  "asset": "31566704",
  "payTo": "XFVBA5GJAXJBRWLERVOTZH57NEGPCOP276U4N2E2LCMYWVVESQQPAPBODQ",
  "maxTimeoutSeconds": 120,
  "extra": { "decimals": 6, "feePayer": "ZMFK2OI7ZBD2U27ISERZC4S6LKM6WMFJPZQ4MYNJDZ2VNBNMBA67RA22AA" }
}

The payment payload for the settle below carried the extensions dict with the bazaar key —
our own request log recorded payload_extension_keys = ["bazaar", "payment-identifier"] for
that transaction.

Reference transaction

• Settle txid: PAZ4OP2OVMLQ4GQPZMBHWHUJ5J2FX4G5AA3LYAOMCEK4HERTG2OQ
• Timestamp: 2026-07-28 11:55:22 UTC
• Resource: https://midax402.com/midas-ops/basic (POST)
• Amount: 0.03 USDC · Algorand MainNet · outcome success
• payTo: XFVBA5GJAXJBRWLERVOTZH57NEGPCOP276U4N2E2LCMYWVVESQQPAPBODQ

What we observe

The analytics index picks it up correctly and immediately:

GET /data/leaderboards?cat=merchants&range=all → we move from rank 53 to rank 46,
labelled "MIDAX402", volume: 0.06, settles: 2, verifies: 3.

The Bazaar discovery catalog does not, two hours later:

Endpoint	Before settle (11:51 UTC)	+31s (11:55 UTC)	+2h04m (13:59 UTC)
GET /discovery/merchants?limit=50 → pagination.total	41	41	41
our payTo present in that list	no	no	no
GET /discovery/resources?search=midax402	0 of 0	0 of 0	0 of 0

In the transparency dashboard these transactions are classified SOURCE = DIRECT; they don't
appear under BAZAAR or X402-GLOBAL-CHALLENGE.

So the payment is ingested by analytics but the resource/merchant is never cataloged — which
suggests the gap is in the cataloging step rather than in ingestion.

Questions

1. POST /verify is documented as "Auto-catalogs resources via Bazaar extension". Beyond
   sending the bazaar key in the payload extensions, is there anything the
   paymentRequirements must contain for the catalog write to happen — e.g. description,
   mimeType, or a discoveryInfo object? Cataloged resources show those fields, and we
   currently don't send them.
2. How is the source classification (BAZAAR / DIRECT / DEV / X402-GLOBAL-CHALLENGE)
   determined — per transaction or per merchant? It isn't exposed as a query parameter on
   /data/leaderboards or /data/transactions, so we can't infer it from the public API.
3. Is X402-GLOBAL-CHALLENGE something a merchant opts into, or is it applied on your side?

Happy to share the exact paymentPayload / paymentRequirements we send for that txid if
that helps narrow it down. Thanks!

[magdielduboy96-debug]

Adding data from a second, independent merchant with the same symptom — and one piece of evidence that I think rules out the leading hypothesis.

Context: MIDAX402 (midax402.com) has settled three real mainnet payments through the GoPlausible facilitator on Algorand. All three appear in the transaction stream with our domain and route. None of them resulted in our payTo appearing in GET /discovery/merchants (41 merchants listed, we are not among them).

This is the same symptom @joeyfife reported in #1 for Coil Scanner. Two independent merchants, same behavior.

---

Ruling out the hand-rolled hypothesis, with code

The most plausible explanation so far has been that merchants using paymentMiddleware index correctly while hand-rolled servers do not. We can rule that out for our case, because our server is not hand-rolled at the x402 layer — we drive x402HTTPResourceServerSync directly, which is the same class paymentMiddleware wraps.

Reading your own package (x402 2.9.0), the middleware makes exactly four calls on this path, and we make all four:

x402/http/middleware/flask.py	our server
self._http_server.initialize() — line 383	✅
self._http_server.process_http_request(context, paywall_config) — line 390	✅ (without paywall_config, which only affects browser HTML)
self._http_server.process_settlement(...) — line 453	✅
_register_bazaar_extension(server) — line 74	✅ (we call register_extension(bazaar_resource_server_extension) directly)

There is no fifth call. No extra endpoint, no additional header, no prior registration step.

Both paths then converge on the same line in x402/http/x402_http_server_base.py:352:

verify_result = yield ("verify_payment", (payment_payload, matching_reqs), None)

and the request body is built in x402/http/facilitator_client.py:117-121 from payload.model_dump(by_alias=True, exclude_none=True) — the client's payload verbatim. A resource server has no slot to inject anything into /verify, middleware or not.

So whatever distinguishes an indexed merchant from a non-indexed one, it is not the middleware wrapper.

What we can confirm is present on our side

1. The bazaar extension is in the payload that reaches /verify. We added instrumentation specifically to measure this rather than assume it — a field in our own paid ledger, payload_bazaar_echoed, that records whether the incoming PaymentPayload carried extensions.bazaar. For txid PAZ4OP2OVMLQ4GQPZMBHWHUJ5J2FX4G5AA3LYAOMCEK4HERTG2OQ it is true.

2. The resource object is complete. Per x402/http/x402_http_server_base.py:293-297, ResourceInfo is built as:

resource_info = ResourceInfo(
    url=route_config.resource or context.adapter.get_url(),
    description=route_config.description or "",
    mime_type=route_config.mime_type or "",
)

All three are set on our routes — absolute URL, a non-empty description, and application/json. These are the fields DiscoveredResource.Description and .MimeType are populated from.

3. Verify and settle go to the same facilitator. We run a multi-facilitator resource server (CDP for EVM/SVM, GoPlausible for AVM), so we checked whether verify and settle could be routed to different clients. They cannot: x402/server_base.py:442 (verify) and :542 (settle) use the identical expression —

client = self._facilitator_clients_map.get(network, {}).get(scheme)

— keyed on the network and scheme from the payload. And empirically, if verify had gone elsewhere it would have failed and the payment would never have settled.

One caveat we want to state ourselves

We run x402 2.9.0, not the latest (2.17.0 at time of writing). We checked what that costs us on this path, and it is one concrete thing: ResourceInfo in 2.9.0 has only url, description, mime_type, while 2.17.0 also carries serviceName, tags and iconUrl.

x402 2.9.0   ResourceInfo: ['url', 'description', 'mime_type']
x402 2.17.0  ResourceInfo: ['url', 'description', 'mime_type', 'service_name', 'tags', 'icon_url']

So our resource block ships three fields where a merchant on a current SDK ships six. That matches an observation on your side: we appear with "logo": null.

We are not claiming this is the cause — a merchant that does send all six is also missing from the catalog (#1). But if your indexer expects fields that only exist from a certain SDK version onward, that would be worth knowing, both for us and for anyone else pinned to an older release. If you can confirm either way, we will schedule the upgrade accordingly.

Everything else described above is unaffected by the version: the middleware call path, the bazaar extension in the payload, and the facilitator routing are identical in 2.9.0 and 2.17.0.

A packaging observation that likely affects every Python merchant on Algorand

While scoping that upgrade we measured something that goes beyond our own pin, and we think it is worth passing along as a data point.

x402-avm installs 192 files into the x402/ package tree, including x402/schemas/payments.py and x402/extensions/__init__.py. It also declares no dependency on x402 itself (only pydantic and typing-extensions), so pip never reports a conflict for any combination.

The practical consequence, measured in a clean virtualenv:

# x402 2.17.0 alone
ResourceInfo: ['url', 'description', 'mime_type', 'service_name', 'tags', 'icon_url']

# x402 2.17.0 + x402-avm 2.0.2
ResourceInfo: ['url', 'description', 'mime_type']

x402-avm's copy of schemas/payments.py (built against the 2.0.x line) wins the file collision, so the three newer fields disappear regardless of which x402 version was requested. In the same combination, x402.extensions also stops exporting declare_payment_identifier_extension and payment_identifier_resource_server_extension.

We are not drawing any conclusion about your indexer from this — we do not know whether it reads those fields. We are reporting it because, if it holds generally, any Python merchant on Algorand ends up emitting a three-field resource block no matter what they pin, and that is invisible from pip show, which keeps reporting the requested x402 version.

Happy to share the exact reproduction steps if useful.

Transactions

• GJ7FWN5SX3AIG3RF6ONGQZT7CPC3J646RCCA22QIXO6VRONBCLIA — 0.03 USDC, Algorand mainnet
• PAZ4OP2OVMLQ4GQPZMBHWHUJ5J2FX4G5AA3LYAOMCEK4HERTG2OQ — 0.03 USDC, Algorand mainnet (this is the one with payload_bazaar_echoed = true on record)
• ROGB54KKYVDTDR3EAF3PLRE24MTGIYZ4CKHSAE7S36ZIGZGU4HVA — 0.03 USDC, Algorand mainnet

payTo: XFVBA5GJAXJBRWLERVOTZH57NEGPCOP276U4N2E2LCMYWVVESQQPAPBODQ
Resource: https://midax402.com/midas-ops/basic
Asset: 31566704 (USDC), network algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=

One observation that may help narrow it down: the analytics index does see us — our merchant rank moved after these settles — while the catalog does not list us. Same transaction, same payTo. If those are two separate ingestion paths on your side, the divergence between them is probably where to look.

Offering

Happy to provide whatever is useful: the raw 402 challenge we serve, the full PaymentPayload as received (minus the signature), our .well-known/x402, or to run a test payment on request at a time that suits you. If there is a field or a call we should be making that the reference resource server does not make on its own, we will add it — we just could not find one in the package.

Thanks for the facilitator, and for making it public and unauthenticated. Happy to help debug rather than just report.

[joeyfife]

Correcting one thing in that comment that concerns Coil, because it was load-bearing for the
conclusion — and adding a new data point.

The "sends all six fields" premise is wrong about us, so the version hypothesis is not ruled out.

@magdielduboy96-debug - the debug mentioned that the field-version hypothesis can be discounted because "a merchant
that does send all six is also missing from the catalog (#1)" — meaning Coil. I checked our
outbound payload rather than assume, and we do not send all six. Our AVM resource block was:

{ "url": "...", "description": "...", "mimeType": "application/json" }

The same three fields your comment measured on the 2.9.0 line. Coil is not a Python merchant at all
— we are a hand-rolled Cloudflare Worker in JavaScript with no x402 SDK anywhere in the path — so we
arrived at an identical three-field block by a completely different route: we built it against the
fields we saw documented, and serviceName / tags / iconUrl were simply never in it.

That means the hypothesis you set out to eliminate has, as far as I can tell, never actually been
tested by either of us. Both merchants in this thread were sending three fields.

So we have now changed our side to send all six, deployed as of 2026-07-25:

{ "url": "https://coil.trade/api/board/regime",
  "description": "Market regime classifier for trading agents — ...",
  "mimeType": "application/json",
  "serviceName": "Coil Market Regime",
  "tags": ["market-regime", "regime-verdict", "risk-on-risk-off", "..."],
  "iconUrl": "https://coil.trade/assets/img/icon-512.png" }

This makes the next Algorand settle against coil.trade a clean test of exactly one variable:

• If it indexes — the hypothesis is confirmed, and every merchant pinned to an older SDK (or
  hit by the x402-avm file-collision you documented, which is a genuinely useful find) needs to
  know that the catalog requires fields their installed package cannot emit.
• If it does not index — the hypothesis is cleanly refuted by a merchant who demonstrably sent
  all six, which is stronger than our current position of "we assumed someone had."

Either result is information this thread does not have today.

Two smaller corroborations from our side:

1. The two-ingestion-path observation matches us exactly. Our settles moved the challenge
   leaderboard (analytics saw them) while /discovery/merchants never listed us — same transactions,
   same payTo. That divergence is the sharpest clue in this thread, and it points at the catalog
   writer rather than anything in the payment envelope.
2. We independently ruled out envelope shape. A fully valid verify — real signed group, complete
   enriched envelope, your facilitator returning isValid: true — still produced no catalog record,
   and we found no POST/PUT registration route (all 404). Details in Bazaar catalog never indexes resources from a hand-rolled (non-middleware) resource server despite valid discovery extension on verify/settle #1.

We are also at the Global Challenge's self-settle limit, so we cannot burn a settle on a test —
which is why the cheapest next experiment is yours. @magdielduboy96-debug — if you are running real
payments anyway, one $0.005 read against https://coil.trade/api/board/regime (Algorand rail is in
the PAYMENT-REQUIRED header, both network spellings served) is a clean single-variable test: our
resource block has sent all six fields since 2026-07-25, so if YOUR successful settle against OUR
endpoint catalogs it, the six-field hypothesis is confirmed for a hand-rolled merchant; if not, the
catalog writer itself is the bug. We will watch our facilitator logs live and publish exactly what
was on the wire.

Three updates since the above was drafted (2026-07-30):

1. The facilitator's analytics appear to have been reset. /data/leaderboards,
   /data/merchants and the 742-resource /discovery/resources catalog all show firstSeen
   values from ~July 29 onward, and our four on-chain July settles (txids in Bazaar catalog never indexes resources from a hand-rolled (non-middleware) resource server despite valid discovery extension on verify/settle #1) are gone from
   every surface — we were rank ~14 on the leaderboard on July 22 and are now absent entirely.
   If you settled before July 29, check whether your history survived; this matters for anyone
   counting on the Challenge's volume metric.
2. We found and fixed a client-side lockout on our own side that is relevant to this thread:
   the pip x402-avm package hard-codes the long-form genesis-hash network string and raises on
   the spec's 32-char truncated form, while the TS @x402/avm SDK matches only the truncated
   form. Any merchant serving one spelling locks out the other half of the client ecosystem —
   we now serve BOTH as separate accepts entries. Worth checking which spelling your 402 serves.
3. Our endpoint's payability is now verified daily against the real shipped SDKs (empty-wallet
   probes through to on-chain simulation), so "the merchant's wire is broken" can be ruled out
   as a variable on our side for any test you run.

Happy to share our full 402 challenge, the exact enriched payload we POST to /verify, or to
coordinate a paired test at whatever time suits.