Verify it yourself

Every number on this page is read out of a machine-written artifact under docs/status/, and every artifact names the command that produced it. Nothing here is typed by hand — if a claim and the code disagree, the artifact is the one telling the truth. Generated by npm run evidence:build from 12 artifact(s).

What this build does not claim

Not claimed	Why
Mainnet settlement	The facilitator runs on `stellar:testnet` only. `stellar:pubnet` with USDC is Tranche 3 work, gated on the Audit Bank review. The agent refuses to sign on pubnet.
A completed security audit	No third-party audit has been performed. A threat model and a monitoring plan exist (THREAT-MODEL.md, MONITORING.md); an audit is not the same artifact.
Organic demand	Every settled payment below was generated by this repo — conformance runs, demos and scripted batches — and is labeled as such in `docs/status/provenance.json`. No third-party seller has listed yet.
A production-sized catalog	The public catalog is mostly seed records on `.example` hosts, flagged `seeded: true` and separable with `?seeded=false`.
Concurrency headroom	One fee-payer, one sequence number: 4/4 serial, 1/10 at concurrency 10. Published in full in LOAD-BASELINE.md; the channel pool that fixes it is Tranche 1.

The four testnet accounts

Public keys only. These are what make fee sponsorship checkable rather than asserted: open any settled payment on stellar.expert and the transaction’s source and fee account is the FEEPAYER, never the payer — the payer appears only inside the Soroban authorization entry. That is the whole claim, and it takes two clicks to falsify.

Role	Public key
ISSUER	`GAC4RE3ZW4G732BC6H3TVQYQ23FCOPTDN4SUQ3TNUARAUSXMDRKM4QUJ`
SELLER	`GCWHOZD7PS6EJOJ3EEGDVWPWQKU7RCKRK6WTTQPI5Q3TGX7XLH7GKG3O`
PAYER	`GC2ZLSM4VIZV7LSGFFLXGQYUUCLBOTBG3U22FPYI4CIJFBEL6E4UW5AO`
FEEPAYER	`GC4E5Q6WQATXWA5FCL5OV7C7HVQUZOAGXVKNHNCIL2EDY3YNAGRLKADT`

The FEEPAYER is also published live at https://stellarsight.xyz/health as feePayer.

Settlements, by why they exist

A settlement count means nothing without knowing what produced it. Every payment this repo generates is labeled at the moment it settles:

Label	Count	What produced it
`conformance`	58	`npm run verify:conformance` — an unmodified `@x402/fetch` client
`scripted-load`	55	`node scripts/evidence-batch.mjs` — this repo paying its own seller, serially
`demo`	23	`npm run demo` — the narrated discover → pay → unlock loop
`setup`	10	`scripts/setup-testnet.mjs` — account creation, trustlines, SAC deploy
total labeled	146

An unlabeled hash renders as unlabeled, never as organic. The full map is docs/status/provenance.json; every hash with an explorer link is in TESTNET-TXS.md.

Coverage: scheme × asset × network

Scheme	Asset	Network	Status
`exact`	SXT (SAC `CAYCPWN5YZEHKPGZOXGU3O7R2Q5H7LT7SZ45YIO26VMFM47VBUHOGPO2`)	`stellar:testnet`	settled, hashes published
`exact`	USDC (Circle)	`stellar:testnet`	settled — 6 payments through the upstream e2e suite, hashes below
`exact`	USDC	`stellar:pubnet`	Tranche 3
`upto`	UPTO (throwaway SAC `CAV4X3SOGWJEZNOI6BE5N5MMMSDUCG2PQ5JSIKJGEDDY2J54VJZ76DN3`)	`stellar:testnet`	one settled `settle_upto` call from the contract in `contracts/upto` — 62846cad…; the scheme in the facilitator and the interop report are Tranche 2

Acceptance criteria, as observed

Written by npm run verify:conformance -- --emit on 2026-10-10 12:58:27 UTC (commit b211e15), driving an unmodified @x402/fetch client — no STELLARSIGHT code on the payment path.

Criterion	Expected	Observed
✓ an unpaid request is answered 402	HTTP 402	`HTTP 402`
✓ the challenge rides in the PAYMENT-REQUIRED header and decodes with @x402/core	decodes via decodePaymentRequiredHeader	`decoded, 1 requirement(s)`
✓ the challenge is x402 v2 shaped	x402Version 2, accepts[].amount	`x402Version 2, amount=100000`
✓ the offer names the scheme and CAIP-2 network	exact @ stellar:testnet	`exact @ stellar:testnet`
✓ an unmodified @x402/fetch client completes 402 -> sign -> settle -> 200	HTTP 200	`HTTP 200 in 6271ms`
✓ the receipt rides in the PAYMENT-RESPONSE header and decodes with @x402/fetch	decodes via decodePaymentResponseHeader	`decoded`
✓ settlement reports success	success=true	`success=true`
✗ the stock client sends `payload: { transaction }` and the facilitator settles it verbatim	payload keys exactly [transaction], settled	`payment header not observed`
✓ the receipt carries a settled transaction hash	64-hex transaction hash	`2bf4a54c7af24aa4ee032c73b84172a7d09fa71eb36fafcff8c94c5609e6b5a9`

Settled: 2bf4a54c7af24aa4ee032c73b84172a7d09fa71eb36fafcff8c94c5609e6b5a9 · 0.01 SXT · 6271ms end to end. Artifact: docs/status/conformance.json

The x402 repository’s own e2e suite

The RFP names this as a hard acceptance criterion: “a passing run of the x402 repo’s e2e suite for both networks”. This is the stellar:testnet half — stellar:pubnet is Tranche 3 work, so the other half is scheduled rather than skipped. 6/6 scenarios passed against https://stellarsight.xyz, on suite commit 6557149b1437. Every payment settled in Circle testnet USDC — not by choice but by construction: the suite’s Stellar route resolves its asset through @x402/stellar’s defaultMoneyConversion and offers no override, so a Stellar run is a USDC run. That also answers, on chain, the “any SEP-41 token, USDC by default” line in RFP 3.1 that this project had until now only claimed.

Client	Server	Result	Settled
`typescript/http/axios`	`typescript/http/express`	✓	`ac4b18e9b3…`
`typescript/http/fetch`	`typescript/http/express`	✓	`9bae6264c4…`
`typescript/http/axios`	`typescript/http/fastify`	✓	`b506b645f8…`
`typescript/http/fetch`	`typescript/http/fastify`	✓	`c4035e78b3…`
`typescript/http/axios`	`typescript/http/hono`	✓	`065b20af27…`
`typescript/http/fetch`	`typescript/http/hono`	✓	`a221fa4a4d…`

What this run does not cover, stated here rather than left for a reader to find:

The seller and the payer are processes the harness spawns locally; it has no remote-seller mode, so the hosted seller at stellarsight.xyz is not on this path. What is exercised remotely is the facilitator.
Reaching a deployed facilitator at all requires a forwarding relay in e2e/facilitators/external-proxies/, which is gitignored upstream and therefore first-party. Ours is published at e2e-proxy/ so the run is auditable.
stellar:pubnet is Tranche 3. The RFP asks for both networks; this is the testnet half, and the other half is scheduled rather than skipped.

Upstream defects worked around:

x402-foundation/x402#3187 (open; fix PR #3228 unmerged): e2e/clients/typescript/client.ts derives EVM and SVM signers before branching on —families, so a Stellar-only run crashes without CLIENT_EVM_PRIVATE_KEY and a 64-byte CLIENT_SVM_PRIVATE_KEY. Both are unused decoys in this run.

Artifact: docs/status/upstream-e2e.json · relay source: e2e-proxy/

Rejection audit

The negative-path counterpart: every documented error path, driven for real, with the code and reason the caller actually received. A rejection that arrives without a non-empty reason fails this run even when its status code is right. node scripts/verify-rejections.mjs · 11/11 applicable path(s) behaved as documented

Path	Expected	Observed	Reason returned
✓ `unpaid-402`	402 + PAYMENT-REQUIRED header	402 + PAYMENT-REQUIRED	`PAYMENT-SIGNATURE header is required.`
✓ `garbage-signature`	402, reason names base64/JSON	402, reason names the format	`The PAYMENT-SIGNATURE header is not valid base64-encoded JSON: Invalid payment signature h`
✓ `echo-mismatch`	402, reason names the mismatch	402, echo mismatch named	`The payment requirements echoed in PAYMENT-SIGNATURE do not match this resource's price, a`
✓ `verify-empty-body`	4xx, isValid=false, non-null invalidReason	400, isValid=false	`Request body must include both` paymentPayload`and`paymentRequirements`.`
✓ `settle-empty-body`	4xx, success=false, non-null errorReason	400, success=false	`Request body must include both` paymentPayload`and`paymentRequirements`.`
✓ `supported-shape`	200, kinds[].extra.areFeesSponsored === true	200, exact@stellar:testnet, areFeesSponsored=true	—
✓ `discovery-unknown-endpoint`	404 JSON listing the real endpoints	404, 4 endpoint(s) named	`no such discovery endpoint: /discovery/nope. This facilitator serves /discovery/resources,`
✓ `search-missing-query`	400, machine-readable reason	400	`the "query" parameter is required on /discovery/search`
✓ `write-without-token`	401 or 503, reason explains which precondition is missing	401, ok=false	`a valid` Authorization: Bearer <STELLARSIGHT_WRITE_TOKEN> `header is required`
✓ `search-wrong-method`	405 + Allow	405, Allow: GET, HEAD, OPTIONS	`allowed methods: GET, HEAD, OPTIONS`
✓ `integrity-replay-labeled`	200, source=“replay”	200, source=replay, 5 row(s)	—

Artifact: docs/status/rejections.json

Scripted batches

Breadth of settlement, run serially and labeled as scripted. Not a load test — LOAD-BASELINE.md already publishes what this stack does under concurrency, and it is the least flattering number in the repo.

Run	Settled	Routes	p50	p95
2026-08-21 05:50	50/50	/v1/fx/usd-brl 17/17 /v1/cep/01310100 17/17 /v1/ocr/nota-fiscal 16/16	9736ms	10278ms

What a settlement costs the Soroban host

Read back off the ledger from the transaction named below, and compared against the network’s live ConfigSetting entries — both sides fetched, neither typed. Regenerate with npm run evidence:footprint -- --emit; the nightly re-measures the payment it has just settled.

Resource	Used	Per-transaction limit	Utilization
Instructions	742,111	400,000,000	0.1855%
Disk read bytes	376	200,000	0.188%
Write bytes	308	132,096	0.2332%
Read ledger entries	2	200	1%
Write ledger entries	3	200	1.5%
Memory	not observable	41,943,040	—

Worst utilization 1.5% — about 66.7× headroom against the tightest per-transaction limit. Measured on 2bf4a54c7af2… in ledger 5,122,704. Memory is the one row without a measurement: Peak host memory is not recorded in the transaction envelope or result meta, so usage is unobserved. The per-transaction limit is reported for completeness.

Fee-payer runway

THREAT-MODEL.md T6: this deployment sponsors every buyer’s network fee from one account, so a drained fee-payer stops every settlement at once. Read straight off Horizon — balance, and burn from every transaction on the account over the trailing window, successful or not, since a fee is charged either way. Regenerate with npm run monitor:feepayer -- --emit; a scheduled workflow pages on a breach.

Signal	Value	Threshold	Status
Balance	19999.3247403 XLM	—	—
Runway	3410285.11 days	< 7 days	✅ ok
Last-hour burn vs 24h median	108,854 vs 0 stroops	> 3× median and > 5,000,000 stroops floor	✅ ok
Last conformance fee	131,902 stroops	> 250,000 stroops	✅ ok

Artifact: docs/status/feepayer.json

How fast discovery answers

Wall-clock from the measuring machine over the public internet to a parsed JSON body — network round-trip and CDN included, because that is what a caller experiences. A server-side timer would look better and mean less. Regenerate with npm run latency:discovery -- --emit.

Probe	Uncached p50 / p95 / p99	Cached p50 / p95 / p99
`GET /discovery/search`	178 / 219 / 394 ms	34 / 46 / 50 ms
`GET /discovery/search + filters`	172 / 207 / 218 ms	36 / 54 / 58 ms
`GET /discovery/resources`	184 / 301 / 320 ms	36 / 45 / 47 ms
`GET /discovery/resources + filters`	186 / 305 / 311 ms	36 / 48 / 109 ms

Worst uncached p95 is 305 ms across 25 samples per probe, 0 failed request(s). Uncached and cached are never averaged together. Uncached forces a CDN miss with a unique parameter per request so the function actually runs — that is the honest number. Cached repeats one URL, which is what a caller polling a hot query sees; it is reported because it is true and labelled because quoting it alone would be the flattering half of the measurement.

Interoperability: one client, two facilitators

The same unmodified withBazaar() client from @x402/extensions, pointed at this deployment and at another facilitator, with every accepts entry validated by @x402/core’s own PaymentRequirementsSchema. Regenerate with npm run verify:interop.

Facilitator	Role	Items	Array field	`accepts` validating
CDP (Coinbase)	reference	20	`items`	40/40
STELLARSIGHT	deliverable	20	`items`	20/20

Fields	On both	Only CDP (Coinbase)	Only STELLARSIGHT
Listing	`accepts`, `description`, `extensions`, `lastUpdated`, `resource`, `type`, `x402Version`	`quality`	`asset`, `firstSeenAt`, `iconUrl`, `id`, `input`, `lastSeenAt`, `maxAmountRequired`, `network`, `output`, `payTo`, `routeTemplate`, `scheme`, `seeded`, `serviceName`, `settlements`, `tags`
`accepts[]`	`amount`, `asset`, `extra`, `maxTimeoutSeconds`, `network`, `payTo`, `scheme`	`currency`, `recipient`	—

One client parses both: yes. Every accepts entry validates on both sides: yes. The two catalogs are not expected to agree — one indexes EVM resources and the other Stellar ones — so what is measured is whether a single consumer can read both and construct a payment from either. Facilitators checked that do not serve the Bazaar discovery endpoint today:

x402.org facilitator (https://x402.org/facilitator) — /supported answers 200; /discovery/resources answers 404
x402.rs facilitator (https://facilitator.x402.rs) — /supported answers 200; /discovery/resources returns HTML

Dependency licences

npm run audit:licenses enumerates the production dependency tree — 191 packages, workspaces included, dev dependencies excluded because they are not redistributed — and reads each declared licence out of the installed package.json. CI runs it with --strict, so an unknown licence fails the build alongside a copyleft one.

Licence	Packages
`MIT`	154
`Apache-2.0`	16
`ISC`	12
`BSD-3-Clause`	4
`BSD-2-Clause`	3
`0BSD`	1
`Unlicense`	1

0 strong copyleft, 0 weak copyleft, 0 unknown across 191 packages. That is the check behind the architectural claim that this facilitator is self-hosted on @x402/stellar rather than built on the AGPL-3.0 OpenZeppelin Relayer — the licence argument is now a property of the installed tree, not a statement of intent.

Run it yourself

Against the hosted deployment, with nothing installed:

# the 402 challenge, in the header the spec puts it in
curl -i https://stellarsight.xyz/v1/fx/usd-brl

# what this facilitator supports, including the Stellar extra
curl -s https://stellarsight.xyz/supported

# the Bazaar: natural-language search over the live catalog
curl -s "https://stellarsight.xyz/discovery/search?query=invoice%20ocr&limit=3"

# filters are applied, not accepted-and-ignored (compare the totals)
curl -s "https://stellarsight.xyz/discovery/resources?limit=100" | grep -o '"total":[0-9]*'
curl -s "https://stellarsight.xyz/discovery/resources?network=bogus:none&limit=100" | grep -o '"total":[0-9]*'

# the catalog-integrity ledger, labeled as a replay rather than observed traffic
curl -s "https://stellarsight.xyz/discovery/integrity?limit=5"

# a refusal, with its machine code and a non-empty reason
curl -s -X POST https://stellarsight.xyz/playground/fund -H 'content-type: application/json' -d '{"account":"GBAD"}'

From a clean clone, ending in a real settled payment:

git clone https://github.com/pedro-pelicioni/stellarsight && cd stellarsight
npm install && npm run setup      # creates and funds the testnet accounts
npm run dev:all                   # facilitator :4021, index :4022, seller :4023
npm run verify:conformance        # unmodified @x402/fetch client → settled hash
node scripts/verify-rejections.mjs  # every error path, expected vs observed

Then open any hash it prints on stellar.expert: the fee account is GC4E5Q6W…, the FEEPAYER — not the payer.

Get started

Guides

Reference

Security

Evidence

Upstream

What this build does not claim

The four testnet accounts

Settlements, by why they exist

Coverage: scheme × asset × network

Acceptance criteria, as observed

The x402 repository’s own e2e suite

Rejection audit

Scripted batches

What a settlement costs the Soroban host

Fee-payer runway

How fast discovery answers

Interoperability: one client, two facilitators

Dependency licences

Run it yourself

​What this build does not claim

​The four testnet accounts

​Settlements, by why they exist

​Coverage: scheme × asset × network

​Acceptance criteria, as observed

​The x402 repository’s own e2e suite

​Rejection audit

​Scripted batches

​What a settlement costs the Soroban host

​Fee-payer runway

​How fast discovery answers

​Interoperability: one client, two facilitators

​Dependency licences

​Run it yourself

What this build does not claim

The four testnet accounts

Settlements, by why they exist

Coverage: scheme × asset × network

Acceptance criteria, as observed

The x402 repository’s own e2e suite

Rejection audit

Scripted batches

What a settlement costs the Soroban host

Fee-payer runway

How fast discovery answers

Interoperability: one client, two facilitators

Dependency licences

Run it yourself