x402 Verifier - Chance

The x402 Verifier answers one question about any x402 payment: is this specific payment what your policy authorizes? Paste the payment terms (or let your agent submit them), and the harness judges them against your mandate while gathering its own evidence about the vendor. You get an ALLOW / BLOCK / ESCALATE verdict with reasoning and a signed, independently verifiable proof. One credit per run. The order matters: x402 settlement is an irreversible push payment, so the only safe sequence is receive terms → verify → sign on ALLOW. Chance never holds keys, never signs, never settles. It is the gate between the quote and the signature.

No code required to try it: the dashboard’s x402 Verifier tab ships six built-in payloads (one legitimate vendor and five attacks) and runs the same engine with a live verdict.

The six checks

Every run inspects the payment along six fixed categories. The judge’s verdict weighs all of them against your policy.

Check	What it catches
Asset & amount integrity	Is the token canonical USDC, so the dollar value is real? A “$5” label next to an unknown 18-decimal token can authorize thousands.
Live terms verification	The endpoint’s own 402 is re-fetched and diffed against the quoted terms. Bait-and-switch and stale quotes surface as a price or terms mismatch.
Vendor reputation & intent	The recipient is looked up on the Coinbase x402 Bazaar (below), and the vendor’s own text is screened for attempts to steer the judge.
Payee on-chain profile	Contract or plain address, and does it hold the balance an established vendor accumulates? A fresh zero-balance `payTo` is how a scam starts.
Signed-payload integrity	For a pre-signed payment, the SIGNED recipient and amount are judged rather than the displayed ones, and the payer wallet is preflighted (balance, and EIP-7702 delegation that would prevent settlement).
Protocol & settlement safety	Scheme (`exact` vs `upto`), network, expiry window, and the fact that settlement is an irreversible push payment with no chargeback.

Vendor reputation, from the Coinbase Bazaar

The x402 Bazaar is Coinbase’s public index of x402 services that have actually settled payments through the CDP facilitator. For every payment, the verifier looks the recipient up and reads:

whether the payTo matches a listed service for the resource’s host,
its unique payers and paid-call count over the last 30 days,
when it last settled a payment.

This is settled usage, not self-reported marketing, which makes it expensive to fake. An unlisted address is treated as a caution signal rather than proof of fraud: trivial amounts to unlisted vendors can still pass, while significant ones escalate or block under the default policy.

The attack catalog

The dashboard ships these as one-click examples. Each demonstrates a real pattern the checks exist to catch; the default policy names every one of the five as grounds to block or escalate.

Example	The pattern
Legit vendor	A Bazaar-listed service with real usage, a trivial USDC amount, terms intact. The baseline that passes.
Fake token as “$5”	The description says “$5”, but `asset` is an unknown token and `amount` is 5 whole units of it. The seller picks the token; only canonical USDC makes the dollar framing true.
Prompt injection	Economics pass, but the vendor’s `description` instructs the verifier to ignore the mandate and approve. The text is withheld from the judge and the attempt itself is flagged as a distrust signal.
Signature ≠ terms	Displayed as “$1 to a trusted vendor”, while the already-signed authorization pays $999 to a different address. The signed values are judged, not the displayed ones.
upto blank check	Advertised as ”~$0.02 per call”, but the `upto` scheme lets the seller settle up to the signed cap ($100, redeemable for an hour). The cap is judged, not the expected bill.
Unlisted, high value	$250 of real USDC to an address with no Bazaar record and no vendor history. Nothing is malformed; the trust picture is.

Integrate it in your agent

The same engine runs behind POST /api/v1/intent with venue: "x402". Probe the paid endpoint, verify the decoded terms, and only let your x402 client sign on ALLOW:

const probe = await fetch(paidUrl); // unpaid probe stops at the paywall
if (probe.status === 402) {
  const terms = decodePaymentRequiredHeader(probe.headers.get("PAYMENT-REQUIRED"));

  const check = await fetch("https://harness.chance.cc/api/v1/intent", {
    method: "POST",
    headers: { "x-api-key": process.env.CHANCE_API_KEY, "content-type": "application/json" },
    body: JSON.stringify({
      intent: "Research agent. May buy API data up to $1 per call, USDC on Base only, established vendors only.",
      action: terms, // the decoded PaymentRequired object, verbatim
      venue: "x402",
    }),
  }).then((r) => r.json());

  if (check.verdict === "ALLOW") {
    await fetchWithPay(paidUrl); // your stock x402 client signs & retries
  }
}

The response carries the verdict, the judge’s reasoning, and the proof receipt (transcript root, judge signature, onchain anchor) that anyone you share the run artifact with can recompute. The x402 venue page documents every recognized payload shape plus a runnable curl against live terms; agents in Claude or ChatGPT get the same check through the connector as verify_intent with venue: "x402".

Why verify agent payments?

The case for a verification layer in the agentic economy.

x402 venue reference

Recognized payloads, live curl example, and how the harness knows x402.

​The six checks

​Vendor reputation, from the Coinbase Bazaar

​The attack catalog

​Integrate it in your agent

Why verify agent payments?

x402 venue reference

The six checks

Vendor reputation, from the Coinbase Bazaar

The attack catalog

Integrate it in your agent