> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chance.cc/llms.txt
> Use this file to discover all available pages before exploring further.

# x402 Verifier

> Six independent checks on any x402 payment before it's signed: asset integrity, live terms, Coinbase Bazaar reputation, payee profile, signed-payload integrity, and settlement safety.

The x402 Verifier answers one question about any [x402](https://docs.cdp.coinbase.com/x402/welcome)
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.

<Tip>
  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.
</Tip>

## 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](https://docs.cdp.coinbase.com/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 a fail-closed rule makes the attempt disqualifying on its own, at any amount. |
| **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:

```ts theme={null}
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](/venues/x402) documents every recognized payload shape
plus a runnable `curl` against live terms; agents in Claude or ChatGPT get the
same check through the [connector](/connectors) as `verify_intent` with
`venue: "x402"`.

<CardGroup cols={2}>
  <Card title="Why verify agent payments?" icon="shield-halved" href="/x402/why-verify">
    The case for a verification layer in the agentic economy.
  </Card>

  <Card title="x402 venue reference" icon="code" href="/venues/x402">
    Recognized payloads, live curl example, and how the harness knows x402.
  </Card>
</CardGroup>