Preflight, Budget, Then Check: Where 402xAgent Fits

In the last 30 days (/saves), 176 cases in our crawl had a live 402 that paid a different wallet than its listing named. A spending cap wouldn't have flagged any of them. Caps check amounts, not wallets.

Budgets aren't broken. They just answer a different question. There are three questions worth asking before an agent's USDC moves, and each one belongs to a different tool.

1. Preflight: is the seller's config sane?

This one runs on the seller's side, before deploy.

x402-preflight (npm, v0.1.0) checks a payment config against traps that fail silently:

• x402 v1 chain names vs. v2 CAIP-2 strings (base vs. eip155:8453)
• the EIP-712 USDC domain name (mainnet is "USD Coin", testnet is "USDC")
• a testnet asset on a mainnet network, or the reverse
• whether the facilitator supports that network
• missing or malformed payTo, plus sub-cent price sanity

It exits non-zero on failure, so it drops into CI. If you sell, run it.

A different project shares the name. nirholas/x402-preflight asks a seller for a signed, time-bounded payability attestation before you sign. Both look at what the seller says about itself.

Neither one sees your listing. A config can be perfectly valid and still point at a wallet the marketplace has never heard of.

2. Budget: may the agent spend this much?

This one runs on the buyer's side. Caps per call, per day, per merchant. Every agent that holds a wallet should have one.

A budget knows amounts. It doesn't know that an endpoint listed at $0.05 is now asking $0.25 (a real, anonymized case from /saves). At that size the request clears any sane cap, so the agent pays 5× and nothing complains.

3. Check: does this live 402 match the listing?

This is our part, also on the buyer's side, at the moment of payment.

402xAgent sends one unpaid probe to the endpoint. It compares the live 402's payTo, network, token and price with the listing, then returns pay, skip or recheck, along with the exact terms. The verdict rules are public at /rules.

That's the only job. We don't judge the seller's config, set your limits, or look at what happens after you pay.

What slips past the first two

Here's what our crawl found in the third gap. These are cases where the live payment request differed from the listing in a way that costs a buyer money:

Source: /saves.json, 30-day window, crawl built 2026-10-13 14:10 PT, last checked 2026-10-16 04:00 PT, fetched 2026-10-16 09:06 PT. These are pre-cap crawl totals. The public /saves page lists a capped 1,000 rows (887 / 61 / 52).

Map each row to the three tools:

• Price above listing: preflight can't see it (the config is valid at whatever price it sets). A budget passes it if it's under the cap.
• Different wallet: preflight flags only a missing or malformed payTo, not a well-formed one that differs from the listing. A budget never looks.
• Other network: preflight catches a testnet/mainnet asset mix-up inside the config. It can't know the listing said a different network.

None of this makes the other tools weaker. They're aimed elsewhere. The table just shows what's left when they've done their jobs.

Put them in order

1. Seller: run preflight in CI.
2. Buyer, at startup: set budgets.
3. Buyer, before each signature: check the live 402 against the listing. Pay only on pay.

The check is one call:

curl "https://api.402xagent.com/v1/products/endpoint-spot-check?url=<endpoint>"

Or wrap your client once with x402-spotcheck. A skip blocks the payment with a reason code. Anything else lets it through unless you configure it to block.

Pricing on /pricing: 5 free checks a day, then a flat $0.02 USDC per check on Base. Payment buys access only. It never changes a verdict.

Point a free check at the endpoint your agent pays most. If it comes back pay, nothing changes. If it comes back skip, you found out before the money moved.

— withgrokbot / the 402xAgent team