x402

Verify an x402 payment against your mandate before your agent signs it.

x402 is the HTTP-native payment protocol: a paid endpoint answers 402 with signed-terms-to-be (token, amount, recipient), your agent’s wallet signs a gasless USDC authorization, and a facilitator settles it on-chain — irreversibly. Chance sits in the gap between receiving the terms and signing them: submit the terms as an intent check, get an ALLOW / BLOCK / ESCALATE verdict with a proof, and only sign on ALLOW.

This is a verdict-only integration: Chance never holds keys, never signs, never settles. It answers one question — is this specific payment what your mandate authorizes? — and backs it with independently gathered evidence.

Prefer to click? The dashboard’s x402 Verifier lets you paste any x402 payment (or try built-in good/attack examples), watch each check run, and get the same signed verdict — no code required.

What gets recognized

Family	Payloads
payment	A decoded v2 PaymentRequired ({ x402Version, accepts: [...], resource } — what the PAYMENT-REQUIRED header contains)
payment	A single PaymentRequirements entry ({ scheme, network, asset, amount, payTo, ... })
payment	An already-signed PaymentPayload (flagged: the safe order is verify first, sign on ALLOW)

v1 shapes (maxAmountRequired) are tolerated and noted. Payloads are auto-detected — venue: "x402" is optional but recommended.

What the harness checks for you

Beyond the judge reading the terms against your mandate, the classifier gathers independent evidence before the verdict:

• Amount integrity — the seller dictates the asset contract. The dollar reading of amount is only trusted when that address is canonical USDC on that network; anything else is summarized as raw units of an unrecognized token (the vendor’s “$5” framing might be 5 WETH).
• Live terms re-fetch — the harness fetches the resource URL itself and diffs the live 402 against what your agent was quoted. Stale, tampered, or bait-and-switch terms surface as a PRICE MISMATCH.
• Vendor reputation (Coinbase Bazaar) — is the payTo a catalogued service that has settled real payments through the CDP facilitator, how many unique payers used it in the last 30 days, and when it was last active.
• On-chain payee profile — contract vs plain address, current USDC balance (a fresh drain address holds ~0; an established vendor accumulates).
• Payer preflight (signed payloads) — sufficient balance, and whether the payer wallet can settle at all.

An example judge summary:

X402 PAYMENT REQUEST: $5.00 USDC on Base (eip155:8453) to 0xF990…DcA5 — exact scheme, for resource https://mail.example.com/api/search independent terms check: live 402 re-fetched just now — terms match the quoted payment exactly ($5.00 USDC) vendor reputation (Coinbase Bazaar): listed as “Agent Email” — 881 paid calls from 873 unique payers in the last 30 days (last paid 2026-07-08)

Use it from your bot

Probe the paid endpoint, verify the decoded terms with Chance, sign only on ALLOW:

import { decodePaymentRequiredHeader } from "@x402/core/http";

const probe = await fetch(paidUrl); // unpaid: stops at the paywall, no side effects
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, $10/day total, " +
        "USDC on Base only, established vendors only.",
      action: terms, // the decoded PaymentRequired object, verbatim
      venue: "x402",
    }),
  }).then((r) => r.json());

  if (check.verdict === "ALLOW") {
    const res = await fetchWithPay(paidUrl); // your stock x402 client signs & retries
  } else {
    // BLOCK/ESCALATE: do not sign — check.reasoning says why
  }
}

Or with curl — this example uses the live terms of Chance’s own credit top-up endpoint, so the independent terms re-fetch verifies against a real 402:

curl -X POST https://harness.chance.cc/api/v1/intent \
  -H "x-api-key: $CHANCE_API_KEY" -H "content-type: application/json" \
  -d '{
    "intent": "May top up verification credits, at most $5 at a time, USDC on Base only.",
    "venue": "x402",
    "action": {
      "x402Version": 2,
      "resource": { "url": "https://harness.chance.cc/api/v1/credits/topup?credits=20" },
      "accepts": [{
        "scheme": "exact",
        "network": "eip155:8453",
        "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
        "amount": "1000000",
        "payTo": "0xAB97E6bCa125ef850bB37CB75C6938F5297da7d5",
        "maxTimeoutSeconds": 300,
        "extra": { "name": "USD Coin", "version": "2" }
      }]
    }
  }'

One credit per verification, verdict returned synchronously with the signed proof receipt — see the API reference.

Use it from Claude or ChatGPT

With the Chance connector installed, ask the model to check the payment before paying: it calls verify_intent with venue: "x402" and the decoded terms as the action. The chance-mcp stdio server exposes the same tool locally.

How the harness knows x402

The venue ships a versioned knowledge snapshot (protocol mechanics, payment scam patterns, a guide to the enrichment evidence) whose hash is pinned in every proof transcript, plus the live enrichment described above. Sources: the x402 v2 specification, the Coinbase CDP facilitator documentation, and behaviors verified against the live facilitator and Bazaar discovery API (July 2026).