risk data for machine payments
For developers
API
Every route is a plain HTTP call — no SDK required. Access is granted on request, and limits are agreed when you are onboarded.
Getting started
- Intercept the 402When your x402 client receives a
402, decode thePAYMENT-REQUIREDheader: it is base64-encoded JSON. - Ask usSend the envelope to
POST /v1/prepayalong with the resource URL and your ownmaxPrice. - Act on the verdict
block— do not sign.warn— sign but log it.allow— a normal payment. Every decision comes with its reason inreasons.
Verdict before payment
This is the main call. It does not answer “is this seller any good” but “is this particular transaction going somewhere it should not” — comparing the envelope the agent is about to sign against everything we have observed.
POST https://nod402.com/v1/prepay
content-type: application/json
{
"envelope": { "x402Version": 2, "accepts": [ {
"scheme": "exact", "network": "eip155:8453", "amount": "10000",
"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"payTo": "0x…", "maxTimeoutSeconds": 60 } ] },
"url": "https://seller.example/api/x",
"maxPrice": "0.10"
}
→ {
"verdict": "allow" | "warn" | "block",
"score": 82, "grade": "B", "status": "scored",
"reasons": ["GRADE_B: score 82", "PRICE_DRIFT: 30% above catalogue"],
"envelope_checked": { "scheme": "exact", "network": "eip155:8453", "payTo": "0x…" },
"alternatives": [ { "url": "…", "grade": "A", "score": 91 } ]
}The envelope field accepts either an object or the raw base64 header
string — you do not have to decode it yourself.
What blocks and what warns
block
- recipient changed, or differs from the catalogue
- a test network in the envelope
- price at least twice the catalogue price
- unencrypted
http://channel - recipient on a sanctions list
- your
maxPriceexceeded - grade F
warn
- grade D
- not enough observations for a score
- new endpoint with almost no payers
- price drift between 20% and 2×
- recent probes did not return
402 - a test network seen previously
Other routes
| Route | Returns | Indicative price |
|---|---|---|
| GET /v1/probe?url= | live check: real request to the endpoint right now | included |
| GET /v1/endpoint?url= | grade, score, flags, last probe | included |
| GET /v1/endpoint/full?url= | observation history and settlements | $0.005 |
| GET /v1/wallet?chain=&address= | wallet grade, agent likelihood, sanctions | included |
| GET /v1/wallet/full?chain=&address= | counterparties and activity | $0.005 |
| POST /v1/prepay | verdict on a live envelope | $0.002 |
| GET /v1/search?q= | endpoint search with scores | $0.01 |
| GET /v1/market/stats | market aggregates | always open |
| GET /badge/<id>.svg | grade badge | included |
| GET /health | collector status and counters | included |
Self-description
/openapi.json · /llms.txt · /skill.md · /.well-known/x402 · /sitemap.xml
Disputing a score
Scores are built only from public data. If you own an endpoint and believe a score is wrong:
- Write to usEmail info@nod402.com with the endpoint URL. We send back the breakdown: what exactly drags the score down and on which observations.
- Report the errorIf an observation is wrong — for example the prober hit you during maintenance — tell us the URL and the time. We recompute.
- Your reply appears next to the scoreWe do not delete accurate observations, but we always publish your response on the page alongside the score.
FAQ
How is the score calculated? Is it a neural network?
No, and that is deliberate. Scoring is deterministic: the same input always produces the same result. No model, no learning on the fly.
We are not publishing the methodology yet — it is still being refined, and published weights would immediately be gamed. Endpoint owners can request a breakdown of what drags their score down, and we take objections.
Why does it say “not enough data” instead of a grade?
A score appears once there are enough observations to stand behind it. We do not assign a
low grade for missing data — the whole catalogue would look dead on day one. The verdict in that
case is warn: unknown is a risk, not a clean bill of health.
What can't you see?
The batch-settlement scheme moves payments into off-chain vouchers: only the
channel opening and the batched claim ever reach the blockchain. Nobody sees the individual
payments there, including us.
On Solana we work from known facilitators, so those numbers are a lower bound. On Base we read blocks in full.
Polygon and Arbitrum are excluded on purpose: a block census found four payments in two hours on Polygon and none at all on Arbitrum.
Schemes upto, auth-capture, tab and bridge
if they leave a different on-chain trace. Live facilitators advertise tab and
bridge, which are not in the protocol documentation at all.
Do you hold funds? Do you need a licence?
We hold nothing in any form: no custody, no escrow, no facilitator role, no credit. Not one payment passes through us — we sell data and signals.
Will your probing break my endpoint?
At most one request per second per host, an honest User-Agent that links back
to us, and we only ask for the payment challenge: we never pay and never take content.
Is it worth checking every single call?
No. Settlement at a facilitator costs about $0.001 and the median ticket on this market is around a cent. It makes sense to check a new seller, a change of payment details, and any payment above your own threshold — not every repeat call to an endpoint you already trust.
That is why final pricing is agreed at onboarding rather than posted as a price list.
Next
Market overview →
Payments, median ticket, who pays whom, who settles.
Endpoints →
Scores, findings and the full observation history per resource.
Wallets →
Payers, recipients and facilitators, listed separately.
Facilitators →
Who actually settles — including those in no public registry.