Check who your x402 agent is paying, before it signs

factline — Tue, 20 Oct 2026 18:05:53 +0000

An x402 client pays whatever payTo the server puts in its 402 response. Budget caps answer "how much". Nothing in the default flow answers "to whom".

So we gave our pay guard the Lazarus Group's wallet as the payTo of a real, healthy seller and asked whether to pay:

curl "https://factline.dev/v1/pay/guard?url=https://api.onesource.io/&pay_to=0x098B716B8Aaf21512996dC57EB0615e2383E2f96&amount_usd=0.05&max_usd=1"

{
  "decision": "deny",
  "reasons": ["payTo 0x098B716B8Aaf21512996dC57EB0615e2383E2f96 is on the OFAC sanctions list (LAZARUS GROUP)"],
  "seller": { "origin": "https://api.onesource.io", "known": true, "payers_30d": 321, "uptime_30d": 1, "median_ms": 1197 },
  "ttl": 600
}

The seller itself is fine (321 paying wallets in 30 days, answered every nightly check). The wallet is not. That is the case a budget cap never catches: a prompt-injected or swapped payTo on an otherwise normal endpoint.

What it checks

payTo against the OFAC list. OFAC is the list that publishes wallet addresses. (EU, UN and UK lists cover people and companies; those are a separate screen.)
The seller's track record from our nightly probes of x402 Bazaar sellers: does it answer a valid 402, how many wallets paid it in 30 days, how long has it been listed. Unknown sellers get a domain age check.
Your budget: amount_usd against max_usd, plus the seller's usual price for comparison.

Answer: allow, review or deny, with reasons in plain English. Free, cached for 10 minutes per seller and payTo.

One line on an x402 client

npm i @factline/x402-pay-guard

import { wrapFetchWithPayment, x402Client } from "@x402/fetch";
import { ExactEvmScheme } from "@x402/evm";
import { withPayGuard } from "@factline/x402-pay-guard";

const client = withPayGuard(
  new x402Client().register("eip155:8453", new ExactEvmScheme(signer)),
  { maxUsd: 1, onReview: "block" },
);
const fetchWithPay = wrapFetchWithPayment(fetch, client);

The official x402 client already has a hook that runs right before it signs (onBeforePaymentCreation, with selectedRequirements.payTo). The guard plugs into that, so a deny aborts before any signature exists. If the guard is unreachable it pays by default (failOpen: true); set it to false if you would rather not pay unchecked. MCP agents can call the same check as the x402_pay_guard tool on https://factline.dev/mcp/kyc.

What it does not do

It is a denylist and a track record, not chain analytics. It will not see indirect exposure (a fresh wallet funded by a listed one). If you need that, pair it with a risk-scoring provider. For an agent paying small x402 bills, a free check of the obvious cases before signing is the part most clients are missing today.

Code: github.com/factline-dev/x402-pay-guard. Live seller and facilitator health: factline.dev/x402/health and factline.dev/x402/facilitators.

We probe 517 paid x402 APIs every night. Here is what the first numbers say

factline — Mon, 12 Oct 2026 21:44:19 +0000

AI agents that pay for APIs with x402 usually pick a seller from a directory listing. A listing tells you a service exists and what it costs. It does not tell you whether it answers, how fast, or whether anyone else pays it.

So I started probing them. Every night a small script on a Raspberry Pi takes the x402 origins in the Coinbase Bazaar with at least two paying wallets in the last 30 days (517 so far, about 500 per night), sends one unpaid request to a real paid endpoint, and records whether a valid 402 Payment Required challenge comes back and how long it took. It never pays. The results are a free table and JSON feed: factline.dev/x402/health and GET https://factline.dev/v1/x402/sellers.

This is after two nights, so read it as a first snapshot, not a trend.

What is in the sample

517 origins (hosts) with 2,555 paid resources between them, 4.9 per origin on average, 72 at most.
Selection: origins with 2 or more distinct paying wallets in the Bazaar over 30 days. Payer counts include sellers paying themselves, so treat them as an upper bound.

1. Almost everything answers

	Night 1	Night 2
Probes	500	501
Valid 402 challenge	496 (99.2%)	500 (99.8%)

Over both nights, 513 of the 517 origins answered every time. 3 never answered, 1 answered once out of two.

That is better than I expected. The catch is the next section: answering is not the same as answering fast.

2. The sellers people pay are three times faster

Origin group	Origins	Average uptime	Median response
10 or more paying wallets	106	100%	501 ms
2 to 9 paying wallets	411	99.1%	1,609 ms

The slowest valid 402 took 26 seconds. The fastest took 139 ms. An agent that waits 26 seconds for a price quote before it has even paid is going to time out or give up, and the payer counts suggest buyers notice.

3. Calls are concentrated in very few hosts

Paying wallets (30 days)	Origins	Calls (30 days)	Share of calls
100 or more	5	466,991	70%
10 to 99	101	161,472	24%
2 to 9	410	40,817	6%

Five hosts carry 70% of the paid calls in this sample. Four out of five sellers share 6%. If you are building on x402 as a seller, the honest takeaway is that a listing alone does very little.

4. Base is the default, Solana is the common second

Networks offered	Origins
Base only	309 (60%)
Base and Solana	106 (21%)
Base, Solana, Polygon and Arbitrum	38 (7%)
Solana only	3
Base Sepolia (testnet) only	5

508 of 517 origins (98%) accept USDC on Base mainnet, and 181 (35%) also accept Solana. Five are listed with paying wallets but advertise only Base Sepolia, the testnet.

5. Most prices are under a cent

Lowest price per call	Origins
under USD 0.001	1
USD 0.001 to 0.01	294 (57%)
USD 0.01 to 0.10	206 (40%)
USD 0.10 to 1	10
USD 1 or more	5

What I would do with this as an agent builder

Check that a seller answers its 402 quickly before you route traffic to it. A slow challenge is a cheap early signal.
Prefer sellers that offer more than one network, so a wallet on either Base or Solana can pay.
Do not read a high call count as trust. Look at distinct payers and response times together.

The data

Table, filterable by uptime and payers: https://factline.dev/x402/health
JSON for your agent, free: GET https://factline.dev/v1/x402/sellers
Method: one unpaid request per origin per night against a listed paid resource; "ok" means a parseable x402 challenge (HTTP 402 with payment requirements). Nothing is paid, nothing is stored beyond status, time and date.

I run this as part of Factline, which sells official-records checks to agents over x402 (company checks, sanctions, supplier invoices). The health data is also behind a payee check that tells an agent whether to pay an x402 seller it has never used. But the table above is free, and I will post an update once there are 30 nights of data.

If you run an x402 service and want your origin added or removed, email hello@factline.dev.

DEV Community: factline