Credit bureau for the agent economy
A human checks reviews and verifies payment details before buying. An agent has milliseconds and checks nothing. nod402 plugs into the moment of signing: one API call, and back comes a verdict with its reason.
A real request, right now: we wait for 402, decode the envelope
and compare it against what we have observed before.
Or skip ahead and see how it plugs in. API access is granted on request — leave a note.
Why a limit is not enough
risk data for machine payments
maxPrice is compared against the wrong numberThe usual objection: “I have a limit set, my agent can't overpay.” But the limit is compared against the price the seller just sent, not the price it advertised in the catalogue. Nobody checks the gap between those two numbers.
An endpoint from a public catalogue advertises one price and then asks for 400 times more in the live response. An agent holding a “no more than a cent” limit sees an amount inside its limit, signs, and moves on. The overpayment surfaces in a monthly report, by which point there is nothing left to claw back.
This is not a one-off: we recorded 57 such gaps in 30 days, with a typical one around three times.
We keep the catalogue price next to the observed one and compare them on every probe. Gaps above a thousandfold are excluded from the statistics: almost always that is a token with different decimals, not an overcharge.
What is already happening
We found everything below ourselves, probing live endpoints from public catalogues over the last 30 days. Each case has a page with the underlying observations.
Worst case on record: an endpoint asking 400 times the price listed in its catalogue.
PRICE_ABOVE_QUOTEListed in catalogues as paid resources, yet they return no payment challenge. The agent burns a call, time and context — and in the logs it looks like the agent's own fault.
NOT_RESPONDINGThe envelope does not follow the spec: a field carries its old name, the network is not in CAIP-2 form, required fields are missing. A client with a strict parser simply crashes.
E_SCHEMAAn endpoint from a production catalogue asking for payment on a test network. The agent signs, burns a nonce and gets nothing: no money moves, and no answer arrives either.
TESTNET_IN_PRODUCTIONThe recipient wallet in the live response does not match the catalogue, or changed between probes. The classic hijack signature: the agent pays the wrong address and the seller never learns the money stopped arriving.
PAYTO_DIFFERSThe share of probes where the envelope arrived strictly to spec with nothing to report. Most sellers are honest — but you only learn which one you got by checking.
ENVELOPE_OKHow it works
The agent receives a 402. Before signing it sends us the envelope and
gets back a verdict with reasons. We compare what the agent is about to sign against
what we have seen: probe history, the catalogue price, the previous recipient, on-chain
settlements and sanctions lists.
// 1. the agent got a 402 and decoded the header
POST https://nod402.com/v1/prepay
{
"envelope": <decoded PAYMENT-REQUIRED>,
"url": "https://seller.example/api/x",
"maxPrice": "0.10"
}// 2. the seller is fine, the transaction is not
{
"verdict": "block",
"grade": "B", "score": 76,
"reasons": [
"PAYTO_DIFFERS: wrong recipient",
"PRICE_ABOVE_QUOTE: 5x the catalogue price"
],
"alternatives": [{ "url": "…", "grade": "A" }]
}maxPrice exceeded, grade F.block — and that
is the part that matters.
Every decision comes with its reason, and a score can be disputed.
Quick start
Integration takes an evening. Below are the real routes and real responses — access is granted on request, and from there it is an ordinary HTTP call.
guard() function below is four lines around what you already have./v1/prepay route takes the decoded PAYMENT-REQUIRED
and your limit, and returns a verdict with reasons.block; log and continue on warn;
pay as usual on allow.// TypeScript — a wrapper around your x402 client
async function guard(envelope, url, maxPrice = "0.05") {
const r = await fetch("https://nod402.com/v1/prepay", {
method: "POST",
headers: { "content-type": "application/json" },
body: JSON.stringify({ envelope, url, maxPrice }),
});
const { verdict, reasons } = await r.json();
if (verdict === "block") throw new Error(reasons[0]);
if (verdict === "warn") console.warn(reasons.join("; "));
return true; // safe to sign
}# Python
import httpx
def guard(envelope, url, max_price="0.05"):
r = httpx.post(
"https://nod402.com/v1/prepay",
json={"envelope": envelope, "url": url,
"maxPrice": max_price},
).json()
if r["verdict"] == "block":
raise RuntimeError(r["reasons"][0])
return rcurl "https://nod402.com/v1/endpoint?url=\
https://seller.example/api/x"
{ "grade": "B", "score": 76,
"status": "scored",
"flags": ["NEW_UNKNOWN"],
"last_probe": { "status": 402, "latency_ms": 181 } }Add /full for the observation history and settlement
aggregates behind the score.
curl "https://nod402.com/v1/wallet?\
chain=base&address=0x…"
{ "grade": "C", "score": 58,
"agent_likelihood": 0.91,
"sanctioned": false,
"payments_sent": 143, "payments_received": 0 }No other public x402 service offers this. Sellers need it to decide whether to serve an agent and how large a channel to open.
Self-description for agents and catalogues: /openapi.json · /llms.txt · /skill.md · /.well-known/x402 · full documentation
Why we see more
Public registries list only the services that announced themselves. But x402 is open, and anyone can run a settlement service. In our data 93% of the addresses settling payments appear in no registry at all. An explorer that walks catalogues never sees those settlements.
Payments also get wrapped in Multicall3, and EIP-3009 has four signature variants. Searching for a single selector misses more than 90% of the market — we decode all four.
Existing services answer “is this endpoint any good”. Nobody answers “who should I serve”. We score the wallet, estimate agent likelihood from how evenly payments are spaced, screen against sanctions lists, and map the links between payers.
This became necessary very recently: the
batch-settlement scheme forces the seller to deliver before the money is secured
on-chain. They now carry credit risk they never had before.
A new endpoint gets the status “not enough data”, not a low grade. The score appears when there are enough observations to stand behind it — marking something down for missing data would be dishonest.
The verdict in that case is warn,
not allow: unknown is a risk, not a clean bill of health.
Dashboard
Access comes with a dashboard: how the machine payment market is actually built, who pays whom, which sellers have a real customer base, and where the same wallet is simply moving money in a circle. For instance: 342 payments above $100 account for 94% of all volume. Any market estimate built on the mean ticket is off by orders of magnitude — we work from the median, $0.01.
Payments, median ticket, who pays, who gets paid, who settles, endpoint health, breakdowns by network and by day.
9,198 paid resources. Tabs for scored, flagged, not responding and all. Every one carries its full observation history.
Payers, recipients and facilitators listed separately. Scores, agent likelihood, sanctions screening, counterparties.
Who actually settles — and separately, those we found in blocks that appear in no registry.
Pricing
Right now we onboard teams that already run agents in production or operate a paid endpoint — with them it is clear what needs improving. The prices below are indicative; the final terms are agreed when you are onboarded.
Pay per request, no subscription, no minimum
For owners of paid endpoints
Facilitators, wallets, analytics
FAQ
x402 is a protocol where a server answers 402 Payment Required
and the client pays in stablecoin to get the resource. Fully automatic, no sign-up, no card.
Convenient — and completely unguarded: an agent cannot read reviews or verify payment details,
and a signature is irreversible.
[FILL IN: who builds nod402 — a name or a company, where the problem came from, a link to GitHub or a profile. This is the one block that cannot be generated from data, and the one a reader of a trust product most wants to see.]
No, and that is deliberate: scoring is deterministic, the same input always gives the same result. No model, no learning on the fly.
We are not publishing the methodology yet — it is still being refined. Endpoint owners can request a breakdown of what drags their score down, and we take objections.
It would, if you checked every call. Settlement at a facilitator costs about $0.001 and the median ticket here is around a cent.
Checking makes sense for a new seller, a change of payment details, and any payment above your own threshold — not for every repeat call to an endpoint you already trust. That is why the final price is agreed at onboarding rather than posted as a price list.
The batch-settlement scheme moves payments into off-chain
vouchers: only the channel opening and the batched claim reach the blockchain. Nobody sees the
individual payments there, us included.
On Solana we work from known facilitators, so those numbers are a lower bound. Polygon and Arbitrum we do not cover on purpose: a block census found four payments in two hours on Polygon and none at all on Arbitrum.
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. That is not a workaround, it is a different class of service.
Write to us with the endpoint URL. We will send back exactly what is dragging the score down and on which observations. If an observation is wrong — say our prober hit you during maintenance — we recompute. Accurate observations stay, but your response is always published next to the score. The procedure.
At most one request per second per host, an honest User-Agent
linking back to us, and we only ask for the payment challenge: we never pay and never take
content.
Your email and a line about what you run — an agent, an endpoint, a platform. We onboard in order, starting with whoever already has live traffic.
Or write straight to info@nod402.com. Dashboard accounts, alerts and badges are in development. Your email is used only to answer about access.