> ## Documentation Index > Fetch the complete documentation index at: https://docs.stellarsight.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Verify it yourself > Every claim, the artifact that produced it, and the command that regenerates it — including what this build does not claim. Every number on this page is read out of a machine-written artifact under [`docs/status/`](https://github.com/pedro-pelicioni/stellarsight/blob/main/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](/security/threat-model), [MONITORING.md](/security/monitoring)); 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`](https://github.com/pedro-pelicioni/stellarsight/blob/main/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](/evidence/load-baseline); 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`](https://stellar.expert/explorer/testnet/account/GAC4RE3ZW4G732BC6H3TVQYQ23FCOPTDN4SUQ3TNUARAUSXMDRKM4QUJ) | | SELLER | [`GCWHOZD7PS6EJOJ3EEGDVWPWQKU7RCKRK6WTTQPI5Q3TGX7XLH7GKG3O`](https://stellar.expert/explorer/testnet/account/GCWHOZD7PS6EJOJ3EEGDVWPWQKU7RCKRK6WTTQPI5Q3TGX7XLH7GKG3O) | | PAYER | [`GC2ZLSM4VIZV7LSGFFLXGQYUUCLBOTBG3U22FPYI4CIJFBEL6E4UW5AO`](https://stellar.expert/explorer/testnet/account/GC2ZLSM4VIZV7LSGFFLXGQYUUCLBOTBG3U22FPYI4CIJFBEL6E4UW5AO) | | FEEPAYER | [`GC4E5Q6WQATXWA5FCL5OV7C7HVQUZOAGXVKNHNCIL2EDY3YNAGRLKADT`](https://stellar.expert/explorer/testnet/account/GC4E5Q6WQATXWA5FCL5OV7C7HVQUZOAGXVKNHNCIL2EDY3YNAGRLKADT) | The FEEPAYER is also published live at [`https://stellarsight.xyz/health`](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`](https://github.com/pedro-pelicioni/stellarsight/blob/main/docs/status/provenance.json); every hash with an explorer link is in [TESTNET-TXS.md](/evidence/testnet-transactions). ## 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…](https://stellar.expert/explorer/testnet/tx/62846cad7a356bf422d5ce1aa03dee92c9bf3e891dc02146b141808445af1029); 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`](https://stellar.expert/explorer/testnet/tx/2bf4a54c7af24aa4ee032c73b84172a7d09fa71eb36fafcff8c94c5609e6b5a9) · 0.01 SXT · 6271ms end to end. Artifact: [`docs/status/conformance.json`](https://github.com/pedro-pelicioni/stellarsight/blob/main/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](https://stellarsight.xyz)**, on suite commit [`6557149b1437`](https://github.com/x402-foundation/x402/commit/6557149b143704a0989b704387aaa9aab15d8b2e). 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…`](https://stellar.expert/explorer/testnet/tx/ac4b18e9b3a8a1ea3b4f92d48e1c65adea7a60a8e21f47c534b3b6ef504514fd) | | `typescript/http/fetch` | `typescript/http/express` | ✓ | [`9bae6264c4…`](https://stellar.expert/explorer/testnet/tx/9bae6264c451775a4f94baf008205d3fc79fc50d70aa7e2ddedfe4e33fd9b506) | | `typescript/http/axios` | `typescript/http/fastify` | ✓ | [`b506b645f8…`](https://stellar.expert/explorer/testnet/tx/b506b645f86ea763c3e5a78b8b33c17d9ee07604a7f7a1113ed4fe278f0ed2ee) | | `typescript/http/fetch` | `typescript/http/fastify` | ✓ | [`c4035e78b3…`](https://stellar.expert/explorer/testnet/tx/c4035e78b314619d6c906d58da6df598a53ee6ca90f055d2b0bf46fa2ab07696) | | `typescript/http/axios` | `typescript/http/hono` | ✓ | [`065b20af27…`](https://stellar.expert/explorer/testnet/tx/065b20af275af143286d65a7346fcbbb53efc2fcc632bf02e2880518dbac2cb1) | | `typescript/http/fetch` | `typescript/http/hono` | ✓ | [`a221fa4a4d…`](https://stellar.expert/explorer/testnet/tx/a221fa4a4de47aa8c010f7994f31859cffa68a3f7fa1f3f4a58279c82a254c93) | **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`](https://github.com/pedro-pelicioni/stellarsight/blob/main/docs/status/upstream-e2e.json) · relay source: [`e2e-proxy/`](https://github.com/pedro-pelicioni/stellarsight/blob/main/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 \` 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`](https://github.com/pedro-pelicioni/stellarsight/blob/main/docs/status/rejections.json) ## Scripted batches Breadth of settlement, run serially and labeled as scripted. Not a load test — [LOAD-BASELINE.md](/evidence/load-baseline) 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…`](https://stellar.expert/explorer/testnet/tx/2bf4a54c7af24aa4ee032c73b84172a7d09fa71eb36fafcff8c94c5609e6b5a9) 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`](https://github.com/pedro-pelicioni/stellarsight/blob/main/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)](https://api.cdp.coinbase.com/platform/v2/x402) | reference | 20 | `items` | 40/40 | | [STELLARSIGHT](https://stellarsight.xyz) | 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](https://x402.org/facilitator)) — /supported answers 200; /discovery/resources answers 404 * **x402.rs facilitator** ([https://facilitator.x402.rs](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: ```bash theme={null} # 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: ```bash theme={null} 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…`](https://stellar.expert/explorer/testnet/account/GC4E5Q6WQATXWA5FCL5OV7C7HVQUZOAGXVKNHNCIL2EDY3YNAGRLKADT), the FEEPAYER — not the payer. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.