Explore Bazaar support for Stellar on x402-foundation/x402

[marcelosalloum]

Bazaar is the AI-agent discovery layer built on top of the x402 protocol — a machine-readable catalog that indexes x402-compatible API endpoints (URLs, prices, accepted payment methods, and input/output schemas) so AI agents can autonomously discover, pay for, and consume APIs without manual setup or API keys.

Bazaar is shipped as @x402/extensions and provides:

• withBazaar — wraps an x402-protected route with structured metadata describing inputs, outputs, and schema so AI agents can discover and invoke it
• bazaarResourceServerExtension — registers the resource server with the Bazaar discovery network
• declareDiscoveryExtension / extractDiscoveryInfo — HTTP and MCP extension points for agent-facing discovery
• Discovery endpoints: https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources (prod) and https://x402.org/facilitator/discovery/resources (testnet)

Current State

@x402/extensions/bazaar is pulled into this repo as a dependency (via @x402/express), but it is not wired up for Stellar. The Dockerfile comments explicitly note: @x402/extensions dynamic import is in a try/catch (bazaar not used).

Upstream Status

Stellar support is fully merged upstream. The x402 protocol repo has moved to x402-foundation/x402 and PR #711 merged the complete @x402/stellar package, including:

• ExactStellarScheme for client, server, and facilitator
• Soroban auth-entry signing and SEP-41 token support
• Network identifiers (stellar:testnet, stellar)
• Fee sponsorship via fee-bump transactions
• Full integration into the all_networks examples and e2e test suite

This unblocks Bazaar integration for Stellar.

Goal

Wire up Bazaar support in this repo now that @x402/stellar is available upstream — enabling Stellar-backed x402 endpoints to be discoverable and invocable by AI agents through the Bazaar network.

Tasks

• Upgrade dependencies to pick up the published @x402/stellar and latest @x402/extensions from x402-foundation/x402
• Audit the current @x402/extensions Bazaar API — confirm withBazaar is payment-network-agnostic (not EVM-coupled)
• Determine the path for independent (non-CDP) facilitators to register with the Bazaar discovery index
• Wire up withBazaar on the examples/simple-paywall/server Stellar routes
• Evaluate exposing a /discovery/resources endpoint from this repo's facilitator, compatible with the Bazaar spec
• Update the Dockerfile to remove the bazaar not used comment once wired

Context

The @x402/extensions package lives in the x402-foundation/x402 monorepo. Bazaar listing for Stellar may still require CDP facilitator support for Stellar settlement — this should be validated as part of the work.

[chopmob-cloud]

Operational data point from running Bazaar discovery against Stellar resources in production at AlgoVoi, in case it helps unblock any of the task list here.

On withBazaar payment-network-agnostic question

From our deployment, the discovery surface is genuinely network-agnostic at the wire-format layer. Our /discovery/resources endpoint (live at https://api.algovoi.co.uk/discovery/resources) returns resources across Stellar, Algorand, VOI, Hedera, Base, Solana, and Tempo from a single extensions.bazaar document per resource. The Stellar entries use the same evidenceShape keys as the EVM entries; the only Stellar-specific bits are:

• network: "stellar-mainnet" (canonical hyphen form)
• asset = the Circle USDC issuer (GA5ZSEJ… for classic USDC delivered via Allbridge; Soroban-wrapped (SEP-41 contract CCW67TSZ…) is a separate path we don't use today)
• payTo = a Stellar G... account string
• extra.payment_reference = a short memo when the resource binds via memo rather than reference pubkey

So nothing in our withBazaar-equivalent emission path is EVM-coupled. Whatever code stripping you'd do upstream to confirm should be small.

On the independent (non-CDP) facilitator registration path

We've been operating as an independent facilitator (no CDP backing for Stellar specifically) for a few weeks. Two paths that have worked for us:

1. Self-advertise via /.well-known/x402.json on our own domain — the canonical x402 v2 discovery endpoint Bazaar consumers can probe directly, no Foundation-side registration needed. Stellar resources show up alongside the others automatically.
2. Facilitator listing in the awesome-x402 catalogue (PR #235, currently in review) — the community-curated discovery surface that x402 indexers tend to walk.

Neither path requires Coinbase CDP support for Stellar settlement on our side. Soroban + the classic-USDC delivery (Allbridge Core → issuer GA5ZSEJ…) handles settlement entirely; the Bazaar discovery layer just describes the resource, it doesn't require the discovery host to also be the settlement venue.

This is worth validating against your own facilitator setup before relying on it, but the working-group framing around independent registration paths is settling into the spec at x402-foundation/x402 #2322 (Compliance category for the registry) and #2334 (privacy_class) — both currently awaiting Foundation maintainer review, but the working-group sign-off is in place.

On /discovery/resources shape

Happy to share our endpoint output as a reference shape if useful — the response is already public, you can compare ours against a CDP-emitted /discovery/resources and see where they agree and where the spec leaves room for emitter variation. Curl https://api.algovoi.co.uk/discovery/resources for the live document; the Stellar entries are the ones with network starting stellar-.

On the wider Bazaar spec lock-in

The working-group thread on PR #2334 has converged on a few items that affect anyone wiring up Bazaar emission today:

• signature_algorithm as an open enum (so PQC primitives can plug in without spec churn)
• off_vm_anchor inner-key polymorphism with a SHA-256(JCS(...)) MUST floor for cross-verifier reproducibility
• Three-row composition table (same-class dedup, cross-class additive, same-key disagreement preserve-both)

These all touch the discovery-document shape. None of them block wiring withBazaar up for Stellar today — they're additive, optional fields. But worth eyeballing the spec PR if you'd like the Stellar listing to be forward-compatible with the lock-in when it lands.

Offer

Happy to share any of:

• The actual extensions.bazaar.evidenceShape block from our Stellar resources (no secrets in it, can paste here)
• The minimal code path we use to emit Bazaar-shaped documents agnostically across our 7 networks
• Patterns for the self-advertised /.well-known/x402.json if it's useful as a fallback while CDP-side support evolves

Genuinely whichever of these is helpful, or none if you'd rather work from CDP's reference shapes directly. We're in similar territory and the Stellar-side independent-facilitator pattern is useful operational data that probably should be more visible.

[egoriklok]

Free public readiness snapshot for Explore Bazaar support for Stellar on x402-foundation/x402:

• Public signal: No-payment readiness snapshot draft for Explore Bazaar support for Stellar on x402-foundation/x402 #50: Explore Bazaar support for Stellar on x402-foundation/x402. Focus: api, bazaar, mcp, payment, x402.
• R1 fit: api, bazaar, mcp, payment, x402.
• Buyer-agent check I would add before autonomous spend: explicit price/cap unit, policy/version hash, receipt or charge-evidence reference, revocation/dispute path, and allow/caution/block preflight result.
• This separates "interesting paid surface" from "safe for an agent wallet to use".

No invoice, no payment link, no delivery link, no private endpoint; this is only a free public snapshot.