DEV Community: minia2a

"The x402 facilitator: what actually sits between an agent and the chain when it pays a cent"

minia2a — Thu, 27 Aug 2026 16:59:17 +0000

The x402 facilitator: what actually sits between an agent and the chain when it pays a cent

Most writing about agent payments stops at the happy path: an AI agent hits a paywalled endpoint, gets a 402 Payment Required, signs a transaction, retries with proof of payment, and gets a response. That is the part of x402 everyone talks about.

This article is about the part nobody diagrams: the facilitator — the component that actually accepts the payment and settles it with the person running the API. If you are building a paid agent API, the facilitator is the thing you are really choosing. Everything else is plumbing around it.

The three roles in an x402 exchange

The spec splits a paid call into three parties, and the split matters more than the protocol version:

Client — the agent. It wants a resource and has a wallet.
Resource server — the API. It has the resource and wants to be paid before releasing it.
Facilitator — the entity that takes the money on the resource server's behalf.

When a resource server returns 402, the challenge says who to pay (payTo) and how much. In a direct setup the payTo is the resource server's own address. In a facilitated setup, payTo is the facilitator's address, and the facilitator later forwards the settlement to the resource server.

That indirection is the entire point. The facilitator absorbs everything the resource server does not want to run itself: wallet custody, chain connectivity, gas management, and the reconciliation of "who paid how much for what."

Why the facilitator exists at all

A resource server could just put its own address in payTo and watch the chain. Almost nobody does, for four reasons:

Gas is a tax on cents. Settling a $0.01 call on a chain with a $0.10 fee is a 10x loss. The facilitator exists to batch, hold off-chain, or absorb gas so per-call economics survive.
One address per chain is painful. An API that wants to accept USDC on five networks now runs five key pairs and five balance books. A facilitator collapses that into one settlement surface.
Reconciliation is the hard part. Payments arrive as unstructured chain transactions. Someone has to map "0.003 USDC from 0x9f... at block 12M" onto "agent X bought tool Y for $0.003." That mapping is a database, not a protocol feature.
Trust is easier to outsource. A buyer that does not know your API will still pay a facilitator it recognizes. The facilitator is a reputational bridge.

The settlement chain, end to end

Here is the chain a cent actually travels, from left to right:

agent wallet → facilitator (payTo) → [batch/ledger] → facilitator payout wallet
                                                          ↓
                                              resource server's wallet

The 402 challenge is the front of this chain. The back half — facilitator internal ledger, payout batching, on-chain settlement — is not standardized. That is the interesting part: x402 standardizes the challenge, not the settlement. Two facilitators can be 100% spec-compatible and settle completely differently.

The design axes that actually distinguish facilitators

If you are evaluating (or building) a facilitator, these four axes matter more than the brand name.

1. Gasless vs. gas-bearing

A gasless facilitator pays the chain fees itself and marks it up (or subsidizes it). A gas-bearing facilitator passes gas through to the buyer. Gasless is a better developer experience and a worse margin; the choice is really "who eats the fee on a $0.01 call."

2. Pass-through vs. credit/reseller

A pass-through facilitator moves money from buyer to seller 1:1 minus a fee. A reseller facilitator does not move the buyer's money at all — it meters its own credits to the agent and pays the resource server separately. The agent never holds a direct relationship with the resource server. Reseller models are attractive because they abstract the chain away entirely, but they concentrate trust in the facilitator.

3. Single-rail vs. multi-rail

A single-rail facilitator settles on one chain (usually one stablecoin on one L2). A multi-rail facilitator accepts payment on several and settles on whichever the resource server prefers. Multi-rail is more capital-efficient for buyers but multiplies the reconciliation problem.

4. Hosted vs. self-hosted

A hosted facilitator is a service you point payTo at. A self-hosted facilitator is software you run next to your API. Self-hosted keeps custody and margin, at the cost of running a wallet and a reconciliation pipeline you were probably trying to avoid.

What this means for the protocol's future

The existence of a second HTTP-402 standard — MPP, from Stripe, Tempo, and Visa, deliberately backward-compatible with x402 — is a signal, not a fight. When a payment rail is being built as infrastructure by card networks, the rails are becoming a commodity. The value is migrating to the layer above the rail: who holds the relationship with the buyer, who does the reconciliation, who vouches for the seller.

That layer is the facilitator. The next few years of agent payments will be decided less by which protocol wins and more by how the facilitator role shakes out — whether it consolidates into a few big settlement networks or fragments into thousands of self-hosted gateways. Watch that, not the version numbers.

This is a technical explainer, not product commentary. The roles and flows described are part of the public x402 specification and its ecosystem; organizations are named only where they are the authors of a public specification.

MCP 2026-07-28 Went Stateless — and Still Has No Way to Charge for a Call

minia2a — Thu, 27 Aug 2026 09:06:55 +0000

MCP 2026-07-28 Went Stateless — and Still Has No Way to Charge for a Call

The Model Context Protocol's July 28 revision is the biggest architectural change since launch. It is not an incremental bump — it's a rewrite of the protocol's core assumption. And yet the one thing server authors keep asking for — a way to get paid — is still, deliberately, not there.

This post is two things: an accurate map of what actually changed (a lot of the summaries floating around get it wrong), and a concrete pattern for the payment gap, using HTTP 402.

What actually shipped: the protocol went stateless

The headline is statelessness. Prior revisions assumed a long-lived session: client calls initialize, server returns a session ID, both sides keep per-session state. The 2026-07-28 revision removes that assumption.

Change	What it means
`initialize` handshake removed	No session ID. Each request carries its own version + capabilities in `_meta.io.modelcontextprotocol/{protocolVersion, clientInfo, clientCapabilities}`
New `server/discover` RPC	Clients learn supported versions and capabilities up front; SDKs fall back to legacy `initialize` for old servers
Stateless-only Streamable HTTP	The `streamable` transport accepts 2026-07-28 only in stateless mode; stateful sessions negotiate down to 2025-11-25
Removed methods	`ping`, `logging/setLevel`, `resources/subscribe`, `resources/unsubscribe`, and SSE resumability (`Last-Event-ID`, standalone GET) are gone — they reject with `MethodNotFound`
MRTR (SEP-2322)	Multi-round-trip requests replace holding an SSE stream open. A server returns `InputRequiredResult` (`resultType: "inputRequired"`) with an opaque `requestState`; the client re-issues the request with `inputResponses` + that same `requestState`. Any replica can pick up the retry — that's the point
Header routing (SEP-2243)	Every Streamable HTTP POST carries `Mcp-Method` (mirroring the JSON-RPC method), plus `Mcp-Name` for `tools/call`, `resources/read`, `prompts/get`. Intermediaries can route without parsing bodies
Cacheable lists (SEP-2549)	`tools/list`, `prompts/list`, `resources/list` carry `ttlMs` and `cacheScope` freshness hints
Real HTTP errors	Transport failures return actual status codes instead of HTTP 200 with an in-body JSON-RPC error: unknown method → 404, unsupported version → 400 (`-32022`), missing capability → `-32021`

Equally important is what got deprecated: roots, sampling, and logging (SEP-2577), plus the legacy HTTP+SSE transport and Dynamic Client Registration (replaced by Client ID Metadata Documents). A lot of the "MCP added OAuth DCR and roots!" summaries have it exactly backwards — those were the old model, now on the way out.

The through-line: the protocol is being rebuilt so that any request can be routed to any replica, with no shared session state. That's a property you want if you're running an MCP gateway, a load balancer, or a fleet of servers behind one endpoint.

What did not change: there's still no payment layer

Search the spec for a way to charge for a tools/call and you won't find one. This is a deliberate design decision, not an omission. MCP solves discovery (what tools exist) and capability (what they do). Commerce — who owes whom — is a different protocol's job, and the maintainers have been consistent that it's out of scope.

The reasoning is sound. A tool-integration protocol should not bake in a pricing model, a settlement rail, or a currency. Those things rot fast. But the decision leaves a concrete problem for anyone running a non-free MCP server: when an agent calls your tool, how do you get paid?

The ecosystem's answer is converging on HTTP 402 Payment Required — the status code that's been reserved since 1997 and is finally being used for its intended purpose. The standard that operationalizes it is x402, which is now under the Linux Foundation.

How HTTP 402 gates an MCP server

The mechanism is refreshingly small. When a request arrives without proof of payment, you return 402 with payment instructions in the WWW-Authenticate header. The caller pays, retries with proof, and you verify. One request cycle, no account system.

POST /mcp HTTP/1.1
Content-Type: application/json
Mcp-Method: tools/call
Mcp-Name: lookup_contract

HTTP/1.1 402 Payment Required
WWW-Authenticate: Payment version="1.0", asset="USDC", chain="base", receiver="0x…", price="0.01"
Content-Type: application/json

{"error": "payment required", "price": "0.01 USDC"}

A working Express middleware for the gate — placed before your tools/call handler:

app.use('/mcp', async (req, res, next) => {
  const isToolCall = req.headers['mcp-method'] === 'tools/call';
  if (!isToolCall) return next();

  const proof = req.headers['x-payment-proof'];

  if (!proof) {
    res.status(402).set({
      'WWW-Authenticate':
        'Payment version="1.0", asset="USDC", chain="base", ' +
        'receiver="<YOUR-RECEIVER>", price="0.01"',
    });
    return res.json({ error: 'payment required', price: '0.01 USDC' });
  }

  // Verify the proof against the facilitator that settled it.
  const ok = await verifyPayment(proof);
  if (!ok) return res.status(402).json({ error: 'payment invalid' });

  next();
});

Two details worth getting right in production:

Mcp-Method: tools/call is now a routing header (SEP-2243). You can gate only paid tools by matching on it, rather than intercepting every POST and inspecting the JSON-RPC body. Free tools (Mcp-Method: tools/list, etc.) pass straight through.
Verification is delegated to a facilitator. You don't need to parse the chain or manage USDC custody yourself. The payment proof is a receipt a facilitator issued; you POST it back to the facilitator's verify endpoint and get a yes/no. Your server stays a stateless replica — which is exactly the property 2026-07-28 just worked to give you.

The stateless rewrite is a gift to paid endpoints

This is the part that connects the two halves. Payment gating and statelessness reinforce each other:

A 402 + retry pattern is naturally idempotent. If your server is a stateless replica, a client can hit any replica with the same paid request and get the same result. No session affinity to fight.
MRTR gives you requestState tokens, so a multi-step paid interaction (request → pay → confirm → result) can span replicas without sticky sessions.
Real HTTP status codes mean a 402 is a 402, not a JSON-RPC error wrapped in HTTP 200. Agents and gateways can branch on it cheaply.

If you're building a non-free MCP server right now, the stateless model removes most of the infrastructure reasons you couldn't charge before.

The other paths (and why they're complementary, not competitors)

HTTP 402 is not the only answer, and it's worth knowing the map:

MPP (Machine Payments Protocol) — a second standard (Stripe + Tempo + Visa) that also uses HTTP 402 and adds session/subscription semantics on top. Backward-compatible with x402 at the 402-challenge level.
MCP Billing Spec v1 — a community draft (noui.bot) that layers billing metadata over MCP's _meta namespace, closer to the tool protocol itself.
AWS AgentCore — wraps MCP servers behind a gateway that adds auth and metering; payment is handled by the platform, not the server.

None of these are in the MCP core spec, and none of them should be. The clean split — MCP for tools, 402 for payment, a facilitator for settlement — is the shape that's actually stabilizing.

Bottom line

MCP 2026-07-28 is a protocol-level bet that agents will talk to stateless fleets of tools, not stateful single servers. It removed the session assumption, standardized routing and multi-round-trip interaction, and got rid of the things that tied a server to a single machine.

It did not add payments — and that's correct. The payment layer lives one status code below the tool protocol. If you run an MCP server that should earn money, the path is: return 402 with payment instructions, verify the receipt through a facilitator, and let the stateless architecture you're now building on do the rest.

The Most-Sampled Endpoints Have Zero Paid Calls

minia2a — Tue, 25 Aug 2026 16:14:07 +0000

Trial counts are the wrong metric. Every API marketplace reports them because they look like demand, but at the endpoint level, the number of free samples and the number of paid calls barely correlate.

I pulled the per-endpoint numbers from a live pay-per-call marketplace for AI agents and found the two most-sampled endpoints — over 4,700 trials each — have been paid for zero times. Meanwhile the endpoints that actually earn money are mostly the boring ones nobody leads a pitch with.

Trial volume ≠ demand

Sort every endpoint by free trials consumed, and the top of the list looks like a healthy business:

Endpoint	Category	Trials	Paid calls
Gas	crypto	4,715	0
Captcha Solve	specialized	4,626	0
Recall	ai	3,867	36
Time	utility	1,652	40
Find	ai	1,629	5
Polymarket	finance	1,240	0

The top two rows are pure samples: thousands of free calls, not a single paid one. The trial counter inflates; the ledger doesn't move. Reading "4,700 trials" as "4,700 units of demand" is reading a number that has nothing to do with money.

What actually gets paid

Sort by real paid calls instead, and the picture inverts:

Endpoint	Category	Paid calls	Trials
Time	utility	40	1,652
Recall	ai	36	3,867
Token Security	security	14	186
Domain Intel	web	10	60
Wallet	identity	8	63
Crypto Price	crypto	8	35
Smart Contract Audit	contract-audit	4	0 (no trial)

The paid cluster is utility + security/audit + web/domain intel. And the last row is the interesting one: the audit endpoint offers no free trial at all, yet it's in the top tier of earners.

Sampling vs. buying are different behaviors

The split makes sense once you see them as two different behaviors:

Sampling is free and reflexive. An agent will trial gas prices or a captcha solver because it can, not because it needs to pay for them — both are trivial to self-serve or find free elsewhere.
Buying only happens when the endpoint does a job the agent can't do for itself: verify a token, audit a contract, resolve domain intelligence.

So free samples pile up on the trivially-replaceable endpoints, and money goes to the hard-to-replace ones. Trial volume is inversely correlated with paid conversion — not because trials are bad, but because what gets sampled freely and what is worth paying for are almost disjoint sets.

The honest metric is paid calls per endpoint, not trials. A design that hands out unlimited free sampling produces a flattering trial counter and an empty ledger.

What this means for trial design

If the goal is real usage (not demo theater), the trial allowance should be tight enough that the trial counter means something: a small shared allowance gets a caller to the moment of "do I pay for this?" without letting the demo counter masquerade as revenue.

The endpoints that convert are the ones where the free sample ends and a real job begins. Everything else is just traffic.

Data from the live service catalog of minia2a.uk, pulled August 25, 2026. "Paid calls" counts real pay-per-call usage, not the free trial allowance.

Agents are starting to pay to be checked before they act

minia2a — Sun, 23 Aug 2026 23:03:09 +0000

Agents are starting to pay to be checked before they act

The first generation of agent spending was "pay to fetch" — an agent pays a few cents to pull a price, scrape a page, or run a query. That's a solved problem now.

The second generation is starting to show up, and it's a different primitive entirely: pay a third party to validate a high-stakes action before you commit to it.

I track a public index of pay-per-call machine endpoints. On August 23 I pulled the full thing — 15,297 listings across 1,613 hosts — and compared it to a baseline two days earlier. The churn was the usual long tail of ephemeral tunnels and single-endpoint demos. But among the genuinely new operators, three independent hosts — nobody coordinating, all in the same window — converged on the same product: pre-flight validation.

Three flavors of "check before you commit"

Outbound-payment preflight — check a payout destination and amount for changed recipients, duplicates, and policy breaches before authorizing. One check per payment, stateless; a cent beats a wrong transfer.
SQL preflight — check a query against a Postgres schema before execution: destructive writes, unsafe changes. Agents are increasingly the ones writing the SQL; a guardrail is worth more than the rollback.
Unsigned-transaction preflight — simulate an unsigned transaction (eth_call + gas estimate) before signing and broadcasting. Catches a revert before gas is spent and before state changes.

I probed the cluster directly rather than trusting the listings: the payment-gated endpoints return live 402 payment challenges to a POST, meaning these are working products charging today, not listing stubs. That's the difference between "someone thought of this" and "someone is charging for it."

The industrial edge: bounded validation jobs

The most striking new entrant isn't crypto at all. One host published sixty endpoints under a buyer-jobs schema, each a bounded validation task: validate a robot trajectory's timing, check closed-loop stability, tune a controller within supplied limits, verify collision constraints, compare state estimators. The same host lists quantum jobs — provider-readiness checks, execution-plan selection, circuit compilation.

Every description uses the same word: bounded. The caller supplies the limits; the service checks the input against them. It's validation as a commodity — deterministic, cheap, and only needed at the moment a decision hangs on it.

Why validation fits pay-per-call

Validation has exactly the properties a micropayment rail rewards:

Small — a preflight check is a few hundred bytes in, a yes/no or a bounded report out.
Stateless — each check is independent; no subscription, no retained state.
High downside — the thing being checked (a payment, a signed transaction, a deploy) is expensive to get wrong, so a cent's worth of checking is a rational purchase.
Not self-certifiable — an autonomous agent can verify data, but it can't verify its own judgment about a high-stakes action. Validation is the one thing it genuinely has to outsource.

The honest caveat

This is an emerging category, not an established market. The validation listings are new, and their 30-day usage sits near the floor of one call — the listing-time probe, not repeat demand. The demand head — the endpoints agents actually pay for today — is still oracle data, fresh social data, search, and enrichment.

But a category doesn't need to be big to be real. Three uncoordinated operators arriving at the same primitive in the same week — one of them already live and payment-gated — is how new layers form. The first act was "pay to fetch." The second act is shaping up to be "pay to verify."

If you're building an agent that moves money, writes state, or signs transactions, watch this space — the pre-flight check you're hand-rolling today may already be a commodity someone is charging a cent for.

Cross-posted from minia2a.uk. Data from a full pull of a public pay-per-call discovery index on 2026-08-23.

The Agent-Payments Stack Just Went Full-Stack

minia2a — Sun, 23 Aug 2026 11:37:25 +0000

For the last few months, the agent-payments market looked like a layer cake where every layer had a different owner. One team did settlement. Another did wallets. Another did gateway. Another did discovery. Nobody owned more than one slice.

That changed this week. A single operator surfaced in the x402 discovery stream that ships four layers at once — an agent wallet, card issuing, a self-serve payment gateway, and settlement — plus a trading surface on top. The stack is consolidating, and the consolidation tells you something important about where this market is headed.

The stack, before this week

Strip the jargon away and agent payments decompose into six layers:

Layer	What it does	Recent shape
Protocol	How a price is attached to a request	x402 (HTTP 402 + payment metadata), MPP
Settlement	How the money actually moves	USDC on Base/other chains; gas-free nanopayment primitives in testnet
Wallet	Where an agent holds funds	Agent accounts with spending controls
Credit / issuing	Fiat rails an agent can spend through	Card issuing on digital-asset collateral
Gateway / facilitator	Turns an existing API into a paid endpoint	No-code wrappers, OpenAPI import
Discovery	How an agent finds an endpoint to pay	Marketplaces and catalogs

Until now these were mostly separate companies. The protocol work lived at foundations. Settlement lived at stablecoin infra. Wallets were one thing, gateways another, discovery a third. Each layer was a point-tool.

What surfaced this week

This week's x402 discovery sweep — a daily crawl of a public x402 resource directory — surfaced an operator that collapses four of those layers into one product:

A wallet for agents — an account an agent can use to pay, earn, and invest across cards, bank accounts, and crypto, with programmatic spending controls (daily budget, per-transaction limit, an allow-list of approved domains).
A card. This is the new primitive. The operator advertises a Visa-network credit card issued by a Visa principal member, collateralized by digital assets — accepted anywhere Visa is accepted, and separate from the crypto wallet. It's the first time I've seen an agent-facing card paired with a wallet and a gateway in one product.
A self-serve gateway — paste your API's base URL and auth, set per-endpoint pricing (flat, dynamic, or session-based), and publish. Sellers get a subdomain per protocol (your-service.x402.vendor.com and your-service.mpp.vendor.com). OpenAPI bulk-import, session billing with escrow, and an MCP surface so an agent can create endpoints itself.
Dual-rail settlement — x402 and MPP behind one gateway, so a seller collects USDC either way.

And the tell that this is real rather than a landing page: one of its gateway-hosted endpoints — a third-party screenshot API wrapped behind the vendor's gateway — already showed up in the public discovery directory. The no-code gateway is onboarding supply, and that supply is flowing into public discovery.

The layer cake is collapsing. Full-stack operators will absorb the single-purpose point-tools — and the layer that stays scarce is discovery.

Why the card matters more than it looks

The wallet and the gateway are interesting. The card is the signal.

An agent wallet that holds USDC can only spend where x402 (or a handful of other crypto rails) is accepted. A Visa-network card can spend anywhere Visa is accepted, backed by digital-asset collateral that sits on the operator's ledger. That's a fiat on-ramp for agents — it turns "an agent can pay for x402 endpoints" into "an agent can pay for anything," with the crypto rails doing settlement underneath.

For the demand side of the agent economy, that's the missing piece. The honest bottleneck in this market has never been the rails — it's been demand generation: getting real agents to actually pay for a call. A card makes an agent a first-class payer in the fiat economy, not just the crypto one.

What consolidation means for builders

If full-stack operators absorb wallets, cards, gateways, and settlement, then the layer a single-purpose team can still win is discovery and trust — the market layer where an agent figures out which of thousands of pay-per-call endpoints is real, what it costs, and whether it will actually answer.

When the rails, the wallets, the cards, and the gateways all consolidate into full-stack platforms, the scarce resource isn't "who can move a micropayment." It's "who can tell an agent which endpoint to trust with that micropayment."

Method note: the operator described here is unnamed deliberately — this is a pattern analysis, not a review of any single company. Observations come from the public x402 discovery directory and the operator's own public site.

x402 Did ~14M Agent Transfers in 30 Days. The Rails Are Solved — Discovery Isn’t.

minia2a — Fri, 21 Aug 2026 15:27:39 +0000

For a year the open question about machine-to-machine payments wasn't how — the x402 standard (HTTP 402 + USDC) had an answer — but whether anyone would actually do it. Every skeptical take boiled down to the same line: "agents don't have wallets, and they don't pay for APIs."

That question just got a number. Token Terminal reports ~14 million AI agent transfers on x402 rails in the trailing 30 days, published August 19, 2026: ~7.3M on Base, ~5.6M on Polygon, with USDC settling nearly all of it.

Fourteen million is no longer an early-adopter anecdote. It's volume.

Where the volume actually is

Rail	30-day transfers
Base	~7.3M
Polygon	~5.6M
Combined	~12.9M of ~14M

Both are first-party rails of the same protocol steward, and the transfers run through its own agent ecosystems. This is not 14 million agents wandering the open web, each discovering a new pay-per-call API and settling on-chain. It's a concentrated garden where the rails, the clients, and the endpoints were built together. That's the right way to bootstrap a standard — but it tells you what the 14M proves and what it doesn't.

What the 14M proves: the rails are done

The rails debate is over. Machines will pay machines, at scale, in USDC, over HTTP 402. The settlement asset is settled (USDC, not a dozen tokens), and the tooling is real — this month also brought AWS Bedrock AgentCore payments to GA (x402 + USDC with spending limits) and enterprise USDC collection for agent payments. When the hyperscaler and the protocol steward both ship agent-payment rails in the same week, "will agents pay" stops being a research question.

The binding constraint moved. It is now discovery: how does an agent that already knows how to pay x402 find the other things worth paying for — the long tail outside the first-party garden?

What the 14M doesn't prove: the open long tail has demand

I can report this from the inside, and it's uncomfortable: the open long tail is still near zero. Our own open x402 catalog — 1,662 pay-per-call services — has recorded 90 real on-chain settlements totaling $11.52 USDC. That's the honest number, and it is five orders of magnitude away from the 14M flowing through the first-party rails.

The gap isn't proof that open marketplaces fail. It's proof that the 14M agents were never given a reason — or a path — to buy anything outside the garden.

Two honest reasons:

1. The traffic is rails-bound, not discovery-bound. An agent built on the steward's SDK pays the steward's endpoints. Nothing in that flow surfaces a cheaper CAPTCHA solver or a niche data feed.

2. The open long tail is invisible to the machines that would pay it. Most third-party x402 services are a repo and a README. An agent can't pay for a service it can't find, and it can't find a service that never published itself in a form agents read.

Discovery is the whole game now

If the rails are commoditizing, the durable position isn't "another payment rail" — it's the index. Three properties matter:

Open, not first-party. Any publisher can list a real endpoint. The long tail is the point.
Trial-first. An agent should verify a service answers correctly before it pays. Pay-per-call, but verify-first.
Machine-readable. A .well-known/x402 record, a JSON directory, an MCP server. Discovery only counts if a machine can do it without a human clicking around.

The 14M didn't change what we build. It changed what's worth arguing about. Nobody needs convincing that agent payments are a thing — the 14M agents already exist and already pay. The work now is making sure that when one of them wants something the first-party garden doesn't sell, there's an open index it can ask.

The rails are solved. Discovery is the next bottleneck, and the next bottleneck is the opportunity.

Your Agent's Trial Call Needs a Signature — and the Service ID Isn't What You Think

minia2a — Wed, 19 Aug 2026 04:29:39 +0000

An agent registers a self-custody wallet, appends ?wallet=0x… to an endpoint the way the quickstart shows — and gets HTTP 402. Nothing is down. The call simply isn't signed, and an unsigned call never reaches the wallet's own trial bucket.

Everything below was measured against a live x402 gateway on August 19, 2026. The pass/fail marks are real responses, not documentation.

Two buckets, not one

Anonymous — 15 calls keyed to your egress IP, shared across the whole catalog.
Registered wallet — a further 15 calls keyed to the wallet itself, reachable only by signing each call.

They're genuinely independent. My measurements came from a host whose anonymous bucket was already at 0/15: unsigned calls returned 402, and signed calls from the same host in the same second returned 200. If your agents run behind shared cloud egress — Lambda, CI runners, a Workers deploy where thousands of tenants share an IP — that's the difference between "free tier exhausted before I started" and "my wallet carries its own allowance wherever it runs."

The message

minia2a trial:<wallet>:<serviceId>:<unixSeconds>

Sign with EIP-191 (personal_sign), send X-Wallet-Signature + X-Trial-Timestamp, put the wallet in the query string. Timestamp is unix seconds, ±5 minutes.

The detail that costs an afternoon

You're standing at the URL https://minia2a.uk/x402/time. The obvious reading of serviceId is time. It isn't — it's the catalog id, x402-time.

Four candidates, same wallet, same endpoint, same minute:

Signed as	Result
`x402-time`	200 — `x-trial-mode: wallet`, `x-trial-remaining: 14`
`time`	402
`/x402/time`	402
`https://minia2a.uk/x402/time`	402

Confirmed on a second endpoint: gas → 402, x402-gas → 200.

Here's why this is worse than an ordinary gotcha. A wrong service ID and a forged signature produce byte-identical responses — both a 402 with trial.mode:"none". An agent debugging this has no signal telling it whether its crypto is wrong, its clock is wrong, its registration failed, or it merely used the wrong noun. So it goes and rewrites the signing code, which was fine all along.

The general lesson, for anyone designing a payment challenge

A 402 body that names a variable — "sign wallet:service:ts" — is not machine-readable. The client has to guess what service expands to, and every wrong guess looks exactly like an auth failure. Emit the literal string, or name the field it comes from.

The cost of that ambiguity lands entirely on the caller, which in the agent economy means it lands on software that cannot file a bug report. Humans work around ambiguous errors by asking someone. Agents retry, exhaust a budget, and give up — and you never hear about it.

Python that works

import time, requests
from eth_account import Account
from eth_account.messages import encode_defunct

acct, sid = Account.from_key(PRIVATE_KEY), "x402-time"
ts = str(int(time.time()))
sig = acct.sign_message(
    encode_defunct(text=f"minia2a trial:{acct.address}:{sid}:{ts}")
).signature.hex()

r = requests.get(f"https://minia2a.uk/x402/time?wallet={acct.address}",
                 headers={"X-Wallet-Signature": sig, "X-Trial-Timestamp": ts})
print(r.status_code, r.headers.get("x-trial-mode"), r.headers.get("x-trial-remaining"))

Don't infer which bucket paid — read the header

x-trial-mode: wallet — signature accepted.
x-trial-mode: ip — you're on the anonymous bucket; something in the signed message was wrong and the call quietly fell back.

That ip case is the quiet one: a 200 doesn't prove your signing works, it may just prove your IP still had calls left. Test from an exhausted IP, or watch the header. Those are the only two honest checks.

Full write-up with curl/CLI/MCP recipes: minia2a.uk/blog/x402-signed-trial-calls-august-2026

Every Number On Our Site Was Typed Once

minia2a — Wed, 19 Aug 2026 00:57:55 +0000

Our homepage said this:

Your agents discover, pay, and consume APIs autonomously in USDC on Base.
300+ services across crypto, web, AI, and data.

The catalog held 1,645. That sentence is the one line on the page whose entire job is to convey scale, and it was understating by more than five times.

The same bug ran the other way too. An internal dashboard page advertised 1,700 services — a number the catalog has never actually reached. And the worst instance was in a file no human reads: the .well-known record that LLM crawlers ingest described us as "272 agent-callable APIs", with a metadata block frozen three weeks earlier. When someone asks a model how big that directory is, 272 is the number it has to work with.

Three directions, one cause

Under-claiming, over-claiming, and telling a crawler something six times too small look like three different mistakes. They are one: a number was typed into a file, the thing it described kept moving, and nothing ever reconnected them.

That's worth naming precisely, because it isn't a content problem:

A count in your copy is a cached API response with no expiry and no owner.

Every marketing page, every .well-known record, every llms.txt is a client of your own stats endpoint that somebody hand-resolved once, months ago.

The test that finds these: grep your site for digits followed by the words you use for your own inventory — services, endpoints, APIs, users — and diff every hit against the live value. We found 17 files. One was current.

Fixing the numbers is the wrong fix

We'd already fixed the numbers once. A hand-patching pass the day before had walked straight past two 272 strings in the very file that feeds LLM catalogs — because hand-patching a list of files is exactly the kind of job that silently drops an item.

So we replaced it in two shapes.

Pages resolve at render time. A component already existed that rewrites any <span data-stat="services"> from /api/stats on load. Eleven pages used it; the pages with wrong numbers didn't. The counts became spans, the missing pages got the script tag, and the value written into the HTML is the current live one — so a crawler or a JS-less reader still sees today's figure.

Static records get rewritten daily, floored downward. JSON records can't run JavaScript, so a cron rewrites them from live stats. One rule matters more than the rest:

Prose counts floor, never round up. 1,645 publishes as "1,600+", never "1,700".

A floored claim is one you can always defend. A rounded-up one is a small lie that grows every time your catalog dips.

Test the alarm, not just the fix

Self-correcting scripts have a specific failure mode: they die quietly and everything looks fine. So the verification suite got a check comparing published claims against live — a prose count must land in (live − 100, live]. Below that, the record stopped tracking. Above it, we're over-claiming. Both fail.

Then the part that's easy to skip. We put the old number back and watched it fail:

FAIL  published counts: /.well-known/ai-catalog.json: claims 272, live 1645

…ran the refresher, watched it heal, re-ran the suite green. A guard you've only ever seen pass is a guard you haven't tested.

The near-miss worth writing down

One page compares marketplaces. A single table row holds our count, one competitor's 5,000 registered agents, and another's 845 paid APIs.

The general rule — "a number followed by registered agents is our wallet count" — is correct on nine pages and catastrophically wrong on the tenth. The dry run said exactly what it planned to do:

L124: 5,000 -> <span data-stat="wallets">775</span>

That edit would have republished a competitor's figure as ours. Not a stale number — a fabricated one, about somebody else's business. It never shipped, because the run was a dry run and the context got read before the write.

The fix: comparison pages get a literal-scoped rule that touches only our own value and leaves every other number alone. The lesson is narrower than "be careful":

An automation that rewrites claims has to know which claims are yours to rewrite. On a page that describes other people, pattern-matching prose is not a safe way to decide.

If you run an agent-facing service

Agents don't sanity-check your numbers the way a human skimming a landing page does. They read llms.txt, .well-known records, and OpenAPI specs literally and act on what they find.

One source of truth. Every published count resolves from the same endpoint your dashboard reads. If a number in your copy can't name its source, it doesn't have one.
Floor, don't round. Publishing less than you have costs nothing you can measure. Publishing more costs the thing that's hard to rebuild.
Plant the old wrong value and watch the check fail. Otherwise you have a dashboard, not a guard.

Full write-up with the exact regex traps and guardrails: Every Number On Our Site Was Typed Once

What Our Own Discovery Records Were Telling Agents

minia2a — Wed, 19 Aug 2026 00:11:46 +0000

A discovery record is an API contract that nothing validates. Your tests exercise your API; nothing exercises the JSON file that tells strangers what your API costs.

We run an x402 resource server, and we finally diffed every machine-readable record we publish against the live 402 responses those records describe. A third of our published prices were 100×–500× below what the gateway actually charges. The published payout address was one we no longer settle to. Our OpenAPI spec pointed buyers at a URL that served the same data for free.

None of this showed up as an outage. Every record returned HTTP 200, well-formed JSON, on time. That's the whole problem with the discovery layer: a record that lies is indistinguishable from a record that works, right up until a buyer acts on it.

The crawler that chased single characters

The audit started with a log shape that made no sense. In one day, one IP requested /n 116 times, /s 87 times, /i 87, /e 87, then a long tail of single-character paths at 58 and 29 hits. 1,189 requests, all 404, all one character long.

The counts are the tell — they're all multiples of 29: 4×29, 3×29, 2×29, 1×29. That's a character-frequency histogram: some string, iterated 29 times. Solving for a string with four n, three each of s/i/e, two each of t/o/l/k/a/w/2/-, one each of x/v/u/r/p/m/j/h/c/4/0 gives exactly one answer:

https://minia2a.uk/.well-known/x402-service.json

(/ and . are absent from the histogram because those requests normalize or redirect instead of 404 — itself a confirmation.)

A client was iterating that URL as if it were a list. And it had a good reason to. We published the field name endpoints in two sibling records:

Record	`endpoints` is…
`/.well-known/x402-service.json`	an array of 82 endpoint objects
`/.well-known/x402`	a bare URL string

Any consumer that learned the field from the first record and then read the second gets a string where it expected a collection. In Python or JavaScript, iterating a string doesn't throw — it quietly yields characters. So the crawler fetched /h, /t, /t, /p, /s, and never once reached our catalog.

We had been reading that as crawler noise. It was our schema.

A third of the prices were fiction

Regenerating one record from the other meant actually reading the catalog, which surfaced something worse: 33 of 82 entries had a published price that disagreed with the live 402.

Our gas-price endpoint was published at 0.005 USDC. Its actual challenge:

"accepts": [{
  "amount": "500000",   // 6-decimal USDC = 0.5, not 0.005
  "asset":  "0x8335...2913",
  "payTo":  "0xf16F0882...",
  "scheme": "exact"
}]

A hundred times the advertised number. Across the catalog the ratios clustered at 100× (20 entries), 500× (6), 50× (2), plus one each at 300×, 10×, 5×.

Under-pricing sounds like the harmless direction to be wrong in. It isn't. An agent that budgets from your catalog and then meets a paywall demanding 100× more doesn't negotiate — it fails the call or silently overpays. Either way the number you published wasn't a price, it was a guess someone made once and nobody re-checked.

The same audit found the catalog's payment.address naming a wallet the gateway no longer settles to. All 82 live 402s named the current address; the published record named a different one. USDC sent to the address we advertised would not have been credited.

The spec that routed buyers around our own paywall

Most of our services are gateway-proxied, so the published path is ours and the 402 happens at our edge. A handful are seller-hosted: the seller runs the API on their own infrastructure and registers it with us.

For those, our generator published the seller's upstream path, with an operation-level servers override pointing at the seller's host. Legal OpenAPI. Wrong twice over:

It 404s for most tooling. Operation-level servers overrides are widely ignored; plenty of clients build the URL from the root server and land on a path our domain never served. 16 such 404s in one day from a single indexer.
It bypasses the paywall entirely. We fetched one of those upstreams directly: 200, complete dataset, no 402 challenge at all. Our spec printed a price next to a URL that serves the data free, never touches our gateway, and never settles.

We were advertising our own bypass. Every one of those services answers a proper 402 at the gateway's proxy route, so that's what we publish now.

Four records described an auth scheme we don't implement

Four records described agent registration as Ed25519 keypair signing. The gateway verifies EIP-191 personal_sign over an exact message string. One of those records is aimed specifically at LLM and catalog ingestion, and its example query read "register my agent using my Ed25519 key" — feeding a nonexistent integration path to the systems most likely to repeat it verbatim.

Another named a registration endpoint that only answers GET. It returns a pointer to the real endpoint, which is sensible — but the record called the pointer the endpoint, so anything that POSTed where we said to POST got a 404.

Why none of it was caught

Every defect has the same shape: a claim about the system, stored outside the system, that nothing re-derives. Prices were copied into JSON when they were true. The payout address was correct when written. The Ed25519 description matched a design that changed. The type mismatch was two people reasonably naming two different things endpoints.

Static files don't rot on their own — they rot because the thing they describe moves. So the fix isn't "be more careful when editing JSON":

Derive from the 402, not from a cache. Price and payout address now come from the actual challenge response, because that's the number the buyer will be charged — not from an internal field that merely ought to agree with it.
One source, two records. The catalog is regenerated first; the summary record is rebuilt from it. Two files can't disagree about a type if only one is authored.
Probe over loopback. An earlier version of this audit probed from outside, rate-limited itself, and read its own 429s as "endpoint healthy" — hiding 71 genuinely dead links behind the throttle. Your own throttle is not a verdict about someone else's uptime.
Refuse to publish suspicious deltas. The corrector aborts if too many entries fail to resolve. A mass drop is far more likely to be an outage on your side than every seller delisting at once.

Test that your test can fail

This runs daily now and fails loudly on drift. But a check you've only watched pass proves nothing — a regex that matches nothing also reports zero mismatches. So we planted the old wrong price back into the input and confirmed:

handbook prices: x402-gas says 1c, charges 50c   →  FAIL

Then reverted. Two minutes, and it's the difference between a guard and a decoration.

Publishing a correction doesn't un-publish the old one

One last thing, because it changes what the fix is worth. A separate client has been calling five endpoint IDs that no longer exist, ~720 times a day, for a week — while re-fetching our now-corrected spec hundreds of times a day. The dead IDs are gone from everything we publish. It's still calling them.

Downstream consumers cache, merge, and hand-copy your records into their configs. Fixing the record fixes the next reader, not the current ones. Which is the real argument for validating discovery records continuously rather than carefully: every day a wrong record is live, some fraction of its readers commit that error to a config that outlives your fix.

Measured against a live x402 gateway on August 18–19, 2026. Request counts come from the gateway's own log; prices and payout addresses were read from live 402 challenge responses. The seller-hosted upstream that serves without a paywall is deliberately unnamed.

The Error Message an Agent Can't Act On

minia2a — Tue, 18 Aug 2026 21:54:05 +0000

Our programmatic registration endpoint returns two different HTTP 400s. One of them includes a working curl example, so a caller that hits it can repair itself. The other says verification failed without ever naming the thing to verify against, so a caller that hits it cannot.

Over seven days that endpoint took 232 calls and returned success four times.

The defect was not a missing field in our documentation — we checked, and the documented payload is complete. The defect was an error message with no recovery path in it.

What we measured

Yesterday we found that every documented path for publishing a service to our marketplace was broken. That prompted the obvious follow-up about the other side of the market: can a machine that reads only our docs register?

From the gateway log, August 12 10:31 through August 18 21:45 UTC, POST /api/v1/register-simple:

4 successes out of 232 calls — 171 × 400, 24 × 429, 24 × 404.

Two honest deductions before that number gets quoted anywhere. 41 of those failures were mine, from earlier testing against the same endpoint. Another 103 came from a single external indexer repeatedly trying to register itself. So this is not 228 lost customers and I won't present it as one.

It also shouldn't be confused with our registered-wallet count, which is 775. Most of those arrived through the browser flow, where a human clicks a MetaMask prompt. The 4-of-232 figure describes one specific path: the one an autonomous agent walks, with no human present.

The asymmetry

We sent seven payload variants and recorded what came back. Usefully, the endpoint validates the signature before it checks the per-IP limit — so a deliberately invalid signature can probe the contract with no possibility of creating a real account.

What we sent	What came back
Empty body / name only / no signature	400 `name, wallet and signature required` — plus a complete, copy-pasteable curl example
Signature over the wrong message, or garbage	400 `signature verification failed — prove you own this wallet by signing the message`
Correct, fully valid payload	429 `one free registration per IP`

Read the first two rows again. Both are 400s from the same endpoint, and they are not the same kind of object at all.

The first contains its own fix. A caller that receives it has, right there in the body, the exact shape of the request it should have sent. It can retry correctly without consulting anything.

The second is a dead end. It says the signature failed and instructs the caller to sign the message — but never says which message. The answer is the literal string minia2a register: <wallet>, and that string appears nowhere in the error. A caller holding a wallet and a willingness to sign has no way to discover what to sign. It can retry forever and never converge.

That's what makes it a machine-specific bug. A human who hits that error opens the docs, finds the signing message, and moves on — thirty seconds lost. An autonomous agent has no such move. The error body is its documentation, and this one contains nothing it can act on.

The test that generalizes: for any error your service returns to a machine, ask whether a caller that receives only that response can repair its next request. If it can't, the error is a defect — even when the status code is correct, the message is accurate, and the field really is invalid.

The second trap: advice that's right everywhere except where it matters

The other finding was in our own documentation, and it was worse, because it actively instructed agents to fail.

Our machine-readable docs listed status codes, including:

429 — rate limited. Back off; do not retry in a tight loop

Correct for every route we serve except one. On registration, a 429 means one free registration per IP, and that condition is permanent for that IP. It is not a retry-after. An agent following our advice is backing off and retrying a request that will never succeed, for as long as it stays running.

Agents on shared cloud egress hit this constantly, and it isn't their fault: Lambda, Cloudflare Workers, Railway, and CI runners share exit addresses, so the free grant for that address is routinely already claimed by someone else entirely.

This gets sharper on September 1, when anonymous trials end and registration becomes the only way in. A misleading 429 today is friction. After that date it's the front door.

We verified the recovery before documenting it

The honest advice for an agent that gets a 429 on registration is to stop trying to register — because registration was never required to use the marketplace. It buys the free credit grant. That's all it buys. Paying works without it.

Rather than assert that, we tested it — generate a wallet that has never touched the platform, call a paid endpoint with it:

$ # freshly generated, never registered
$ curl "https://minia2a.uk/x402/time?wallet=0x8837...7026&probe=1"
HTTP/2 402
{"accepts":[{"scheme":"exact","network":"eip155:8453",
  "asset":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "payTo":"0xf16F...4ECA","amount":"100000"}, ...]}

A payable challenge, two settlement rails, real payTo addresses. The unregistered wallet is a first-class customer.

What changed

The 429 semantics are documented across our three machine-readable surfaces, as a permanent per-IP condition with the payment path as the stated recovery — replacing the generic backoff advice.
The fix was applied to the generator, not the output. One of those files is rebuilt hourly from live state; editing the published copy would have looked correct for up to fifty-nine minutes and then quietly reverted. Worth checking, if you automate your own docs, which of your files are artifacts.
The claim is now a daily test. We already had a regression check asking whether a machine could publish using only the docs. It now also asserts that an unregistered wallet still receives a challenge carrying a real payTo. We tell agents they can skip registration and pay directly; if that ever stops being true, our documentation starts lying, and we'd rather hear it from a failing check than from an agent stuck in a loop.

What we did not change is the error message itself. Making the signature failure name its expected message — the way the missing-field error already names its curl example — is a gateway change, outside what we alter unilaterally. It's filed. Until it ships, the docs carry the string: minia2a register: <your-wallet>, EIP-191 personal_sign.

What this doesn't explain

It would be tidy to claim this accounts for our conversion gap. It doesn't. We've issued 388,219 free credits and seen 910 spent. Fixing a front door doesn't create demand behind it, and an agent that registers successfully still has to find something worth paying for. The registration path being broken is a real defect worth fixing on its own terms; it is not the explanation for everything downstream, and we've been wrong before by reaching for single causes.

The narrower claim: two sides of this market were failing for the same underlying reason, discovered a day apart. Sellers couldn't publish because our documentation described a nonexistent API. Buyers couldn't register programmatically because our error messages described a problem without describing its solution. Both are the same category of bug — information a human routes around and a machine cannot — and both were invisible in our metrics, because a 400 and a 429 are exactly what a healthy service returns to bad requests.

We Documented a Marketplace Nobody Could Join

minia2a — Tue, 18 Aug 2026 21:10:59 +0000

A developer filed an issue on one of our repos titled "Publisher docs and CLI disagree with live seller API." They had tried to list an API on our x402 marketplace, followed the published instructions, and got HTTP 400.

Our first instinct was that they had the wrong route. They claimed the seller endpoint was POST /api/register with header-based signature auth, which did not match what we believed our own API to be.

So we tested it against the live gateway instead of arguing from memory.

POST /api/register
  {"name":"...","endpoint":"https://...","priceCents":5,"wallet":"0x..."}
  X-Wallet-Signature: 0x...
  X-Signature-Ts: 1755...

→ {"error":"name, wallet and signature required"}

That is the buyer registration error. The endpoint ignored endpoint and priceCents entirely. We sent the identical request with the two signature headers removed and got a byte-for-byte identical response — proof the handler never reads those headers at all.

The reporter's conclusion about which route works was wrong. But their complaint was exactly right, and here is why they believed it: that route and that header scheme are what our own canonical agent guide told them to use.

Four surfaces, four different failures

Once we knew the canonical guide was wrong, we checked every document that describes publishing. Each was broken, and no two were broken the same way.

Document	What was wrong
`AGENTS.md` (canonical, linked everywhere)	Wrong route (a buyer alias), wrong field name (`priceCents` vs `price_cents`), two required fields missing, plus a documented header-auth scheme that is no longer honoured
`llms.txt`	Correct route, example omitted a required field → 400
`agent-cookbook.html`	Correct route, same missing field → 400
`mcp-x402.html`	Missing `endpoint` and `signature` (both required), wrong field name, invalid category value — four errors in one call

There was no working documented path. If you read our documentation and tried to sell an API on our marketplace, you could not do it.

The error message made it worse

The field everyone was missing is description, which must be at least 20 characters. Here is what the API returns for an empty request:

POST /api/v1/publish-service  {}
→ {"error":"name, endpoint, wallet and signature required"}

description is not in that list. It is enforced but not announced. A developer doing the sensible thing — reading the error and adding exactly the fields it names — still gets a 400, with a new error that finally mentions the real requirement.

This is the part I find most instructive. A wrong example is one problem. A wrong example plus an error message that under-reports the contract is a loop that punishes the exact debugging strategy a competent developer would use.

Why this matters more for agents than for humans

A human who hits a 400 has options. They read the error, try variations, search for someone with the same problem, check the HTML on another page, or email support. Humans route around bad documentation. It costs them time, and some fraction succeed anyway.

An agent does not do this. It reads AGENTS.md or llms.txt, constructs the call exactly as specified, gets a 400, and stops. If it retries, it retries the same wrong shape.

For an autonomous client, the documentation is the interface. A wrong llms.txt is not a docs bug — it is an outage that returns 200.

This is worth sitting with if you are building anything agent-facing. The ecosystem is investing heavily in machine-readable discovery: llms.txt, agent cards, .well-known manifests, OpenAPI specs. All of that infrastructure assumes the content is true. We had all of those files. Several were confidently describing an API that would reject you.

What the numbers looked like

Our catalog has 1,644 active services. Twelve are hosted outside our own infrastructure. The rest are ours.

The buyer side — whose documentation was correct throughout — has 775 registered wallets and has served 21,155 free trial calls.

I am not going to claim documentation is the sole cause of that asymmetry. Publishing an API is a bigger commitment than calling one, and this is an early market on both sides. But the simplest explanation for near-zero external supply is that the on-ramp returned an error to everyone who tried it, and we should have caught it long before a user did.

To be equally honest about the rest of the funnel, since it is the number that actually matters: those 21,155 trial calls correspond to 54 settled paid transactions and 3.522 USDC of real on-chain volume. Fixing the seller path does not fix that. Demand generation is a separate and harder problem.

What we changed

AGENTS.md — rewrote the publish section with the correct endpoint, full required-field list, and signing message. Explicitly marked the dead header-auth scheme as no longer honoured, so anyone who copied it earlier can tell why it stopped working.
llms.txt, cookbook, MCP guide — corrected every publish example and called out the undocumented description minimum where developers will be looking when they hit it.
llms-full.txt — a hand-written snapshot that had drifted, and was somehow shorter than the summary it was meant to expand. Now generated from the live catalog hourly, with the 402 example captured from a real challenge at generation time rather than written by hand.
CLI — it had no publish command at all; its register command is buyer-side, which is precisely the confusion the reporter hit. Added publish with client-side validation so a missing description fails immediately with a legible message.

One thing we did not fix: the catalog does not record an HTTP method, so a service published to be called with POST reads back indistinguishably from a GET service and generic clients call it with GET. That is a gateway change, not a docs one. Until it ships it is written down, and the CLI warns about it after a successful publish. Naming a known defect beats letting a publisher discover it from silent failures.

The general lesson

If you run anything agents are supposed to use autonomously, the test is not "is the documentation good." The test is: can a machine that reads only your documentation complete the task? That question has a yes-or-no answer, it can be checked automatically, and we were not checking it.

The fix that generalizes is not "write better docs." It is to stop hand-maintaining files that describe a system that changes. Our discovery surface now regenerates from live state on a schedule, with examples captured from real responses. Anything still hand-written is a snapshot, and every snapshot drifts from the moment it is written.

Ours drifted for weeks, in public, while telling agents exactly how to fail.

Determinism Is the Product: What a 26-Endpoint Catalog Reveals About What Agents Pay For

minia2a — Tue, 18 Aug 2026 18:27:05 +0000

A one-person studio just launched a catalog of 26 pay-per-call APIs for AI agents — and the single most instructive endpoint in it is a hash function. Not a model, not a data feed, not a "smart" anything. A deterministic sha256 wrapped in an x402 payment challenge.

The reason it exists is the thesis of the whole catalog: models generate strings that resemble valid cryptographic hashes but are not, and a wrong hash silently breaks webhook signature verification.

That one sentence captures what the agent economy is about to pay for — determinism, not abundance.

The 26-endpoint experiment

The catalog is _done, from One Scales — a solo builder shipping narrow, single-purpose APIs that machines call, not humans. Every endpoint is $0.01 per call, paid in USDC over x402 on Base or Solana, with no accounts and no API keys: an agent requests an endpoint, receives an HTTP 402 payment challenge, signs a microtransaction from its wallet, and gets the result. That is the entire on-ramp.

Look at what made the cut for those 26 slots:

Endpoint	Why an agent can't just do it itself
Hashing	LLMs hallucinate plausible-but-wrong hashes; webhook verification needs the real bytes.
DNS / WHOIS lookup	Deterministic resolution against live infrastructure, not a model's memory of a domain.
DMARC validation	Email deliverability and spoofing checks need actual record parsing.
OCR	Turning pixels into exact text — a perception task, not a generation task.
Screenshots / port scanning / sitemap extraction	Ground truth about a live page or host, fetched now, not reconstructed.

None of these are "data an LLM could guess." They are all verification against reality: producing the exact bytes, the exact record, the exact text. That is the common thread, and it is why they can charge at all.

The contrast that matters

The market is currently obsessed with catalog size — how many endpoints a marketplace lists. But a catalog with a thousand endpoints where almost none get called teaches less than 26 endpoints each built around a determinism gap. The unit of value is not "one more API"; it is "one more thing the model cannot reliably do itself."

This matches what the payment data already says. Keyrock's May 2026 report found 76% of AI agent payments sit below Visa's $0.30 fixed-fee floor — card rails are structurally incapable of settling a $0.01 hash lookup. Stablecoin micropayments are the only rail that fits, which is why every one of these deterministic endpoints settles in USDC. The pricing floor and the rail choice aren't separate decisions; they're the same decision.

Why we publish our own zeros

The honest version of this story includes the unflattering numbers. Our own marketplace is serving 817,324 total requests and 20,953 trial calls, against 86 on-chain transactions totaling 3.522 USDC. Most of those 817K requests are crawlers, validators, and quote-cachers — the same shelf-placement traffic every x402 endpoint absorbs. The trial volume is real adoption; the settlement volume is the honest state of an early market.

That gap is the signal. It says the scarce resource in machine-to-machine payments is not rails, not wallets, not discovery — it is things worth paying for. And the things worth paying for, as _done's 26 endpoints show, are the ones that close a determinism gap: the hash, the DNS record, the DMARC check, the OCR'd receipt. Build one of those, price it at a penny, and you have a product. List a thousand guesses and you have a museum.

The takeaway: don't optimize for how many endpoints you can surface — optimize for how many things you can make exactly right that a model can't. Determinism is the product. Abundance is the noise.

Cross-posted from minia2a.uk. minia2a is an open marketplace for x402 pay-per-call endpoints — 15 free trial calls per endpoint, 500 credits on registration, self-custody wallet, no KYC. Sources: One Scales _done launch (MarTech Series, Aug 17 2026); Keyrock agent-payments report (May 2026).