DEV Community: Mark Zhurbin

Charge per API call in USDC — and give buyers a receipt they can verify

Mark Zhurbin — Mon, 29 Jun 2026 20:23:54 +0000

AI agents can now pay for things on their own. The x402 protocol reuses HTTP 402 Payment Required so a client — human or agent — pays per API call in USDC, no API keys, no accounts, no subscription. It's a genuinely nice primitive.

But there's a gap that bites the moment an agent acts on what it paid for: the payment rail proves the money moved. It says nothing about the bytes that came back. An agent can pay perfectly and still act on tampered or spoofed data.

So here's what I wired up, and how you can too: an Express endpoint that charges per call in USDC and hands the buyer a signed receipt they can verify before acting on the response. The packages underneath are free and MIT — this is just the assembly, shown plainly.

What we're building

client ──GET /price──▶  402 Payment Required  (USDC terms)
client ──pay USDC───▶  200 OK + your data + an X-BYTE-Attestation receipt
client ──verify────▶  recompute hash, recover signer → act or refuse

Two small libraries do the work:

@foreseal/gate — seller-side Express middleware. Turns any upstream into a paid, attested endpoint.
@payperbyte/sdk — buyer-side verifier.

Both MIT. You can absolutely wire them yourself; that's the point of this post.

Part 1 — the seller, in one middleware call

import express from "express";
import { trustMiddleware } from "@foreseal/gate";

const app = express();
app.use(express.json());

app.use(
  "/price",
  trustMiddleware({
    upstream: "https://your-api.example.com/data", // your real endpoint
    price: { perCallUsdc: "0.01" },                // or { perKBUsdc, floorUsdc }
    payTo: "0xYourUSDCAddressOnBase",              // where USDC settles
    attestation: "delivery",                        // stamp every paid 200
  }),
);

app.listen(3000);

That's the whole integration. An unpaid call gets a 402 with x402 USDC terms. On payment, the gate proxies your upstream and stamps the response with an EIP-712 attestation over the exact bytes it served — byte for byte — in an X-BYTE-Attestation header.

Part 2 — what the buyer sees

curl -i http://localhost:3000/price
# HTTP/1.1 402 Payment Required
# ... x402 payment terms (asset, amount, network, payTo) ...

The client pays in USDC, retries with the payment header, and gets 200 plus the data and the receipt. Standard x402 flow — the gate just adds the receipt.

Part 3 — verify before acting (the part that matters)

This is the half everyone skips. Before your code (or your agent) acts on the response, recompute the hash of the exact bytes and recover the signer. If either is wrong, refuse.

import { verifyFromGatewayResponse, ARBITRUM_SEPOLIA } from "@payperbyte/sdk";

const res    = await fetch(url, { headers: paymentHeaders }); // your paid call
const body   = await res.text();                              // the EXACT bytes
const header = res.headers.get("x-byte-attestation");

const v = await verifyFromGatewayResponse(
  body, header, ARBITRUM_SEPOLIA, gatewayAttester, // pin the seller's attester
);
if (!v.verified) throw new Error("refuse: " + v.reason);
// ...safe to act on `body`.

You can prove the mechanic offline, no wallet and no network — sign a sample receipt, then verify it and two attacks:

verify-before-act:
  genuine        → verified=true    received bytes match the attested hash AND signer — safe to act
  tampered byte  → verified=false   HASH MISMATCH — do not act
  forged signer  → verified=false   bad recover — do not act

Accept genuine. Refuse tampered and forged. That's the gate.

The honest part: provenance, not truth

This is important enough to say out loud, because plenty of "verified data" pitches blur it:

The receipt proves the bytes are authentic and unaltered, signed by the attester you pinned. Tamper-evident, signer-pinned, recomputable.
It does not prove the data is correct. A genuine receipt over a wrong number still verifies — authentic bytes, garbage value.

So the claim is narrow and useful: "these are genuinely the bytes the seller signed," not "this number is right." You still decide whether to trust the seller. The receipt just removes the question of whether you got their actual bytes. Tell your own users which one you mean.

The one gotcha that trips everyone

The EIP-712 signing domain is anchored at chainId 421614 (Arbitrum Sepolia) — a frozen signing namespace for signature recovery. It is not a settlement chain. Payments settle in USDC on Base mainnet. So you pass ARBITRUM_SEPOLIA to the verifier even though the money moved on Base. Recovery happens in the domain; settlement happens on the rail. Mix them up and your signatures won't recover — budget five minutes of confusion here, then never again.

Testnet today, mainnet when you're ready

Default to base-sepolia: the public x402 facilitator advertises testnet, so the full 402 → pay → 200 → receipt loop works for free with testnet USDC, no keys. (On Base mainnet without a mainnet facilitator the paid route correctly fails closed.)

For real USDC on Base mainnet, point at the Coinbase CDP facilitator:

NETWORK=base
FACILITATOR_AUTH=cdp
CDP_API_KEY_ID=...
CDP_API_KEY_SECRET=...
# and: npm i @coinbase/x402

I ran this end-to-end on Base mainnet — the 402 advertises network: eip155:8453, the canonical Base USDC asset, and your payTo. Develop on testnet, flip one env block for mainnet. That's the only change.

Try it in one second

No install, no wallet — see the whole accept-genuine / refuse-tampered loop locally:

npx @foreseal/demo

It runs offline and shows an agent act on genuine bytes and refuse a tampered byte, a forged signature, a missing receipt, and a forked signing domain — in about a second.

Take it further

Building an AI agent that should buy data over MCP? byte-mcp-server (MIT) gives Claude Desktop / Claude Code / Cursor a buy → verify-before-act tool out of the box.
Want the wired-up, deploy-ready versions instead of assembling it yourself? I packaged two starter kits — an x402 + verify-before-act Express kit and an MCP agent kit (server + examples + deploy/integrate guides), $39 each. The libraries above stay free MIT; the kits are the afternoon you'd otherwise spend wiring them.

Either way: if your code acts on data it paid for, verify it first. Provenance is cheap. Acting on tampered bytes isn't.

Questions or corrections welcome in the comments — I'd rather fix something than leave it wrong.

Verify before your agent acts: a trust check for x402 data feeds (in one npm install)

Mark Zhurbin — Tue, 23 Jun 2026 18:05:35 +0000

Your agent paid for the data. That doesn't mean the bytes are real.

Autonomous agents are starting to pay for data — per call, in stablecoins, over x402. That solves billing. It doesn't solve trust. A 200 OK from a paid endpoint tells you the money moved. It tells you nothing about whether the bytes you got back are the bytes the publisher actually signed — or whether a proxy, a cache, or a man-in-the-middle rewrote them on the way to your agent.

If your agent is about to act on that data — release funds, open a position, file a report, trigger a workflow — "I paid for it" is not the bar. "I can prove it's intact and I know who stands behind it" is.

This is a 5-minute walkthrough of doing that check before your agent acts, using an open MIT kit. No token, no signup, no API key.

See it first — one command, no wallet

npx @foreseal/demo

This runs entirely offline. It walks an agent through a handful of payloads — a genuine signed one, a byte-tampered one, a forged-key one, one with the receipt stripped off, one with the domain rewritten — and prints ACT or REFUSE for each. The point: a verifier that fails closed. Tampered, forged, or missing-receipt → the agent refuses. No real money is involved; it's the mechanism, distilled.

How the receipt works

Every paid response from the PayPerByte gateway carries an
X-BYTE-Attestation header: an EIP-712 PayloadAttestation.
The recipe is published, machine-readable, at /.well-known/agent.json:

keccak256(responseBody) === payloadHash AND recoverTypedDataAddress(domain, {PayloadAttestation}, message, signature) === attester

Two legs. The hash leg proves the bytes weren't altered. The signer leg proves the receipt was
issued by the key you expect — not self-asserted by whoever sent the response. You check both, locally,
before acting. (One deliberate detail that looks like a bug but isn't: payments settle in USDC on Base, but the attestation's EIP-712 domain is anchored on Arbitrum, chainId 421614. Settlement rail and trust anchor are intentionally separate.)

Wire it into your agent

npm i @payperbyte/sdk@^0.1.2

Version matters: the full hash and signer check (verify / verifyAttestation /
verifyFromGatewayResponse) ships in 0.1.2+. Earlier 0.1.0/0.1.1 only export the hash-only
verifyPayload. Pin ^0.1.2.

The one-call path, for a response you just fetched from the gateway:

import { verifyFromGatewayResponse, ARBITRUM_SEPOLIA } from '@payperbyte/sdk';

// Pin this once from https://x402.payperbyte.io/.well-known/agent.json → receipt.attester
const GATEWAY_ATTESTER = '0x77c86a5367d941091a31BC97104609F2Db33C472';

async function getVerifiedData(url: string, res: Response): Promise<Uint8Array> {
  const body = new Uint8Array(await res.arrayBuffer()); 
  const header = res.headers.get('X-BYTE-Attestation');

const verdict = await verifyFromGatewayResponse(
    body,
    header,
    ARBITRUM_SEPOLIA,        // the attestation domain's chain (421614)
    GATEWAY_ATTESTER,        // pin it — a self-asserted header can't prove itself
  );

  if (!verdict.verified) {
    // fail-closed: tampered, forged, expired-key, or no receipt at all
    throw new Error(`refusing to act on ${url}: ${verdict.reason}`);
  }
  return body; // safe to act on
}

That GATEWAY_ATTESTER argument is not optional ceremony. If you don't pin the attester, the kit
fails closed on purpose — because the publisher field inside an attestation header is attacker- controlled, so trusting it would let a forged response self-certify. Pin the address from the published recipe; then a forged header has nothing to stand on.

The Verdict you get back is explicit, so your logs tell you why something was refused:

interface Verdict {
  verified: boolean;       // hashMatch && signerMatch === true — the one "safe to act?" bool
  hashMatch: boolean;      // bytes weren't altered
  signerMatch: boolean | null; // null = no attestation present → fail-closed (never "pass on hash alone")
  recovered: string | null;    // the address the signature actually recovers to
  expired: boolean;        // ADVISORY ONLY — staleness is a freshness axis, not a provenance verdict
  reason: string;          // human-readable, for post-mortems
}

Note expired does not flip verified to false. A once-minted now+300s deadline makes every aged feed look "expired"; that's a freshness question for your own policy, not a tamper verdict. Surface it, decide for yourself.

If you're working from the lower-level pieces (raw bytes + the attested fields, or an on-chain event
rather than a gateway header), verify(input) takes the explicit struct, and verifyPayload does the hash-only leg on its own. Same fail-closed contract: it throws nothing and always returns a Verdict.

Bonus: verify the counterparty, not just the payload

The same EIP-712 receipt pattern backs a live $0.05 counterparty screen — a signed go/no-go on an address+domain before your agent releases funds. It's a paid feed; the verdict comes back as a signed ALLOW/WARN/BLOCK you verify the same way:

curl -i -X POST https://x402.payperbyte.io/feeds/address-reputation \
  -H 'content-type: application/json' \
  -d '{"domain":"payee-checkout-7x9q.example","address":"0xRecipient","amount":5000000,"chain":"base"}'

(With no payment header you get the HTTP 402 challenge back — that's the handshake, not an error. This is a counterparty screen — "is it safe to send here?" — not a seller-reputation score.)

Where this is honest about itself

This is early. It's dogfooded end-to-end; the only mainnet settlements so far are our own self-tests, and external adoption is exactly the open question we're publishing this to answer. What it does prove is narrow and real: authenticity and tamper-evidence, not correctness — your agent learns "these are exactly the bytes that were signed, by the key I expected," not "this data is true." It's MIT, USDC-only, no token, no new contracts to deploy. The verifier is the whole pitch: a small amount of code, hardened to fail closed, that you run before your agent acts.

Demo: npx @foreseal/demo
Kit: npm i @payperbyte/sdk@^0.1.2 · Gate (for publishers): @foreseal/gate
Recipe: https://x402.payperbyte.io/.well-known/agent.json
MCP server (drive it from Claude/Cursor): npx -y byte-mcp-server

Disclosure: I build PayPerByte (machine name "BYTE Library").