Does an x402 seller deliver what it declares?
Most x402 measurement counts transactions. 402Scope buys the resource and checks whether what arrived matches what the provider said it would deliver.
Four chains, one method. Raw data published with SHA-256 hashes, every observation signed, every correction published.
For facilitators: a verdict on every payment you settle, a Bazaar ranked by what actually works, and optional refunds and escrow, settled in seconds, when a seller breaks its own terms.
Reading live from this site’s own API…
Free check
Should an agent pay this endpoint?
Paste an endpoint and get a decision: sell, sell and warn or hold, with the reasons. It reads the paid measurements behind the endpoint and checks its 402 challenge. No payment is made and no malformed request is sent.
The decision follows a seller policy set on the fault rate upper bound. Adjust the two thresholds to your own tolerance.
Right now
Two ways to count the same month
Every figure quoted about the size of this ecosystem is a transaction count, because that is what an explorer shows. Counting money gives the opposite picture.
loading…
Coverage
Three layers, not one
These measure different things and are not interchangeable. Only the first says anything about whether what arrives is correct.
loading…
The paid panel
Bought every two hours, checked against a reference
Each endpoint is paid for and its response compared with an external reference. The relationship column shows which providers have contact with the observatory and which do not; the method is identical either way.
loading…
What a fault rate upper bound is
A provider with no faults in 34 observations has not proven it never fails. The upper bound is the worst fault rate consistent with what has been observed, at 95% confidence (Wilson interval). It is what a policy can sit on while a provider is still new. It is not an estimate of the provider’s rate.
Two providers at n=34, one with zero faults and one with five, return bounds of 10.2% and 30.1%. A buyer that holds anything above 15% holds the second from day one.
n ≥ 100. Confidence established; the figure can be cited.
n from 20 to 99. Low confidence: enough to support a policy, not to publish a rate.
n below 20. No rate, but the bound is still returned.
402Scope Trust
From a measurement to a payment decision
Measurements are only useful if an agent acts on them before it pays. 402Scope Trust puts the scores where the payment is decided: in a Soroban contract on Stellar, and in the agent’s own wallet.
Running end to end on Stellar testnet
Bonded attesters, onchain
Independent attesters lock a bond, make real paid calls and publish scores per endpoint and per seller in a Soroban registry. Each score commits to a Merkle root of the calls behind it, and the contract checks any call against it. A false score can be slashed.
A wallet that refuses untrusted sellers
An OpenZeppelin smart account with the 402Scope trust policy checks the seller inside its own authorization. Payments to sellers its chosen attesters do not trust fail to sign, whatever the agent’s code does.
No facilitator lock-in
The agent wallet paid through OpenZeppelin’s hosted Built on Stellar facilitator unchanged. Any x402 facilitator can add trust hooks to flag or refuse payments, rank its Bazaar listing, and share its listing with the observatory.
Built on Stellar’s own standards, so wallets and explorers can check the outputs without our code: SEP-41 payments and bonds, SEP-53 signed receipts and claims, SEP-1 attester identity, and SEP-55 verified contract builds attested on GitHub. Which standards, and where.
Delivery declarations
One vocabulary for what a buyer gets
x402 standardised how a seller asks to be paid, not what the buyer receives. 99.84% of resources declare the shape of their response; few declare anything about its quality, and those that do use six incompatible vocabularies.
402Scope publishes one: freshness, quality and provenance, carried by x402 itself as an extension. A seller is held only to what it declared, and only a breach of its own declaration is its fault.
- Terms in the 402 challenge.
extensions.declarationsstates what the seller commits to before payment, such as a maximum data age, and what it does if it breaks that. - A declaration per response. The
X-402-Declarationheader states the age and source of this response, and the seller’s delivery receipt signs it with the body, as a SEP-53 Stellar signed message any wallet or SDK can check. - Two tiers. In-band,
usableandproviderAtFaultlet a settlement layer skip or credit one charge. Out-of-band, the observatory’s fault rate bound tells a seller policy when to stop selling a provider that is honest but consistently broken. - Sellers that never adopt it are still read through the x402-declarations adapters, labelled as declared or inferred.
// PAYMENT-REQUIRED → extensions "declarations": { "info": { "version": 1, "freshness": { "maxAgeSeconds": 60, "basis": "live" }, "provenance": { "source": "EIA-930", "verifiable": true }, "perResponse": true, "onBreach": "refund" } } // paid response X-402-Declaration: { "freshness": { "ageSeconds": 12 } } X-402-Receipt: signed by the payTo key, binds payment, body and declaration
Build with it
One package, three roles
One open-source package, with one call for each side of a payment. Everything below works today, without a key or registration.
Know what your payments paid for
A verdict on every payment you verify and settle, flagged or blocked; your Bazaar ranked by measured quality; refund-backed sellers first.
scopeFacilitator(facilitator, { trust, mode: 'flag' })
For facilitators
Show what you deliver
Your delivery terms in the 402 challenge, a signed receipt with every paid response, a live badge, and an optional refund bond that makes buyers prefer you.
const scope = scopeSeller({ secret, terms })
app.use(...scope.middleware)
Make your badge
Pay only for what works
A check before paying, a check of what arrived after paying, and automatic refunds from sellers that offer them. Also as an MCP tool and in Python.
const pay = scopeFetch({ client, refunds })
Or ask the API
Ask before you pay
One call returns the signed aggregate for an endpoint: state, fault rate upper bound, sample and signature.
curl "https://402scope.org/v1/provider?endpoint=https://api.example.com/x"
An MCP tool for your agent
Add it to Claude, Cursor or any MCP client. observatory_decision returns sell, sell and warn or hold from the observatory’s measurements, on your thresholds.
{ "mcpServers": { "402scope": {
"command": "npx",
"args": ["-y", "github:arturete58-sys/402scope-trust", "mcp"] } } }
Who and how much, enforced by the wallet
A smart-account wallet that pays only sellers the chosen attesters trust, within a daily budget, managed by the owner’s passkey.
See it onchainVerify receipts and attestations in Python
pip install "git+https://github.com/arturete58-sys/402scope-trust#subdirectory=python"
API
No key, no registration
60 requests per IP per 5 minutes; a batch of 50 counts as one. Every response that carries a rate carries the bound, n and the window it rests on.
GET /v1/provider?endpoint=<url> signed aggregate for one provider
POST /v1/providers {"endpoints":[...]}, up to 50
GET /v1/endpoints what is currently measured
GET /v1/history?endpoint=<url> the series, with the rule changes in it
GET /v1/coverage what is covered, by layer
POST /v1/verify check a third party's signed attestation
POST /v1/watch alert me when a provider crosses a bound
POST /v1/report contribute counts from a facilitator
GET /v1/market market size, by chain, each with its criterion
GET /v1/unused endpoints that answer but nobody pays
GET /v1/latency measured settlement latency, with a suggested timeout
GET /v1/health whether this observatory is working
Method
Everything is reproducible
Block ranges, ledger ranges, thresholds and criteria are published. Every figure in a report ships with the query that produces it.
- The observation table is append-only. A database rule prevents modification of historical records. When a rule changes, the change is logged with an explicit scope declaring which observations it invalidates.
- Aggregation has a floor. Fault rates are published above n=100 with a Wilson interval. Below that the API says so rather than returning a number that cannot be defended.
- Signatures anyone can check. Every aggregate is signed by the observatory. Delivery receipts and endpoint claims use SEP-53, Stellar’s standard for signed messages, so they can be checked with any Stellar SDK, without our code. Claim your endpoint.
- Local canaries with known-bad behaviour run alongside the real panel, so a silent failure of the instrument itself is detectable.
- Nothing is charged to the providers measured. The observatory has no commercial relationship with any provider in its panel. Scores are never for sale.
- Corrections. Figures later found wrong are corrected in public, including the ones that were more flattering before they were wrong. One correction withdrew a whole table rather than restate it; another was about the correction machinery itself failing. All corrections.
- Right of reply. Any provider named in any report is contacted before publication and may submit a response, published unedited alongside the data concerning them.
- Facilitators can contribute. A facilitator can share its Bazaar listing and the resources it settles, so coverage reaches providers no catalogue lists. Contributions add resources to measure; they never change a result.
Self-check
Is this instrument working
Each check below corresponds to a defect that reached production once. They report and do not repair.
loading…
Open source
Code, data and method on GitHub
If any figure here is wrong, saying so is useful. It has happened before and the correction was published.
Method, raw data with hashes, reports, corrections and issues.
402scope-trustSoroban contracts, agent wallet policy, receipts, declarations and facilitator hooks. Apache-2.0.
x402-declarationsCall any x402 endpoint from its declared schema and read what the provider says about its data. On npm, MIT.