DEV Community: minia2a

The Most-Used Agent API in October 2026 Costs Two Cents

minia2a — Sun, 11 Oct 2026 18:14:23 +0000

The Most-Used Agent API in October 2026 Costs Two Cents

2026-10-11 · minia2a

Every few weeks someone publishes a transaction count for x402 and the number looks enormous — millions of payments, a quarter of a ledger's activity, "agentic commerce is here." Then you look at the dollar value and it is a rounding error.

A study presented at TOKEN2049 Singapore this month ("The State of AI Agent Payments 2026", BeInCrypto) did the useful thing and put the two numbers next to each other. Over a 35-day sample of x402 traffic on Base and Solana (late July–August 2026):

6.4M

x402 transactions — settling $119,947 in total, with 90.8% under one cent

And then the most interesting line in the whole report: the single most-requested paid resource was a token safety check — priced at two cents — called 63,319 times. Not an LLM inference call, not a data feed, not a trading signal. A cheap, deterministic, per-call safety check, bought over and over.

Why that one line matters more than the transaction count

It tells you where the demand actually is. Agents that hold or move tokens need to answer "is this contract safe to touch?" before they act. That question is: frequent, small, repetitive, machine-verifiable, and worth exactly a few cents per answer. That is the shape of a real M2M microtransaction — not a $40 model call, but thousands of $0.02 checks.

It also tells you the market is early, and honestly so. The same report flags concentration: on a single day, 145 addresses made 1,283,926 payments to just three recipients. The XRP Ledger picture is starker still — 13.4 million agentic x402 payments processed, with total settled value reported under $5,000. High counts, tiny value, few actors. Anyone selling "agent payments at scale" should be measured against that.

The economics the card networks can't reach

A Coinbase Institute paper published the same week ("Machine-to-machine payments in the AiFi era", Oct 7, 2026) makes the structural argument plainly: a flat card fee destroys sub-cent payment. A $0.30 interchange fee is a 30,000% overhead on a $0.001 API query. There is no tweak to the card rails that fixes that; you need a native rail where the fee is on-chain gas, approaching zero. The paper demonstrated a 0.01 USDC transaction on Base settling in about two seconds with network cost under $0.001, via x402 + EIP-3009.

That is the entire reason a two-cent check can be a business. The cost of moving two cents has to be less than two cents. On card rails it isn't; on a stablecoin rail it is.

The takeaway for API builders: price for the shape of agent demand, not for a human subscription. The most-purchased endpoint in the market today is a two-cent, no-account, per-call check. If your API can answer a small deterministic question, it is already the right product for this market.

Where minia2a sits on this

We run a pay-per-call market for x402 endpoints, so the demand-centre fact is directly testable against us. Our /x402/token-security endpoint is a token safety check, and it is priced at exactly the market's number — two cents:

$ curl -s https://minia2a.uk/x402/token-security | python3 -m json.tool
  accepts[0].amount    = 20000                                  # microUSDC = $0.02
  accepts[0].asset     = 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913  # USDC
  accepts[0].network   = eip155:8453                             # Base

No account, no API key — the endpoint answers a plain 402 Payment Required with the price, and a signed wallet gets five free trial calls before it pays anything. That is the full recipe for the demand the report measured: a machine that needs one small answer, one small payment, no human in the loop.

We are not going to pretend the volume is large. It isn't — for us or for anyone in this market yet. What is real is the direction: the paid resource agents actually buy is a cheap per-call safety check, and the settlement rail they actually use is Base. We serve both. The transaction graphs everywhere are flat because the market is young, not because the shape is wrong.

Try the two-cent check yourself.
Five free trial calls per signed wallet. No registration.

Sources: BeInCrypto, "The State of AI Agent Payments 2026" (launched TOKEN2049 Singapore, Oct 7–8, 2026); Coinbase Institute, "Machine-to-machine payments in the AiFi era" (Oct 7, 2026); XRP Ledger agentic-payment figures as reported by PrimeXBT / AInvest / tokenpost. The minia2a 402 figures above were read live from https://minia2a.uk/x402/token-security on 2026-10-11.

Originally published at minia2a.uk.

The Empty Example: a discovery layer that hands your agent a call it cannot make

minia2a — Wed, 07 Oct 2026 04:02:02 +0000

The Empty Example: a discovery layer that hands your agent a call it cannot make

October 7, 2026

When an x402 resource wants to be called, it advertises itself in a 402 response. For a machine caller the price is not the part that matters most — the part that matters is the input example: the shape of the body it is supposed to send. When that example is {"from": "", "to": "", "value": ""} — correct field names, empty values — the agent has everything it needs to construct a request, and no reason to suspect the request will be rejected. It copies the example. It sends it. It gets a 400.

This is a trap we spent a week of paid-call rejections discovering on our own endpoints, and it is worth writing down because its shape is subtle: an empty template does not look broken, and a crawler has no way to tell it from a real one.

Where the example comes from

A discovery layer — a bazaar index, a /.well-known/ manifest, a registry — reads the metadata a resource publishes about its own inputs. In the x402 bazaar extension that field is extensions.bazaar.info.input.body: a sample request body the caller (and the crawler that indexes the seller) is meant to read.

The producer almost never hand-writes these. It builds them through a fallback chain: a curated map first, then a machine-generated map of examples that were actually exercised, and — when neither has an entry — a schema-derived fallback. It is the last branch that hurts. With nothing else to go on, it emits one key per declared field, each with an empty string value.

{
  "from": "",
  "to": "",
  "value": ""
}

Every name is correct. Every value is a blank. The shape is valid JSON, the fields are the real fields, and the example will be rejected by the handler's own validators — from required, value required.

Why `{field:""}` is worse than `{}`

The two payloads are a few bytes apart and mean opposite things:

Example body	What it tells an agent	What happens
{}	This resource takes no input.	Agent sends nothing, call succeeds.
{"a": "", "b": ""}	This resource takes fields `a` and `b`.	Agent fills or copies them, handler validates, call fails.

A consumer cannot tell a template from an example. Both are objects with keys; only one is safe to send. This is the same failure class as a 200 response whose body says ok:false: the outer layer reports health and the inner layer reports the opposite, so the honest signal is the one the reader was told to ignore.

Of the two ways to advertise "no required input", only one is reachable by accident. An empty map is a deliberate statement. A blank template is what a generator writes when it has nothing to say — and it looks like a promise.

What it cost us

We measured rejections on our own paid endpoints. In the window ending 2026-09-19, 16 of 69 paid calls were rejected. In the window ending 2026-09-28, 32 of 90. The rejection messages were the handlers' own validators — text required, domain required, expr required — failing on bodies that followed the published example. Roughly a third of paid attempts in that period failed on input shape, not on payment, and the caller had done exactly what the discovery layer told it to do.

That is the cost of the trap in the only unit that matters: a payment-ready agent was turned away, and nothing in the response pointed at the example as the cause.

The rule we adopted

Never publish a blank template as an example. If a resource takes no input, publish {} — never {"a": ""}. The two must not be produced by the same code path, because they are not the same statement.
An example is only an example if it ran. Our generator's acceptance test is to send the candidate body through the real handler and require ok:true with non-empty content. A body that parses is not a body that works.
Curate from the handler's own valid-value domain. The unit m2 is in the handler's conversion table; sqm is a plausible-looking synonym that is not. The whole difference between an example and a 400 is that the value came from the code that validates it.
Re-generation must not be destructive. An upstream that is transiently unreachable is not evidence that a service's example is wrong. Drop it and the trap re-opens for the callers that endpoint already had.

How to check your own discovery layer

List every resource whose published example is non-empty but whose values are all empty strings. That is the trap population, and it is counted separately from the {} resources — only the second set is a defect.
Run each example body against the live handler. A good example returns 2xx with content; anything else means the example is a liability, not documentation.
Check the generator, not just the data. If the fallback branch is reachable, the trap re-appears for every new service that does not get a curated entry.
Watch the rejection rate on paid calls and read the reasons. A rejection that names a required field is the discovery layer talking, not the caller.

What we are and are not claiming

These are our numbers, on our endpoints. We did not survey other x402 producers and do not know how common the empty-template fallback is elsewhere. The rejection counts above are ours and measured.
Fixing it is per-service data, not a switch. The fallback is convenient because it generalizes; the only way to retire an endpoint out of it is to give that endpoint a real, exercised example. That is why it is a rolling cleanup rather than a one-line change.
The lesson generalizes past x402. Any registry that publishes example payloads — OpenAPI example blocks, GraphQL playground defaults, an MCP tool's sample arguments — can ship a blank template where it means to say "no input". The test is the same in every one: does the published example actually run?

The rejection counts (16/69 and 32/90 paid calls) are read from our own delivery records on the dates shown; the valid-value-domain example (m2 vs sqm) is from the handler's own unit table. No figure here is estimated and none is drawn from a third party.

← More posts · minia2a.uk

Originally published at minia2a.uk.

What an x402 Rail Announcement Actually Certifies

minia2a — Mon, 05 Oct 2026 12:50:26 +0000

Three x402 announcements landed inside two weeks: a chain joined the official SDK, a network crossed a ten-million-payment milestone, and a major CDN opened a beta that puts a 402 paywall in front of any domain. Each one is real. None of them, by itself, tells you whether you can get paid on that rail today — because each is certifying a different thing, at a different stage of the same journey.

We are a marketplace, not a rail, so we read these announcements the way a buyer does: not "is this good news for x402?" but "if I build on this, does a settlement actually clear?" That question has five separable parts, and a press release usually answers only the first.

Three announcements, three different claims

The chain that joined the SDK

A major proof-of-stake chain joined the official x402 standard SDK in September, with an installable package (@x402/cardano), TypeScript first and Python planned. The specification had merged in June; the implementation commit landed about twelve days before the public announcement. The facilitator passed 166 unit tests and processed a real end-to-end transaction — on a pre-production network. As of the announcement it had not settled on mainnet.

That is not a knock on the work — shipping a facilitator that passes a real transaction on a testnet is exactly the right first step. It is a statement about what the announcement certifies: the code is joined, not the money is flowing.

The network that crossed a milestone

A payments facilitator reported that one network crossed ten million x402 transactions (and, in a conference talk two days later, eleven million), driven by AI agents buying compute and data. The same reporting is careful about what the number is: it is that facilitator's counter, not the network's, and it measures messages, not settled value, not distinct buyers, not unique sellers. Separately, the protocol's originator has reported over a hundred million x402 payments across its two home chains — a different counter again.

Payment counts are the easiest x402 metric to produce and the hardest to interpret. A hundred million agent-signed messages and a hundred million settled, distinct-buyer purchases look identical in a headline.

The CDN that put a paywall on every domain

A major CDN opened a closed beta of a monetization gateway that lets a domain owner charge agents per request. It uses HTTP 402 and x402 authorization, and it settles USDC on Base — the same chain and asset our marketplace settles in. Because it is a beta, it is gated: U.S.-based sellers only, a credit card on file, an account older than 60 days, a proxied zone older than 30 days, and requests priced from $0.001 to $100.

This is the announcement with the most immediate substance — a real gateway, real early sellers, real settlement — and the one with the most caveats attached: geography, account age, and a per-request price ceiling that does not fit every catalog entry.

The five questions a rail announcement does not answer

1. Merged, or deployed? An SDK package existing is not an implementation serving traffic. Ask: does the package install, is it versioned, and who is running it in production?

2. Testnet, or mainnet? A facilitator that settles on a testnet has proven the code path. Ask the one question that separates the two: has a real mainnet transaction settled, and can I see it?

3. Whose counter is the headline number? "Ten million payments" is almost always one operator's view. Ask what it counts — messages or value, all buyers or one, all sellers or one.

4. What gates apply to me? Geography, account age, KYC, a funding instrument, a price ceiling. These decide whether a rail exists for your address, independent of how good it is.

5. Does the resource accept it? The rail being live somewhere does not mean the endpoint you want to pay accepts it. That is decided at payment time, and only one artifact decides it: the 402.

The only claim that binds at payment time is the challenge

Every other layer — press release, SDK, facilitator, gateway — is upstream of the one document that actually constrains a payment: the 402 challenge the resource returns when an unpaid caller asks for it. That document lists the rails the resource will settle on, and if the rail you read about is not in it, no amount of "x402 support" elsewhere will help you pay.

You can read it without paying anything. Request the resource, and decode the payment terms:

# an unpaid request returns the machine-readable terms
curl -sDi https://minia2a.uk/x402/time | tr -d '\r' | grep -i '^PAYMENT-REQUIRED'

# base64-decode the header and read accepts[]:
#   scheme             exact | upto
#   network            eip155:8453        <-- the rail that will settle
#   asset              the token address
#   payTo              where value lands
#   maxAmountRequired  the price
#   extra              EIP-712 domain the wallet signs against

That network field is the ground truth. A rail is "supported" for you on a given endpoint if and only if it appears in that endpoint's accepts[]. Everything above it — the SDK you installed, the milestone you read, the gateway in beta — is a claim about the ecosystem, not a promise about this resource.

A buyer's shortcut: before trusting any rail claim, read one 402 from the endpoint you actually intend to call. If you want to read more than one, most x402 catalogs offer a free trial allowance so you can enumerate challenges without spending — on our own we allow five signed trial calls per wallet, no registration.

Where this leaves a marketplace

Our honest position, stated the same way we would want a rail operator to state theirs: minia2a settles USDC on Base only today. We list more than a thousand endpoints, and every one of them declares that single rail in its accepts[]. When a second rail is genuinely live on mainnet — not merged, not testnet, not one operator's counter, but settling through a facilitator we can actually reach — we will add it and say so, and the 402 is where you will be able to verify it rather than take our word.

An SDK merge, a milestone, and a gateway beta are three real and encouraging steps for the protocol. But "a rail exists in the ecosystem" and "I can pay this endpoint on it" are different sentences, and the distance between them is exactly the checklist above. Read the challenge; it is the only part of the stack that cannot overstate itself.

Sources for the three announcements: the Cardano Foundation's SDK-integration announcement (September 21, 2026; package @x402/cardano; testnet-only settlement at announcement) as reported by CoinDesk and CoinMarketCap community coverage; XRP Ledger payment-count figures as reported by t54 at XRP Seoul 2026 (October 3, 2026) with the same reporting noting the counts are facilitator-scoped; and the Cloudflare Monetization Gateway closed-beta coverage (September 30–October 1, 2026) via Search Engine Journal. Protocol-originator aggregate figures are as publicly reported.
minia2a publishes its own live numbers at /api/stats; the settlement-chain claim above is enforced in our own guard corpus against those numbers.

Originally published at minia2a.uk.

The 429 Your Agent Client Can't Read: designing rate limits for machine callers

minia2a — Mon, 05 Oct 2026 03:55:30 +0000

The 429 Your Agent Client Can't Read

A rate-limit response has two readers: a human debugging it in a terminal, and a retry loop parsing it in a program. Most APIs write it for the first reader and forget the second — and the second is the one that decides whether the next second brings one request or ten thousand.

The one field a retry loop actually reads

When a service answers 429 Too Many Requests, the mechanism the caller is supposed to use to back off is the Retry-After header. It is in the HTTP spec for exactly this (RFC 9110 §10.2.3), and the retry machinery in common clients already honors it without the application doing anything: Python's urllib3 and requests Retry classes respect it by default, and every serious HTTP gateway and service mesh has a knob for it.

What none of that machinery does is parse your JSON body. A generic client does not know that your error document carries a field named retryAfter, or retry_after, or retryAfterSeconds — you invented the name, and only clients that read your docs will ever look inside. So a retry hint that exists only in the body is addressed to a reader that, in practice, is not there.

The asymmetry in one line: a header is read by default; a body field is read only if the caller already knows its name. Putting your retry hint in the body is not wrong — it is optional to the one reader that acts on it.

What we found in our own API

We went looking at this because of a monitoring bug, not a client one. While reviewing why one of our own internal checks had gone quiet on a large sweep, we read our rate-limit response at the source. The anonymous gate on our catalog routes answers:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json

{"error":"rate limit exceeded","retryAfter":60}

That is retryAfter — a body field, in seconds. There is no Retry-After header on the response. A caller that reads the JSON and knows our field name backs off exactly right; a caller using stock retry middleware sees a bare 429 with no timing and does whatever its default is, which is often "retry immediately, then again."

We also noticed a second, quieter inconsistency: we do send a Retry-After header on our database-unavailable path, and the two responses are otherwise similar enough that an integrator would reasonably assume the same shape applies to both. One carries the standard signal, the other carries a private one.

We found this while reading our own source, which is the cheap way. The expensive way to find it is to watch an agent client quietly turn a soft limit into a hard one.

Why it costs you, not just your caller

The bill for an unreadable retry hint comes back to the server. A client that cannot tell "wait 60 seconds" from "wait forever" usually picks one of two bad defaults: retry tightly until something changes, or give up and never come back. The first is a self-inflicted flood — the exact traffic your limiter exists to stop — and it inflates your own 429 counters until they stop distinguishing a real abuser from an ordinary client that simply could not read you. The second loses you the client silently.

There is a second-order cost, too. When your monitoring and your product share an origin, a rate limit is also a fact your own checks have to interpret correctly. A sweep that hammers its own edge until it is throttled learns nothing about the endpoints and something misleading about the response codes — a 429 read as a defect is a phantom failure, and a 429 read as "no data" is a false all-clear. We have hit both shapes. The fix on the client side is to treat a throttle as a distinct outcome from a defect; the fix on the server side is to make the throttle impossible to misread.

A short checklist for agent-facing APIs

Send Retry-After. It is one line, it is in the spec, and every retry library honors it. Body fields are for humans and for callers who read your docs; the header is for the caller who did not.
If you also put the hint in the body, match the header. Two sources of the same number that can disagree is worse than one. If they can only ever be equal, say so in the docs and in a test.
Do not let 429 mean several different things. "Slow down," "you already registered," and "daily quota spent" are three different actions — back off, stop, come back tomorrow. If they share a status code, distinguish them in a field and in your docs, and keep the machine-readable one stable.
Say what the limit is scoped to. Per IP, per wallet, per key, per route group — the caller cannot infer it, and guessing wrong is how a correctly-written client still gets throttled by a limit it never read.
Do not page on 429. It is a request for patience, not an outage. A monitor that treats it as a failure will lie to you the first time your own traffic is healthy but fast.

None of this is exotic. It is the difference between a limit that shapes traffic and a limit that a client simply cannot see.

We operate an x402 pay-per-call API marketplace and hit our own edge with the same clients agents do. The 429 shape quoted above is read from the deployed gateway source, not from memory. No numbers in this post are invented; where we describe our own behavior, it is the behavior of the running service.

Originally published at minia2a.uk.

What Happens When Academics Stress-Test 15 x402 Payment Gateways: An Operator's Security Audit

minia2a — Sun, 04 Oct 2026 22:00:53 +0000

Last week, researchers from EPFL, Zhejiang University, and USENIX Security 2026 dropped a paper that should make every x402 operator stop and audit their code: 31 security vulnerabilities across 15 facilitators, covering 99% of x402 transaction volume. Every single facilitator they tested violated at least one payment verification or settlement rule.

We run a facilitator in production. When the paper landed, we had two choices: skim the abstract and move on, or take it seriously and audit our own code against every attack class they described. We chose the latter.

Here's what we found, what we fixed, and a practical audit checklist for anyone operating an x402 payment gateway.

The Paper: A Quick Summary

The EPFL/Zhejiang team (arXiv:2607.19545) built an automated testing framework that systematically probes x402 payment gateways for violations of the protocol's three core guarantees:

Payment verification — the facilitator must cryptographically verify that payment was made before delivering the service
Settlement finality — once verified, the settlement must either succeed atomically or fail without delivering the service
Resource protection — the facilitator must not allow attackers to consume paid resources without paying (gas abuse, replay, double-spend)

They classified attacks into four families:

Attack Class	What It Exploits	Impact
Free Shopping	Settle failure → still serve. Invalid signatures accepted. Zero-amount payments pass.	Attacker gets paid service for free
Asset Theft	Facilitator wallet compromise. Refund-to-attacker. Settlement amount manipulation.	Attacker drains facilitator funds
Service Denial	Replay attacks. Sig reuse. Malicious payloads causing facilitator crash.	Legitimate agents can't pay or get service
Gas Abuse	Facilitator pays gas for malicious txns. Spam causing repeated on-chain ops.	Facilitator bleeds gas fees

The paper reports that Coinbase, PayAI, and Mogami had acknowledged six of the vulnerabilities by February 2026 — some already fixed, others still being addressed. But the broader finding — every facilitator had at least one vulnerability — is the real headline.

Our Audit: Methodology

We run a production x402 facilitator handling payment for 326 services. The codebase spans four files that matter for payment security:

proxy.js (2,472 lines) — the main gateway: receives requests, checks trials/credits, forwards to services, injects payment headers
x402.js (1,163 lines) — the payment engine: signature parsing, facilitator verify/settle, on-chain verification, receipt generation
receipts.js — cryptographic receipt signing and verification
payment.js — payment model: amount calculation, network routing

Our audit mapped each attack class from the paper to specific code paths, then traced every path manually to verify the control flow.

Free Shopping: The Most Critical Check

This is the big one. Free Shopping means "attacker gets paid service without paying." The paper found it in the majority of facilitators. The root cause is almost always the same pattern: settle failure after verify success, but the service is still delivered.

Here's the correct control flow for a paid request:

1. Parse payment from HTTP header
2. Call facilitator.verify(signature, amount, network)
3. If !verify.isValid → return 402 (don't serve)
4. Call facilitator.settle(verifiedPayment)
5. If !settle.success → return 402 (don't serve)  ← THIS IS THE CRITICAL CHECK
6. Generate receipt
7. Forward request to service
8. Return service response + receipt

Step 5 is where most facilitators fail. They verify successfully (step 3), then if settlement fails (step 5), they either:
(a) serve the content anyway — "the payment was verified, settlement will probably go through"
(b) log an error and continue — "we'll reconcile later"
(c) return a partial response — "here's a degraded version"

All three are Free Shopping vulnerabilities.

Our main proxy path (proxy.js → x402.js) passed this check: the processPayment() function properly returns null on settlement failure, and the caller returns 402 without forwarding the request. The primary payment path is secure.

What We Found: One Real Vulnerability

⚠️ Vulnerability Found — x402.js processPayment() function: when settlement failed, two code paths (gas and api-review endpoints) still delivered the service response instead of returning 402. The settlement call returned an error, but the function continued execution and returned the paid service data.

Here's what the vulnerable code pattern looked like (simplified):

// VULNERABLE PATTERN (simplified)
async function processPayment(payload, priceCents, networkId) {
  // Step 1: Verify signature — this works correctly
  const verifyResult = await facilitatorVerify(payload, priceCents, networkId);
  if (!verifyResult || !verifyResult.isValid) {
    return null; // ✅ Correct: no verify → no service
  }

  // Step 2: Settle — but settlement failure was NOT handled
  const settleResult = await facilitatorSettle(verifyResult);
  // ❌ BUG: settleResult could be null or failed, but code continues

  // Step 3: Return paid service data
  return {
    receipt: generateReceipt(verifyResult),
    data: await fetchServiceData(verifyResult.serviceEndpoint)
  };
  // ❌ Service delivered even when settlement failed
}

The fix was straightforward: check the settlement result and bail out if it failed:

// FIXED
async function processPayment(payload, priceCents, networkId) {
  const verifyResult = await facilitatorVerify(payload, priceCents, networkId);
  if (!verifyResult || !verifyResult.isValid) {
    return null;
  }

  const settleResult = await facilitatorSettle(verifyResult);
  if (!settleResult || !settleResult.success) {
    console.error('[x402] SETTLE FAILED — returning 402, no service delivered');
    return null; // ✅ Fixed: settle failure → no service
  }

  return {
    receipt: generateReceipt(settleResult),
    data: await fetchServiceData(verifyResult.serviceEndpoint)
  };
}

This was a real bug. In the narrow window between verify and settle, if the facilitator returned a settlement error (network blip, facilitator-side issue, gas spike), the service would still be delivered. The attacker would get a paid API call for free.

We deployed the fix with zero-downtime reload, verified all four affected endpoints returned correct 402 responses, and the backup files are timestamped and stored.

Audit Results: Attack-by-Attack

Here's how our facilitator scored against every attack class in the paper:

Attack Class	Status	Details
Free Shopping — settle failure	🔴 Found & Fixed	Fixed in processPayment(); settle failure now returns null → 402
Free Shopping — invalid sig	🟢 Safe	facilitatorVerify() properly validates all signatures before returning isValid
Free Shopping — zero amount	🟢 Safe	Minimum 1 cent enforced; schema.exact validation catches zero amounts
Asset Theft — wallet keys	🟢 Safe	Platform wallet is env-var only; no private key in code or logs
Asset Theft — refund redirect	🟡 Low Risk	Refunds go to payment source address (on-chain tx); facilitator wallet not used for refunds
Service Denial — sig replay	🟢 Safe	sigUsed() / lockSig() dedup; each signature usable exactly once
Service Denial — tx replay	🟢 Safe	txUsed() / lockTx() dedup per transaction hash
Gas Abuse — spam txns	🟡 Mitigated	5-min pending tx timeout; invalid txns cleaned without on-chain cost
Gas Abuse — malicious payload	🟢 Safe	Amount validated client-side before any on-chain operation

What Every x402 Operator Should Check

Based on this audit, here's a practical checklist for anyone running an x402 payment gateway:

1. Trace your settle failure path

This is the #1 vulnerability. Find every code path that calls settle, and verify that settle failure means no service delivery, no exceptions. Don't trust error handlers that "log and continue." Don't trust try/catch blocks that don't re-throw. The only acceptable behavior on settle failure is returning 402.

2. Signature deduplication is not optional

If your facilitator doesn't track used signatures (or nonces) and reject replays, an attacker can pay once and call the same paid endpoint infinitely. This is trivial to implement (a Set or Map of used sigs with TTL expiry) but catastrophic to miss.

3. Zero-amount transactions must be rejected

The x402 challenge format includes maxAmountRequired. Verify that your settlement code rejects zero-amount payments even if the facilitator says they're valid. A facilitator bug that accepts zero-amount settlements becomes a Free Shopping vulnerability downstream.

4. Receipts are not optional — they're accountability

The paper notes that facilitators without receipt generation can't provide dispute resolution. If an agent claims they paid but didn't get service, the facilitator has no evidence to resolve the dispute. Cryptographically signed receipts (linking payment txHash → service endpoint → response hash) are the foundation of accountability in agent payments.

5. Test your 402 responses in production

Set up a monitor that calls your endpoints with invalid signatures and verifies you get a proper 402 response (not a 200 with trial data, not a 500, not a timeout). The EPFL team built automated testers for this — you should too.

Why This Matters Beyond Security

The EPFL paper is a milestone for the x402 ecosystem. It's the first independent, academic security audit of the protocol in production — and it shows that the protocol design is sound (the attack surface is implementation errors, not protocol flaws).

But there's a bigger story here: security audits create trust, and trust is what's missing from agent-to-agent payments.

Right now, the biggest barrier to M2M payment adoption isn't technology. The payment rails work — Cloudflare, Coinbase, Stripe, and 40+ x402 Foundation members have proven that. The barrier is that agents (and their developers) don't trust the payment infrastructure. They don't know if their money is safe. They don't know if they'll get what they paid for. They don't know if there's recourse when something goes wrong.

Independent security audits — and operators who publicly share their results — are part of building that trust. Every facilitator that passes an audit and publishes the results makes the whole ecosystem stronger.

We're doing our part. If you run an x402 facilitator, we encourage you to do the same.

References

Wang, Yang, Chen, Ji, Payer — "When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments", USENIX Security 2026 (arXiv:2607.19545)
USENIX Security '26 presentation — usenix.org/conference/usenixsecurity26/presentation/wang-qinying
x402 Protocol Specification — x402.org
Cloudflare Wallets documentation — developers.cloudflare.com/wallets

Disclosure: We found and fixed the vulnerability described in this post on August 9, 2026, the same day the EPFL paper came to our attention. No user funds were at risk — the vulnerability was in the service-delivery path, not the fund-custody path. The affected endpoints (gas, api-review) had low paid transaction volume. We're publishing these results to help the x402 ecosystem mature.

Originally published at minia2a.uk.

Your x402 Endpoint Isn't in the Bazaar Yet — and It's Probably Not Your Metadata

minia2a — Sun, 04 Oct 2026 17:37:51 +0000

Your x402 Endpoint Isn't in the Bazaar Yet — and It's Probably Not Your Metadata

Every few weeks someone in the x402 channels asks the same thing: "I deployed a valid endpoint, why isn't it in the Bazaar?" The usual first guess is metadata — a missing field, a bad extensions.bazaar block, a truncated description. Sometimes that's right. But the larger answer is structural, and it's written plainly in the CDP docs: the Bazaar has no registration step at all. A resource gets indexed when a payment settles through the CDP Facilitator.

Discoverability is metadata; indexing is settlement. Two different gates. Most sellers only ever test the first one.

Gate one: is your endpoint discoverable?

This part you control directly, and you can check it before you ever take a payment. CDP exposes a free, unauthenticated validation endpoint:

POST https://api.cdp.coinbase.com/platform/v2/x402/validate

It returns bazaarExtension.discoverable plus a list of named preflight[] checks, each with a severity. The rule that matters: a failure with severity == "required" means the resource will never be indexed; advisory is a warning, not a blocker.

We ran a stratified sample of 64 live endpoints from our own catalog (across price and category) through it:

64 / 64 discoverable = true, 0 required preflight failures.

As a negative control we fed it one endpoint we already knew was retired (x402-language-detect): discoverable = false, 21 required failures. The validator is not a rubber stamp — it flips on a genuinely broken resource.

So our metadata is fine. And that is exactly the trap. Passing gate one proves nothing about gate two, and gate two decides whether anyone can find you.

Gate two: has your endpoint settled?

From the CDP seller docs, verbatim:

"Every validated endpoint is eligible for indexing in the CDP Bazaar after a successful settled payment." — with the setup item: "Complete a successful paid call through the CDP Facilitator."

Not after registration. Not after validation. After a settled payment through the CDP Facilitator.

This is the fact that explains the most common confusion. If your 402 is answered and settled by some other facilitator — or by your own gateway, as ours is — then no CDP settlement ever occurs, and by the docs' own rule your resource is eligible forever and indexed never. It is not a metadata problem. It is a rail condition.

On the settlement request, two fields must be present or the route is treated as an ordinary 402 and skipped:

paymentPayload.extensions.bazaar — the metadata block the index stores.
paymentPayload.resource — which route it belongs to.

The docs put it flatly: "Only routes that declare Bazaar metadata are indexed."

What gets you removed

Being indexed is not permanent. Three documented exits, none of which announces itself:

Trigger	Effect
30 days with no settlement	Removed from both the catalog and search results
Stops returning `402 Payment Required`	Eventually removed from the index entirely
Sustained consecutive probe failures	First down-ranked, then auto-delisted

The middle row is the one to internalize. An endpoint that starts returning 200 — because you added an unauthenticated demo path, or a refactor bypassed the payment middleware, or a CDN cached a success response — gets delisted for being too available. The index is a directory of things that charge money; when a thing stops charging, it stops being a useful row.

Two edge cases that quietly sink good endpoints

1. TypeScript indexes you by default; Python does not. On the CDP SDK's TypeScript building blocks, discovery is automatic — "You do not need to add a discovery setting." On Python it is explicitly opt-in: you register the Bazaar resource-server extension and declare metadata per route yourself. Same protocol, same 402 shape, opposite default. A Python seller can ship a textbook-correct endpoint and never appear, purely because the language differs.

2. High-cardinality path segments get collapsed. The Bazaar normalizes any path segment that consists entirely of a high-cardinality identifier — a UUID, a wallet address, a tx hash. If your product is /token/<address> or /tx/<hash>, every one of those URLs collapses into a single index entry. Usually the right call for the index, but it means a parameterized API looks like one resource, not thousands. If you need distinct entries, the escape hatch is a prefix or suffix that is not an identifier.

What a seller should actually do

Validate before you deploy, not after. One unauthenticated call names the exact required fields you're missing.
Confirm your settlement rail. If being in the CDP Bazaar matters, the payment must settle through the CDP Facilitator. Verify it — nothing in your 402 tells you which facilitator will clear it.
Send the two fields on the settlement payload — extensions.bazaar and resource. Static metadata alone is not enough.
Keep answering 402. A convenient unauthenticated path is a delisting vector. If you want a free tier, gate it behind the same signed-trial check so the unauthenticated answer stays a 402.
Don't read a small index count as a metadata failure. For most of the catalog it's settlement volume, not schema quality. Check both gates before hunting a bug that isn't there.

Sources: CDP x402 seller docs, "Get discovered" (docs.cdp.coinbase.com/x402/seller/get-discovered), read 2026-10-04. Validation sample: POST api.cdp.coinbase.com/platform/v2/x402/validate over 64 live endpoints from our catalog, all discoverable = true with zero severity: "required" failures; negative control on a retired endpoint returned discoverable = false. Quotes attributed to the CDP docs are verbatim.

48 Networks, One Winner: What 24,419 x402 Resources Actually Settle On

minia2a — Sun, 04 Oct 2026 14:25:04 +0000

48 Networks, One Winner: What 24,419 x402 Resources Actually Settle On

"Which chain does this x402 service settle on?" is a question the catalog can answer and the homepage copy usually can't. So we paged the entire CDP x402 discovery index — the largest public x402 catalog — and counted what its resources actually advertise as payment options. The result is cleaner than the marketing: 48 distinct networks appear, and Base appears in 97.9% of resources. The interesting part is not that one chain dominates. It is how much of the catalog is one publisher, and how fast it grew without diversifying.

What was measured

Source: https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources — the CDP x402 discovery index, read-only, no auth.
Method: paginate the endpoint, combine every page, count the accepts[] array on each resource. Each entry in accepts[] is one payment option: a network, an asset, an amount, a payee.
Frame: 24,419 resources on 2026-10-03. The same index read 19,126 resources on 2026-09-29 — up 27.7% in four days.

A resource is a listing, and an accepts[] entry is an advertised option. Neither is evidence that anyone paid. This is a map of what the catalog says is payable, not of what settled.

Finding 1 — Base is present in 97.9% of resources

Grouping by whether a resource's advertised networks include Base (eip155:8453):

Class	Resources	Share
Base only	14,515	59.4%
Base + at least one other network	9,398	38.5%
No Base at all	506	2.1%

Read together with the asset column below, this says something practical for a buyer agent: if it holds USDC on Base, it can pay 97.9% of the advertised catalog. If it holds USDC on any other single chain, it can pay a small fraction of it. The catalog's diversity lives almost entirely in the multi-rail tail, not in the base case.

Finding 2 — 48 networks, and the tail is long and thin

Network (CAIP-2)	Resources advertising it
`eip155:8453` (Base)	23,913
`solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp`	6,638
`eip155:137` (Polygon)	3,408
`eip155:42161` (Arbitrum)	2,665
`eip155:84532` (Base Sepolia)	2,366
`eip155:143`	910
`eip155:10` (Optimism)	659
`eip155:43114` (Avalanche)	655
`xrpl:0`	641
`eip155:42220` (Celo)	603
`stellar:pubnet`	599
`algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=`	337

The 36 networks below the visible cut are real but small. Note that Base Sepolia — a testnet — carries more than a quarter as many listings as Solana mainnet. A discovery index counts what people list, not what people pay, and testnets list cheaply.

Finding 3 — the asset is USDC, and the scheme is `exact`

Across every accepts[] entry in the catalog, the asset is overwhelmingly USD Coin. The five most-quoted assets, by number of entries:

Asset (contract)	Accept entries
`0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` (USDC, Base)	25,186
`EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v` (USDC, Solana)	6,893
`0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359` (USDC, Polygon)	3,430
`0xaf88d065e77c8cC2239327C5EDb3A432268e5831` (USDC, Arbitrum)	2,711
`0x036CbD53842c5426634e7929541eC2318f3dCF7e` (USDC, Base Sepolia)	2,371

The settlement scheme is just as concentrated. Of all accept entries, exact accounts for 48,257; everything else is a long tail — upto (782), batch-settlement (52), and a dozen experimental schemes in the single and double digits. A catalog of 24,419 resources is, in practice, a catalog of one asset and one scheme with a decorative fringe.

Finding 4 — 2,054 publishers, and the top of the curve is steep

Counting by resource host:

Measure	Value
Distinct hosts in the catalog	2,054
Hosts with ≥100 resources	36
Share of all resources held by the top 5 hosts	28.8%

One host alone lists 3,420 resources. That single fact changes how the whole catalog should be read: a 27.7%-in-four-days jump in the resource count is not 5,000 new teams arriving. It is a handful of bulk publishers pushing rows. The index is inflating faster than it is diversifying, and the two numbers above — 24,419 resources, 2,054 publishers — are the pair to quote together, never the first alone.

Where our own service sits. We are one small row on this map: a Base-only, USDC-only, exact-scheme seller. That is the median of the catalog by rail, not the tail. It is also, deliberately, a single rail — we do not advertise Solana, XRPL, Celo, Stellar, or Algorand, and the 2.1% of resources that take no Base are, for us, unreachable buyers in the other direction. Cross-rail paying is the open problem this data makes visible: the catalog lists a buyer's chain, but a 402 is answered in one rail, and nothing in the listing reconciles the two.

What a builder should take from this

Quote the publisher count, not just the resource count. "24,419 resources" and "2,054 publishers" are the same catalog; only one of them is a market size.
Base is the safe default rail, by a wide margin. 97.9% of advertised resources accept it. If you ship one settlement rail, ship that one.
Testnets inflate listings. Base Sepolia out-lists XRPL and Stellar mainnets in this index. Filter testnets out before you draw any conclusion about mainnet coverage.
"Multi-chain" in a listing usually means "one chain plus a fallback." 38.5% of resources are multi-network, but the currency is nearly always USDC and the scheme nearly always exact — the variety is in the chain, not in the payment shape.

Source: api.cdp.coinbase.com/platform/v2/x402/discovery/resources, full pagination read on 2026-10-03 (24,419 resources). Compared against the same index read on 2026-09-29 (19,126 resources). All figures are counts over the resources' own advertised accepts[] arrays; nothing here is a settlement figure. Re-derivable from the public endpoint.

Originally published at minia2a.uk.

An Index Is Not a Market: What the x402 Storefront Ships, and What It Leaves Out

minia2a — Sat, 03 Oct 2026 13:42:09 +0000

This week the x402 ecosystem got a storefront. Agentic.market — a directory of x402-enabled services, operated by Coinbase and presented as an "app store for agents" — now headlines 2,980 services. We are in it. So instead of arguing about it from the outside, we queried its public catalog and checked our own row, field by field, against our live 402. What that exercise shows is a clean line between two things that both call themselves a marketplace: an index, and a market.

What it is, pinned to the source

Agentic.market describes itself as "a directory of x402-enabled services that agents can call with pay-per-request pricing in USDC," with "no registration, no API keys, no rate limits."
Its footer is explicit about ownership: x402 is owned by the Linux Foundation, and the marketplace itself is operated by Coinbase and is not an official x402 Foundation product.
There is a read-only public catalog: GET https://api.agentic.market/v1/services and .../v1/services/search?q={query}, both documented in https://agentic.market/llms.txt.
The network figures — roughly 69,000 active agents, 165M+ cumulative transactions, $50M volume, ~85% settling on Base — are self-reported by Coinbase (CDP engineering lead Erik Reppel) and carried by several outlets. We did not independently verify them, and neither should you.

Note the actor: the storefront is the protocol steward's own commercial product, built on a standard it governs through a foundation. That is fine to build — but it means the storefront's incentives and the standard's neutrality are not the same thing.

Our own row, measured

GET /v1/services/search?q=minia2a returns exactly one record — minia2a-uk, domain minia2a.uk, network eip155:8453 — carrying 20 endpoints. We probed all 20 against our live challenges on 2026-10-03:

check	result
endpoints indexed	20
answer `402` with a payment challenge	20 / 20 — no dead links
indexed price equals our live 402 amount	18 / 20
indexed price differs (their snapshot is stale)	2 (`loan`, `hash`: index says 0.01 USDC, live is 0.5)
service category in the index	empty string
service description in the index	empty; endpoints show auto-generated `"minia2a service: x402-<id>"`
submission path to fix any of the above	none documented on the site or in `llms.txt`

Two things are true at once, and it is worth keeping them apart. First, rail-level interoperability is real: every endpoint answers their crawler with the standard challenge, so a wallet configured for their storefront can mechanically pay ours. That is the protocol working as intended.

Second, the row is thin. No category, no description, two prices frozen at a value we stopped charging, and duplicate entries: 9 of the 20 endpoints are indexed under a doubled-prefix spelling of our path (the x402- id prefix applied a second time), 2 of them under both that and the canonical path. Both spellings resolve — the gateway tolerates one doubled prefix — so they are duplicates, not breakage, but each keeps its own counters and nothing merges them. The two stale prices are not our error: our catalog and our live challenge agree with each other for both endpoints. Their figure is a snapshot from the last observation, and it ages at its own pace. We cannot edit it, because an index has no provider-facing edit surface.

What an index does, and what a market does

This is not a criticism of indexing. Indexing is a hard job — crawl a federation of facilitators, normalize wildly different endpoints into one schema, at scale. 2,980 services is real work. But an index and a market answer different questions, and conflating them is how buyers get hurt.

question a user actually has	index	curation / market
Does a service with this capability exist?	yes, best effort	yes
Is this price the price I will be charged right now?	only as fresh as the last crawl	checked against the live challenge
Can I try it before paying?	no concept of a trial	trial path is a first-class rule
Who answers when a row is wrong?	nobody; the row is auto-derived	a named operator, with the row under a check
Is there a category I can trust?	only if the crawler inferred one	set by the listing's own metadata

The difference is not engineering quality. It is who answers for the row. An auto-derived listing can only ever be as good as its crawl, and no crawl knows whether a price moved, whether a seller is reachable, or whether two entries are the same service behind a path alias. Those are exactly the questions a buyer has.

If you build on top of any index: treat the row as a lead, not a contract. Fetch the live 402 before you commit a payment decision. The challenge is authoritative; a directory entry is a memory of one.

What this changes for us

Not much about the rail — we settled on the same one and it works. What it sharpens is why a curated, agent-first storefront exists next to a very large index: not to be bigger, but to be answerable. Every price we publish is the price our own live challenge returns; if it drifts, a check fires rather than a user discovering it. Trials are a rule, not a row attribute. When a service goes stale, the remedy is on our side of the table.

The honest summary of the week is not "an index launched and threatens us." It is that the layer everyone is racing to own — discovery — has at least two shapes, and only one of them can be held to a number. We would rather be small and answerable than large and unaccountable.

Measurement note: the Agentic.market figures were read live on 2026-10-03 from api.agentic.market (our row) and from public reporting for the network-wide numbers, which are marked self-reported. Our own prices were compared against our live 402 challenges and our catalog, which agree. No end-to-end settlement through a third-party facilitator was tested for this post, and we make no claim that we did.

A 402 Can Be Structurally Perfect and Still Unpayable

minia2a — Sat, 03 Oct 2026 08:21:57 +0000

If you are a buyer, you inspect the 402 before you pay it: the scheme is exact, the network is the chain you hold, the amount is what the listing said, the payTo is an address somebody set up. All four can be right and the challenge still be unpayable — because none of those four is what your client actually signs against. That lives in a fifth place, and the official SDK reads it with a default that never raises.

What you check, and what the client signs

An x402 payment challenge is an array of accepts entries. Four fields describe who gets paid and how much:

field	answers
`scheme`	how the transfer is authorised (`exact`)
`network`	which chain settles it (`eip155:8453` — Base)
`amount`	how much, in the asset's base units
`payTo`	which address receives it

What the buyer's wallet signs is an EIP-712 typed message, and its domain is not spelled out in those four fields. On the EVM rail it comes from the entry's extra object: extra.name and extra.version are the token's EIP-712 domain name and version. The signature is only valid if those match what the token contract on that chain actually declares. Pay USDC on Base with extra.name: "USDC" instead of "USD Coin" and every signature recovers to an address nobody controls.

Why this failure is silent

The reason it is worth writing down is that on a first-party route, the same operator both mints the challenge and verifies the signature — and both read the same literal. So the two never disagree with each other. A wrong domain does not surface as a mismatch between two products that can be diffed; it surfaces only as payments that recover to nobody, i.e. every payment failing, with no error anywhere naming the cause. On a rail that mints its own challenges, that is the half the buyer cannot verify from the outside and the seller cannot verify from the inside either.

The shape: a challenge with a valid scheme, a supported network, the advertised amount and a real payTo — and an extra whose domain is wrong. Every field a buyer can see passes; the payment cannot be signed.

The fifth field, and the SDK's silent default

There is a second value in extra that decides how the transfer is authorised: assetTransferMethod. We read the installed client to be sure of what it does with it rather than taking it on faith. In @x402/evm 2.25.0, the exact scheme resolves it like this:

// @x402/evm 2.25.0, exact scheme — "Routes to EIP-3009 or Permit2
// based on requirements.extra.assetTransferMethod."
const assetTransferMethod = paymentRequirements.extra?.assetTransferMethod ?? "eip3009";
if (assetTransferMethod === "permit2") {
  return createPermit2Payload(...);
}
return createEIP3009Payload(...);   // any other value lands here

Read that carefully. The only value that branches away from the default is the exact string "permit2". A missing key, an empty string, or a value the client has never heard of all take the same path: EIP-3009. No exception, no warning. So for a buyer, the safe assertion is not "assetTransferMethod equals a known-good value" — it is "the key is absent, or equals one the client supports", because equality with a value you invented is exactly the shape that falls through.

One nuance that is easy to over-generalise from: the batch-settlement scheme in the same package does not fall through — it raises on a value that is neither eip3009 nor permit2. The silent default is a property of the exact path, which is the path most listings — including ours — use. Same field, two different failure behaviours depending on the scheme, which is itself a reason to check the scheme you are actually being offered.

What we assert about our own challenges

The rule we adopted is the one above: assert the absence of assetTransferMethod, not equality with a guessed value. Here is our own quick-start route read straight off the deployed challenge:

$ curl -s 'https://minia2a.uk/x402/time'
accepts[0].scheme = exact
accepts[0].network = eip155:8453
accepts[0].amount  = 100000          # == the advertised price, exactly
accepts[0].asset   = 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
accepts[0].payTo   = 0xAb62452b4b019bC4402BFfCca6C706d16d72A7Bf
accepts[0].extra   = { "name": "USD Coin", "version": "2" }
"assetTransferMethod" in extra = false

One accepts entry, none missing. The domain the wallet is asked to sign against is declared in the challenge; the branch the client takes is the EIP-3009 default, which is the branch USDC on Base supports. That is what we can show a buyer from the outside.

What we do not verify daily

One honest limit. The values in extra are pinned against what the token contract's own name() and version() return on Base — but reading that from the chain is a third-party network call, so it does not run in our daily path. Our daily check compares the live challenge against a constant in the guard file, which means the challenge and the constant can agree with each other while both are wrong about the chain — precisely the failure mode this post describes. The chain read is a separate mode that runs when the pin or the asset changes, which is the only moment the answer can move. A buyer checking a stranger's route cannot run even that; the most they can read is the challenge itself, which is why the challenge should carry the domain explicitly and the client should say what it does with a value it does not recognise.

Measured 2026-10-03: the challenge read above is live from https://minia2a.uk/x402/time (HTTP 402, GET only, no trial burned, nothing signed). The client behaviour is read from the installed @x402/evm 2.25.0 distribution, not from documentation. This post describes a failure shape and the check that catches it; it is not a claim that any particular route is broken.

Cloudflare Put a 402 Paywall Behind Every Domain. The Rail Was Never the Hard Part.

minia2a — Fri, 02 Oct 2026 23:29:36 +0000

On 2026-09-30 Cloudflare opened a closed beta of its Monetization Gateway. It lets a domain owner charge agents per request over HTTP 402, settled in USDC on Base, through Coinbase's x402 Facilitator. We have settled on exactly that rail since we launched. So the interesting question is not whether the rail works — it plainly does — but what is left to build on top of it.

What actually shipped, verified

People will summarize this launch in a hundred ways, so it is worth pinning the facts to the source rather than to the retellings:

The interface is the status code. Cloudflare's own framing: there is "no redirect to a checkout page and no separate payment API to call."
Settlement is USDC on Base, through Coinbase's x402 Facilitator.
Closed beta, U.S.-based sellers and buyers only, more geographies promised.
Named early customers: Cloudflare AI Gateway (pay per inference), Ceramic.ai (pay per web search), Stocktwits (pay for stock signals), API2PDF (pay per API access).
Their published API2PDF example carries the challenge in a payment-required response header.

We checked our own live challenge to compare. curl -D - https://minia2a.uk/x402/mime-type answers 402 with the payment requirements in both the JSON body and a payment-required header, and the accept entry is:

{"scheme":"exact","network":"eip155:8453",
 "asset":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
 "payTo":"0xAb62452b4b019bC4402BFfCca6C706d16d72A7Bf",
 "amount":"50000","maxTimeoutSeconds":120,
 "extra":{"name":"USD Coin","version":"2"}}

Same scheme (exact), same network (Base, eip155:8453), same asset (USDC), and the same EIP-712 extra (name/version) a facilitator needs to build the transfer authorisation. That is the sentence worth stating plainly: this is not a competing rail. A wallet that learned to pay a Cloudflare-metered endpoint is, mechanically, able to pay ours.

What we did not test. We verified the shape of our challenge against the shape that facilitator requires. We did not route a real payment end-to-end through Coinbase's infrastructure from our host — third-party egress here is restricted, and "shape-verified" is a claim we can stand behind where "settlement-verified" is not.

The half that is genuinely new: the buyer

Most x402 coverage is about sellers — who is allowed to charge. The more interesting half of this announcement is on the buy side: U.S. Cloudflare customers can pay per inference at request time by sending PAYMENT-METHOD: x402.

A pay-per-call economy has two cold starts, not one. Everyone notices the seller side — nobody lists an endpoint until there are buyers to call it. The buyer side is quieter and harder: an agent will not integrate a payment SDK it does not already carry. A header that a platform already terminates is a buyer cold-start being solved by somebody else, for free. That is good for the whole space, this catalog included.

Four jobs a gateway does not do

A gateway monetizes one domain, on first contact. A marketplace has to do four other things, and none of them is the rail.

1. Cross-seller discovery

A gateway answers "how does this endpoint charge?" It cannot answer "which of 1,694 endpoints should I call for this task?" Discovery is a separate layer, and it is the layer that decides whether an agent finds any seller at all rather than the one domain it already knew.

2. First contact

A gateway charges on the first request; that is its job. An agent evaluating an unknown endpoint needs the opposite — a free first look. We give 5 free trial calls per signed wallet, one shared allowance across the catalog, no registration, so testing an endpoint costs a signature and not a payment.

And the footnote, because it is the same disease as the provenance problem below: most of the wallets in our own trial count are ours. Of 1,338 trial wallets in the last 7 days, 1,336 trace to our own address prefixes. The trial mechanism is real and it works; the trial demand number is mostly us proving it works. We would rather publish the split than a flattering total.

3. Accountability when the delivery is bad

A facilitator moves money. It does not adjudicate a 200 that returned garbage. Settlement and redress are different layers, and the second is where trust actually accumulates. We run a refund path: 57 refunds, 0.875 USDC, against 226 settled on-chain payments. Small numbers — but they exist, and they are the layer a pure gateway has no structural reason to build.

4. Provenance of the numbers

Volume in agent payments is easy to inflate. A seller buying from itself moves a headline and proves nothing; independent analysis of Base x402 traffic this week found the same shape at scale — most headline buyers funded by the sellers themselves. So we publish the split instead of the total: 226 settled on-chain payments / 6.227 USDC, 6 paying wallets in 7 days against 1,338 trial wallets. That gap is the honest state of the market, and it is more useful to a builder than a bigger, fuzzier number.

The threat, stated without spin

Cloudflare owns the edge, an agent-identity primitive, and now a wallet relationship. That is three of the four ingredients of a marketplace. What it does not have is a catalog, and today the gateway is a closed U.S. beta with no published fee.

If it opens up and bolts a directory on top, the rail becomes the marketplace and the discovery layer gets squeezed. Our bet is that breadth and trust are the durable layer and the rail is not: rails commoditize, and the thing that told you which endpoint to call, let you try it free, and refunded you when it lied does not. If we are wrong, this post is a useful record of when we were.

What we are watching

Whether the beta leaves the U.S., and at what fee — an unpublished fee is the whole question for sellers doing the math.
Whether a directory appears on top of the gateway. That is the actual competitive event, not the gateway itself.
Whether the x402 spec's newer schemes — upto, batch-settlement, auth-capture — become how agents actually buy metered capacity, because a paywall that can charge "up to X" is a different product from one that charges a fixed amount per request.

We will keep the challenge in the open. If you are building a client against Cloudflare's gateway and want to point it at an endpoint in our catalog, it is the same object — a 402 with an exact accept on Base, in the body and in the header.

Sources: Cloudflare's Monetization Gateway closed-beta announcement, 2026-09-30 (blog.cloudflare.com/monetization-gateway-beta/). Live challenge read from https://minia2a.uk/x402/mime-type on 2026-10-02. Counts from https://minia2a.uk/api/stats on 2026-10-02; the trial-wallet first-party share and the on-chain/refund split are fields the platform publishes and discloses as first-party where applicable.

Two Kinds of Machine Consumer: the ones that read your 402, and the ones that replay

minia2a — Fri, 02 Oct 2026 18:56:59 +0000

A few weeks ago we noticed that our 402 payment challenge was making a specific kind of caller produce malformed 404s: the challenge carried a discovery field whose value was a service id (x402-time), and a consumer was appending that value to our published paths as if it were a URL segment. We wrote that up and asked the obvious follow-up: if we stop emitting the field, do the 404s stop? We said we'd want to run that experiment before writing the mechanism down as settled. We ran it. This is the result, and it is more interesting than a yes or no.

What we changed

The fix was narrower than it first looked. The field was doing internal work — it keyed a lookup into our per-service input examples — so we couldn't simply delete it. The change was to take the value, use it, and drop it before the challenge is serialized. After that, the field is absent from what a caller actually receives:

$ curl -s 'https://minia2a.uk/x402/time?probe=1'
extensions.bazaar keys = ["discoverable", "info", "schema"]
"routeTemplate" in keys = false

So the write side is clean: the challenge no longer carries the value that was being appended. If the mechanism we described was right, and the consumer was reading the field from the challenge, the 404s should now go to zero.

What we measured

We re-ran the measurement with the clock pinned to the deploy (--since 2026-10-02T11:16:27Z, the moment the new binary came up — the rotated logs still hold the pre-deploy lines and would otherwise make a fixed thing look broken). The result, over the whole post-deploy window:

154 of 271 distinct 404 paths still matched the "published path + its own service id" shape. Not zero.

The natural reading is "the fix didn't work." That reading is wrong, and the reason is worth the rest of this post. Before concluding anything, look at who the 154 came from:

property	value
user agents	1 (`Nitrograph-HealthCheck/1.0`)
source IPs	1
time span of the burst	12 seconds (12:35:58Z → 12:36:10Z)
that IP's requests, across every rotated log	1,078
…of which responses were 402 (the challenge)	0
…of which responses were 404	1,078

That last pair is the whole story. Across every log we retain, this caller has made 1,078 requests and received 1,078 404s. It has never once fetched a 402 from us — not before the change, not after. It is not reading our challenge and mis-parsing a field; it is replaying a list of URLs that it built at some earlier point and has not rebuilt since.

You cannot fix a consumer that does not read you. Removing the field from the challenge changed a document this caller never opens. The residual 154 are not evidence the mechanism was wrong — they are evidence that this particular caller is outside the mechanism's reach by construction.

The distinction

It is tempting to treat "machine consumers" as one audience, but on the evidence there are (at least) two:

	readers	replayers
behavior	fetch the current challenge, then act on what they find	act on a copy captured earlier
your fix reaches them	yes, on their next fetch	only when their source refreshes — or never
what you can measure about them	challenge fetches in your own logs	a flat wall of one status code
what they cost you	your real traffic	your 404 rate and your log volume

The useful part is that the second column is legible in data you already have. You do not need to detect a "bad bot." You need one question answered per source: has this caller ever fetched the document I just changed? If its entire request history is one status code, nothing you serve will change its behavior, and it belongs in a different bucket from the callers your fix is actually for.

What this changes in practice

Three things we now do differently:

Measure the write side and the read side separately. "The field is gone from the challenge" and "the malformed requests stopped" are different claims with different evidence. We confirmed the first directly (a probe). The second needs a consumer that both fetched a fresh challenge and then mis-used it — and in this window no such request exists, so the read-side half stays unconfirmed, not refuted.
Attribute residuals before explaining them. A count of 154 invites a story. The story has to survive the per-source breakdown: one UA, one IP, 12 seconds. Group first, theorize second.
Do not read a replayer's noise as your own regression. A guard that fires on every replayed request will fire forever, and its redness stops carrying information. That is a defect in the guard, not in the system it watches.

This is the sibling of a rule we keep relearning: a check has to measure the thing it names. "The malformed 404 count" is not "our fix's effect" unless every counted line could, in principle, have been affected by the fix. When the population includes callers that never read you, the count is a mix — and a mix with an unreachable component in it can never reach zero.

The honest scoreboard

For the record, because the earlier post asked for it explicitly:

claim	status
the challenge no longer carries the appended value	confirmed (live probe)
removing it stops the malformed 404s	untested — no post-deploy caller both fetched a challenge and then appended an id
the sole surviving source is a consumer that never fetches the challenge	confirmed (0 of 1,078 requests were 402)

We would rather leave the middle row "untested" than upgrade it to "works" because the number went the way we wanted. The number did not go the way we wanted — it stayed at 154 — and the reason it stayed is itself the finding.

Method: the shape predicate is "a 404 path equal to a published service path with that service's own id appended," with both oracles read from live data (/api/services and the gateway). The per-source status mix is a grep over every rotated gateway log for the single matching source. Both are read-only; the deploy timestamp is the gateway binary's mtime. Callers are identified by user agent and source address; no payload data is inspected.

Catalog Freshness: Why We Won't Self-Buy, and Why There's No "Verified" Timestamp

minia2a — Fri, 02 Oct 2026 02:08:36 +0000

A reader on dev.to asked two things about our catalog measurement: whether we force a self-buy when a price or payee changes so a third-party snapshot moves, and whether our listing page surfaces a "last verified against live 402" timestamp, or leaves that to the facilitator.

Thanks — and the nastiest part is exactly the one you named: the rows that stay wrong are the ones nobody buys, and those carry the biggest gaps.

On the self-buy habit: we looked at it and decided against it. A self-buy is a real settlement, so it writes a real row into our own books — we would be manufacturing payment activity in order to move someone else's snapshot. Our published figures are what our ledger actually holds, and we would rather leave a catalog row stale than make our own payment history say something that did not happen. So for us the snapshot moves only when someone genuinely buys.

On the "last verified against live 402" timestamp: not on the listing page, and that is deliberate. What we do run is a check of our own 402 against our own service records — which answers "is our challenge internally consistent", not "does a third-party catalog still agree with us". Those are different questions, and a green internal check would be a misleading answer to the second one. So the catalog sweep runs as a measurement that prints the discrepancy, not as a guard that claims health.

Which leaves the honest freshness signal the one you cannot fabricate: the last real settlement.

Context: a reply to a question in the comments on The Catalog Is a Snapshot. Method note: the catalog sweep is a measurement, not a health claim — it pulls a directory's rows for our own origin and compares each quoted amount against the live 402 the endpoint actually returns, printing the rows that disagree rather than folding them into a score.

Ranking hints may come from a catalog; the amount and payee an agent signs should come only from the challenge it just received.

DEV Community: minia2a

The Most-Used Agent API in October 2026 Costs Two Cents

The Most-Used Agent API in October 2026 Costs Two Cents

Why that one line matters more than the transaction count

The economics the card networks can't reach

Where minia2a sits on this

The Empty Example: a discovery layer that hands your agent a call it cannot make

The Empty Example: a discovery layer that hands your agent a call it cannot make

Where the example comes from

Why {field:""} is worse than {}

What it cost us

The rule we adopted

How to check your own discovery layer

What we are and are not claiming

What an x402 Rail Announcement Actually Certifies

Three announcements, three different claims

The chain that joined the SDK

The network that crossed a milestone

The CDN that put a paywall on every domain

The five questions a rail announcement does not answer

The only claim that binds at payment time is the challenge

Where this leaves a marketplace

The 429 Your Agent Client Can't Read: designing rate limits for machine callers

The 429 Your Agent Client Can't Read

The one field a retry loop actually reads

What we found in our own API

Why it costs you, not just your caller

A short checklist for agent-facing APIs

What Happens When Academics Stress-Test 15 x402 Payment Gateways: An Operator's Security Audit

The Paper: A Quick Summary

Our Audit: Methodology

Free Shopping: The Most Critical Check

What We Found: One Real Vulnerability

Audit Results: Attack-by-Attack

What Every x402 Operator Should Check

1. Trace your settle failure path

2. Signature deduplication is not optional

3. Zero-amount transactions must be rejected

4. Receipts are not optional — they're accountability

5. Test your 402 responses in production

Why This Matters Beyond Security

References

Your x402 Endpoint Isn't in the Bazaar Yet — and It's Probably Not Your Metadata

Your x402 Endpoint Isn't in the Bazaar Yet — and It's Probably Not Your Metadata

Gate one: is your endpoint discoverable?

Gate two: has your endpoint settled?

What gets you removed

Two edge cases that quietly sink good endpoints

What a seller should actually do

48 Networks, One Winner: What 24,419 x402 Resources Actually Settle On

48 Networks, One Winner: What 24,419 x402 Resources Actually Settle On

What was measured

Finding 1 — Base is present in 97.9% of resources

Finding 2 — 48 networks, and the tail is long and thin

Finding 3 — the asset is USDC, and the scheme is exact

Finding 4 — 2,054 publishers, and the top of the curve is steep

What a builder should take from this

An Index Is Not a Market: What the x402 Storefront Ships, and What It Leaves Out

What it is, pinned to the source

Our own row, measured

What an index does, and what a market does

What this changes for us

A 402 Can Be Structurally Perfect and Still Unpayable

What you check, and what the client signs

Why this failure is silent

The fifth field, and the SDK's silent default

What we assert about our own challenges

What we do not verify daily

Cloudflare Put a 402 Paywall Behind Every Domain. The Rail Was Never the Hard Part.

What actually shipped, verified

The half that is genuinely new: the buyer

Four jobs a gateway does not do

1. Cross-seller discovery

2. First contact

3. Accountability when the delivery is bad

4. Provenance of the numbers

The threat, stated without spin

What we are watching

Two Kinds of Machine Consumer: the ones that read your 402, and the ones that replay

What we changed

Why `{field:""}` is worse than `{}`

Finding 3 — the asset is USDC, and the scheme is `exact`