RFP alignment

A reviewer’s index. For each requirement of the “x402 Facilitator with Bazaar (discovery) support” RFP: what state it is in, and the artifact that shows it — a command to run, a generated file, or a section that argues the position. What this document does not claim. It is not an exhaustive enumeration of every clause in the RFP. It covers the requirements this repository can point at evidence for, quoting the RFP where the exact wording matters. A requirement that is absent here is absent because it is not mapped yet, not because it is met. Anything with no artifact behind it says so. Status vocabulary, used strictly:

Status	Means
Delivered	Working today on `stellar:testnet`, with an artifact anyone can regenerate
T1 / T2 / T3	Funded work, in the named tranche (ARCHITECTURE §10)
Position	A decision taken and written down, with the reasoning, rather than a build
Not built	Absent, and said so

Every number below is generated. npm run evidence:build rewrites EVIDENCE.md and the README from docs/status/*.json; nothing in that directory is hand-entered.

§3.6 — The six acceptance criteria

The hardest table in the RFP, because each row is pass/fail rather than a judgement.

#	Criterion	Status	Evidence
1	An unmodified canonical client completes a payment end to end, on both networks	Delivered on testnet · pubnet is T3	`npm run verify:conformance` → `conformance.json`
2	`/supported` advertises the Stellar extra including `areFeesSponsored`	Delivered	`curl -s https://stellarsight.xyz/supported`; asserted in `npm run verify:api`
3	The `payload: { transaction }` shape is accepted verbatim	Delivered	Named criterion `payload-transaction-verbatim`, read off the header the stock client sent; the reading is pinned by `test/payment-shape.test.mjs` against a real recorded payload
4	A passing run of the x402 repository’s own e2e suite, on both networks	Delivered on testnet, 6/6 · pubnet is T3	`upstream-e2e.json`, pinned to suite commit `6557149`
5	A settled transaction hash published per network per scheme	Delivered for `exact`/testnet · `upto` is T2 · pubnet is T3	TESTNET-TXS.md
6	Every rejection carries a non-null reason	Delivered, 11/11	`node scripts/verify-rejections.mjs` → `rejections.json`

§3.1 — The facilitator

Requirement	Status	Evidence
`verify` / `settle` / `supported`, self-facilitated	Delivered	`apps/facilitator`, self-hosted on Apache-2.0 `@x402/stellar`
Fee sponsorship — the paying agent needs no XLM	Delivered	ARCHITECTURE §2.4; visible on any settled transaction’s fee account
Support for classic keypairs and custom `__check_auth` accounts	Classic keypairs Delivered · `__check_auth` is T2	ARCHITECTURE §2.2, §10
”Caller authentication, metering, and rate limiting are the respondent’s design choice. Document the mechanism and make it configurable.”	Rate limiting Delivered and configurable · per-caller metering Not built, belongs with per-seller identity in T1	DEPLOY.md — Caller authentication, metering and rate limiting; `GET /health` reports the policy
”any fee must be configurable rather than hard wired* so a self hoster can change or remove it. Document the business model.”*	Fee is `0`, read from `FACILITATOR_FEE_BPS` and reported on `/health`; collection is T3, inside the audit scope	DEPLOY.md — The business model

§3.2 — The Bazaar discovery layer

The RFP calls this “the core new capability” and “the hardest part of the scope”.

Requirement	Status	Evidence
Automatic cataloging, with no separate seller registration	Delivered	ARCHITECTURE §3.1 — a listing is a side effect of a settled payment; `/verify` never writes to the catalog
Readable by the stock `@x402/extensions` client	Delivered	`npm run check:bazaar` against any deployment; 49 checks in `npm run verify:api`
Catalog integrity — “the facilitator is a trust boundary”	Delivered	66 adversarial tests: traversal under triple encoding, `iconUrl` SSRF, tag flooding, external `$ref`
Natural-language search, with a stated evaluation method	Delivered	`npm run eval:search` → nDCG@10 0.864 over a 50-query graded set, with a CI regression gate
Listings representable consistently with other facilitators’, “so Stellar is not a walled garden”	Delivered	`npm run verify:interop` → one client, two facilitators; ARCHITECTURE §3.6
Golden set at 150–200 queries; wire shape locked by golden tests	T1	ARCHITECTURE §10

§3.3 — The agent-facing interface

Requirement	Status	Evidence
MCP interface an agent can discover and pay through	Delivered	`apps/agent` — four MCP tools with input and output schemas, 17-code error enum
Hosted HTTP MCP endpoint	T2	ARCHITECTURE §10

§3.4 — Schemes, and coordinating upstream

Requirement	Status	Evidence
”`batch-settlement` … `auth-capture` is also deferred … Do not foreclose either.”	Position, argued positively and checkably	ARCHITECTURE §6.4 — including the two consumer surfaces that would need editing, named
Coordinate the contribution “through the x402 Technical Steering Committee”	Position today, T2 as a deliverable	upto-position.md; ARCHITECTURE §10
`upto` implemented as standardized, with an interop report	T2	ARCHITECTURE §6.3

§3.5 — Stellar specifics

Requirement	Status	Evidence
”Soroban resource limits. Verify, settle, and any registry operations must stay within per transaction read, write, instruction, and memory limits.”	Delivered, measured	`npm run evidence:footprint` → what a settlement costs the host; ARCHITECTURE §2.7. Worst utilization 1.5%; memory reported as unobserved rather than guessed; no on-chain registry exists, so that clause has no operation to bound
SEP-41 / SAC assets	Delivered	ARCHITECTURE §2.3

§3.6 — Security, conformance, licensing

Requirement	Status	Evidence
”Strict payload verification, a settlement path resistant to replay and front running”	Delivered	Replay: THREAT-MODEL T7 — enforced on-chain by the Soroban nonce. Front running: T13, with what it does not cover stated
”No AGPL or other strong copyleft in the dependency path … Confirm dependency licenses and flag anything uncertain.”	Delivered, confirmed rather than asserted	`npm run audit:licenses` → dependency licences: 191 production packages, all permissive, zero unknown. CI fails the build on strong copyleft or an unknown licence
”Drift, not inability, is the failure mode this screens for”	Delivered	The drift we found in ourselves: our seller advertised `x402Version: 2` and answered 402 in the v1 wire format. The whole story, and a nightly stock-client run so it cannot recur
Permissive licence end to end	Delivered	Apache-2.0, checked by the audit above
External security review	T3	SCF Audit Bank; the fee is excluded from the budget per the rules

§4 — Evaluation criteria

Criterion	Where the answer is
§4.2 Interoperability story	`npm run verify:interop`, and ARCHITECTURE §3.6. Graded twice — it is also a §3.2 requirement
§4.3 Conformance discipline — “prior conformance runs, spec contributions, or interop bug reports are strong signals”	Nightly settled payment since 2026-08-22; the official x402 e2e suite passing 6/6; a spec PR open upstream; and the v1/v2 drift found in our own seller
§4.6 Alignment with wallet teams on auth-entry signing	T2, scheduled rather than asserted — ARCHITECTURE §10
Search quality as a real answer, not a plan	`npm run eval:search`, with the method and the caveats in SEARCH-EVAL.md
Honest reporting of weaknesses	LOAD-BASELINE.md publishes the worst number in the repo: 4/4 serial, 1/10 concurrent

§5 — Expected deliverables

Deliverable	Status	Evidence
§5.4 Author `scheme_upto_stellar.md`	Position — we propose implementing #3134 rather than authoring a fourth spec. If the TSC prefers that we author one, T2 absorbs it at no change in cost	upto-position.md
§5.7 Role-based developer guide with a seller path, a buyer/agent path and an operator path	Delivered, all three	seller · agent · operator
§5.7 Contributions to the Stellar Developer Docs	T2	ARCHITECTURE §10
§5.8 Two end-to-end example integrations	Delivered	`apps/seller` — a paid API with three real routes that announces itself into the catalog; `apps/agent` — an MCP agent that discovers and pays with no prior integration. Both run in CI
UX: “docs to a paid, discoverable endpoint appearing in the Bazaar in well under an hour”	Delivered — 59 seconds, measured	QUICKSTART-SELLER.md, every command timed with `/usr/bin/time`
On-chain registry	Out of scope, deliberately	The RFP calls it an optional stretch and explains the rent/TTL and doubled-settlement cost; ARCHITECTURE §3

Appendix — the conformance baseline the RFP suggests

The appendix suggests building a baseline by “pointing the same stock client at both it and the deliverable”. That is what npm run verify:interop is: one unmodified withBazaar() client against a reference facilitator and against this deployment, with every accepts entry on both sides validated by @x402/core’s own schema. Result and method: EVIDENCE.md. One finding worth carrying into any baseline work: of the public facilitators reachable today, only CDP serves the Bazaar discovery endpoint at all. x402.org/facilitator answers /supported and 404s on /discovery/resources; facilitator.x402.rs returns its marketing page for the same path. A discovery-layer baseline currently has one other implementation to be a baseline against.

Get started

Guides

Reference

Security

Evidence

Upstream

§3.6 — The six acceptance criteria

§3.1 — The facilitator

§3.2 — The Bazaar discovery layer

§3.3 — The agent-facing interface

§3.4 — Schemes, and coordinating upstream

§3.5 — Stellar specifics

§3.6 — Security, conformance, licensing

§4 — Evaluation criteria

§5 — Expected deliverables

Appendix — the conformance baseline the RFP suggests

​§3.6 — The six acceptance criteria

​§3.1 — The facilitator

​§3.2 — The Bazaar discovery layer

​§3.3 — The agent-facing interface

​§3.4 — Schemes, and coordinating upstream

​§3.5 — Stellar specifics

​§3.6 — Security, conformance, licensing

​§4 — Evaluation criteria

​§5 — Expected deliverables

​Appendix — the conformance baseline the RFP suggests

§3.6 — The six acceptance criteria

§3.1 — The facilitator

§3.2 — The Bazaar discovery layer

§3.3 — The agent-facing interface

§3.4 — Schemes, and coordinating upstream

§3.5 — Stellar specifics

§3.6 — Security, conformance, licensing

§4 — Evaluation criteria

§5 — Expected deliverables

Appendix — the conformance baseline the RFP suggests