DEV Community: John O'Malley Jr

A settlement is a claim, not a fact — so I verify every x402 payment

John O'Malley Jr — Tue, 20 Oct 2026 17:19:13 +0000

In my last post I put an MCP server behind HTTP 402 and showed a real $0.005 USDC settlement on Base. A reader could click the BaseScan link and check that one transaction by hand. That works for one payment. It does not work for a business.

If you're an API owner thinking about charging agents per call, here's the question that should bother you: when your dashboard says "paid," what actually proved it? A settlement notification is a claim — someone says a payment happened. Claims can be wrong, early, replayed, or mismatched. I didn't want my demo, let alone a client's endpoint, running on claims. So I wired in an independent verifier.

The verifier

Flow Executor built a settlement verifier for x402 on Base and made it free: POST https://flow-kg4x.vercel.app/api/settlement-verify. Send it a signed EIP-3009 authorization, optionally with the settlement transaction hash, and it runs four checks:

Signature recovery — the signature actually recovers to the payer who supposedly authorized the payment.
Nonce consumption — USDC.authorizationState shows the authorization's nonce was actually consumed on-chain. EIP-3009 authorizations are single-use; an unconsumed nonce means the payment hasn't settled, whatever anyone says.
Transfer match — the settlement transaction's USDC Transfer log matches the authorization's payer, payee, and amount.
Validity window — the settled block sits inside the authorization's validity window.

Without a tx hash, checks 3–4 are skipped and the verdict rests on signature + consumed nonce. Base only, for now.

How I wired it into the demo

Every new settlement on https://demo.quinnsconveyance.com now auto-verifies, and the result is stored in Postgres next to the payment:

verify_status: verified, failed, unverified_verifier_down, or unverified_error (default unverified)
the existing verified boolean, plus verify_detail with what the checks actually returned

One design rule matters more than the rest: verification never blocks a settlement. If the verifier is down, the payment lands anyway — but it's recorded as unverified_verifier_down, permanently, not silently passed. Fail-open, but loud.

That wording is deliberate. My first version just skipped verification when the endpoint was unreachable, which sounds reasonable until you say it out loud: the moment the checker fails is exactly the moment unchecked payments sail through with no trace. A status column fixes that. "Unverified" is honest. Silence isn't.

The first thing it caught was my own pipeline

Within the first batch of settlements, statuses came back failed and unverified where I expected verified. The cause was a timing race: my integration fired verification at settlement time, before the chain state had propagated, so the nonce check ran against a chain that hadn't caught up yet. Re-checks pass — the payments are real — but at verification time, they didn't verify.

I'm publishing that instead of quietly fixing it because it's the whole argument for doing this:

If I hadn't stored a status per settlement, I'd never have seen the race. The settlements "worked." The money moved. The gap would have stayed invisible.
Verification isn't a one-shot at settlement time. It needs a re-check pass after chain state settles. That's now on my list, in the open.
Any volume number reported without a verification column is counting claims. That includes, today, some of mine — which is the point of the column.

Should verify_status be a standard?

Flow Executor has proposed exactly that: every settlement carries a status — verified / failed / unverified — "no status, no trust." I support the convention. I'm cautious about directories and facilitators requiring it before a payment counts: a hard mandate makes the verifier a gatekeeper and a single point of failure for the whole ecosystem. Fail-open-but-loud gets you the trust signal without the chokepoint. Statuses, yes. Permission, no.

Try it / steal it

The verifier is free and live — the endpoint above returns usage docs on a GET. The demo is live with settlements you can inspect: https://demo.quinnsconveyance.com

And if you're an API business whose endpoints are being hit by agents for free: this verification layer is part of what I install on every Quinn's Conveyance deployment, alongside the settlement logging and the challenge→settlement funnel. One endpoint behind 402, live in under a week, $500 flat — waived with an Operate plan. john@quinnsconveyance.com

— John O'Malley, Quinn's Conveyance

How We'll Measure the Agent Economy

John O'Malley Jr — Tue, 20 Oct 2026 14:30:25 +0000

The x402 ecosystem has a counting problem.

By Q3 2026 there were 138 million cumulative x402 transactions on Base, and 87% of them were under $0.10. Depending on who you ask, that's either the birth of the agent economy or the world's most efficient wash-trading machine. TRM Labs estimates only 0.6–7.5% of x402 value is genuinely agentic. The honest answer: nobody knows, because almost everyone is counting the wrong thing.

Transactions are easy to count. Commerce is not. A settlement on-chain tells you a wallet paid. It doesn't tell you whether an agent needed something, got a price, decided to pay, and received value — or whether a script is farming volume in a loop.

We run x402 implementations for API businesses. Here's the measurement stack we install on every deployment, and what each layer actually proves.

1. The funnel, not the total

Every paid endpoint serves far more 402 challenges than settlements. That ratio is the business:

Challenges served — an agent (or a bot, or a curious human with curl) hit the price wall.
Settlements — a wallet signed and paid.
Conversion rate — settlements ÷ challenges. This is the single most honest number in agent commerce. A healthy paid endpoint converts a meaningful fraction of its challenges. A wash-traded one converts ~100% of challenges from a handful of wallets, instantly, around the clock.

If someone shows you settlement volume without the challenge count behind it, they're showing you the numerator and hiding the denominator.

2. Wallet persistence

Agents that do real work come back. We track payer wallets over time: first seen, calls per wallet, repeat rate. Real demand has a long tail of wallets with human-shaped usage patterns — bursts during work hours, topic drift, price sensitivity. Manufactured volume has a short head of wallets with metronome timing.

Wallet identity is also what makes agent commerce different from the API-key era: the payer is pseudonymous but persistent, so reputation can accumulate without an account ever being created.

3. Latency and failure shape

We record challenge-to-settlement time on every call. Real agent clients take measurable time to evaluate a price and sign (our own test client: ~1.2 seconds). Sub-100ms challenge-to-settlement at scale is a signature worth investigating, not celebrating.

Failures matter too: expired authorizations, insufficient funds, signature mismatches. A deployment with zero failures isn't well-run — it's not being used by anyone new.

4. Verification status on every settlement

A settlement is a claim. We verify each one independently — signature recovery, on-chain nonce consumption, transfer-log match against the authorization, block timing — and store a status next to every payment: verified, failed, or unverified (with the reason). Fail-open, but loud: if the verifier is down, the payment still lands, but it's marked unverified forever. Directories and facilitators that report volume without a verification column are reporting claims, not facts.

What we'll publish, and when

When our deployments have enough real traffic, we'll publish the aggregate numbers: conversion rates, repeat-wallet share, median settlement latency, verification outcomes — per category, never per client, and never the underlying customer data. That data belongs to the businesses that earned it; we sell implementation and operations, not our customers' information.

Until the volume is real, we'd rather publish the ruler than a fake measurement.

— John O'Malley, Quinn's Conveyance
We put APIs behind HTTP 402 and keep them running: quinnsconveyance.com

I put an MCP server behind HTTP 402. Here's the exact setup.

John O'Malley Jr — Mon, 19 Oct 2026 02:24:08 +0000

AI agents are hitting APIs thousands of times a day and paying nothing. I wanted to know if the "pay per call" story is real or slideware, so I built the smallest possible version: my own knowledge base, sold per query, settled on-chain. It works. Here's everything, including the transaction.

What it is

Five MCP tools wrapping things I actually know — ComfyUI API-prompt fixes, node wiring recipes, verified dead ends (the kind of knowledge that only exists because I burned GPU hours finding out). Each tool costs $0.005 per call, paid in USDC on Base. Two more tools are free: ping, and list_topics so an agent can see what's for sale before spending anything. Discovery free, answers paid.

The stack (all stock, nothing custom)

@x402/mcp — Coinbase's x402 MCP package. The key primitive is createPaymentWrapper: you wrap each paid tool's handler and it handles the 402 challenge/response at the MCP protocol level. Paid tools and free tools live side by side.
@modelcontextprotocol/sdk — the standard MCP server, StreamableHTTP transport via Express (plain SSE stalls behind tunnels — learned the hard way).
Facilitator: PayAI's public facilitator for Base mainnet (no key needed on the free tier). Note: the x402.org facilitator is testnet-only despite what the docs imply — it errors on mainnet routes.
Chain: Base. Testnet (Sepolia) for iteration, mainnet for the proof below.

The whole server is ~120 lines. The payment wrapper is the product; everything else is plumbing.

The payment flow, measured

Agent calls a paid tool → server answers 402 with payment requirements ($0.005 USDC, my address, Base).
Agent signs an EIP-3009 authorization. The buyer pays zero gas — signing is free, no ETH needed. This is the property the whole design rests on.
Facilitator verifies the signature and submits the USDC transfer on-chain, paying the gas itself (~$0.001–0.05 on Base).
Server gets the settlement confirmation and returns the answer.

Measured end to end on testnet: https://sepolia.basescan.org/tx/0x5b0b2205606f13d7197a5c8d7556d413723d1ae84c9732eac1b3a4b1850fa2cb (success — $0.005 USDC moved). Then one real mainnet settlement: https://basescan.org/tx/0xb762d7856c03fc009b4743859850e075b997ea90d36a68681348e9634b0634f0 — $0.005 moved on Base, verifiable by anyone.

The gas math nobody puts in the pitch deck

At $0.005 per call, gas is not a footnote — it's the margin. If the facilitator pays $0.002 to settle your half-cent payment, 40% of revenue is gone before you start. Per-call micro-pricing only survives with batching or a facilitator that sponsors gas. Price accordingly, and read the facilitator's terms before you set prices. (This is also why "millions of micro-settlements with zero friction" is a fantasy unless someone is batching underneath you.)

What it costs to run

Server: a Google Cloud e2-micro free-tier VM (static IP, systemd service). CPU-only — no GPU involved.
Per sale: the facilitator's gas, ~fractions of a cent.
My time to build it: an afternoon, most of it reading the x402 repo's own examples.

What I actually think

The rail is real and the code is boring in the best way — that's the compliment. What's not real yet is the demand: nobody's agents are lining up to pay half a cent for answers. The people who will pay real money are businesses whose APIs are being scraped for free right now. That's who I'm building this for next.

If that's you — one endpoint behind 402, live in under a week, flat fee. Try the demo: https://demo.quinnsconveyance.com (/health is free, POST /mcp is the paid endpoint). Reach me at jkomalleyjr@gmail.com — more of my work at github.com/jkomalleyjr.