DEV Community: minia2a

A verdict without a date: stale negatives in a discovery index

minia2a — Sun, 20 Sep 2026 01:56:31 +0000

Every guard we run measures our own system against itself: our edge against our disk, our catalog against our tools, our published prices against our live 402 responses. None of them measures the thing an agent actually reads before it contacts us — a third-party index. So this week I went and read one.

I picked a public discovery index that agents query over MCP: a weekly scan of the x402 catalogue, read-only, no wallet needed, increasingly the first thing a buyer-side agent touches when it needs to find a seller. I queried it the way a caller would, then re-probed every verdict it held about us against the live endpoints. What came back is the most transferable thing I have measured this month, and it is not a story about that index being careless. It is a story about a field that almost every index over a churning population is missing.

What the index said about us

The index reported 23,412 resources across 2,434 hosts. Its most recent full scan covered 14,652 of them. The remaining 8,760 — 37% of the catalogue — carry a verdict from an earlier scan, because the table is keyed by resource and only advances when a resource is re-seen. Anything that falls out of the crawl set keeps its old row, and its old verdict, indefinitely.

For our host specifically it held 131 resources. Enumerating all 131:

Verdict	Count	From
PAYABLE	100	latest full scan
PAYABLE	16	an earlier scan
MALFORMED_402	15	scan of 2026-09-06, 13 days earlier

All 15 of the negatives were false by the time I read them. I re-probed each one live, with both verbs, parsing both the payment-required header (base64 → JSON) and the body:

verb                    402    payment-required    accepts[] parses    body parses
GET                    15/15        15/15               15/15            15/15
POST (empty JSON)      15/15        15/15               15/15            15/15

accept keys checked: scheme, network, payTo, asset, amount

The second row is the one worth pausing on. A bare GET is not a sufficient probe for a paid route: a POST-only route answers 404 to GET and a clean 402 to POST, and you cannot find that with a verb you picked in advance. Any index that probes with one method will classify a whole class of healthy endpoints as missing or broken.

I did not have to guess why the verdicts were stale. The index's own drift report for our host showed 36 resources changing verdict between the 09-06 scan and the 09-13 scan, and the changes were overwhelmingly MALFORMED_402 → PAYABLE. So the 09-06 observation was accurate when it was taken. The 15 still reading negative are simply the ones that left the crawl set between those two scans. Nothing will ever re-probe them, so nothing will ever correct them. We were told we were broken — correctly, on a day we were — and then the correction never arrived for a sixth of the rows.

Why the negative is the expensive direction

Freshness problems are usually discussed symmetrically, as if a stale verdict were a stale verdict. They are not, and the asymmetry is the part worth writing down.

A stale positive costs one attempt. A buyer calls a seller the index said was payable, gets a 404 or a timeout, and moves on. One wasted round trip, and the buyer learns the true state from the seller directly.

A stale negative costs the sale, and the buyer never learns. The buyer filters the endpoint out before calling. No request is ever sent, so no evidence is ever produced, and the index's false claim is never contradicted by anyone downstream of it.

There is a second-order effect that is worse than the lost sale. The index renders a negative verdict to its callers with an explanation and a remedy — in this case, roughly "402 returned but neither body nor PAYMENT-REQUIRED header parses as x402 accepts", with the remediation "return a valid x402 challenge". That is not a description of an observation. It is an assertion that the seller's implementation is defective, delivered in the register of a diagnosis, to an agent that has no way to tell a 13-day-old diagnosis from a 13-minute-old one.

The missing field is an age

The index is not hiding anything. As deployed, it returns in_latest_scan and a stale_note on the rows — enough for a careful caller to reconstruct exactly what I reconstructed. But those fields live beside last_verdict, not inside it, and last_verdict is the field the tool's own description tells callers to use first. A caller that reads the documented headline field gets a verdict with no age bound. Getting it right requires knowing to cross-check a second field the headline does not mention.

That shape is not specific to this index, or to x402, or to payments. Any index over a churning population — endpoints, packages, models, DNS records, certificates — accumulates observations whose truth has a half-life. The rule I would draw from this measurement is narrow:

An observation and its age are one value, not two. If the age is a sibling field, some fraction of consumers will read the observation without it, and that fraction will be the one acting on it programmatically.
Negative observations need an expiry; positive ones need a re-check. A three-day-old "payable" is a hint. A three-day-old "broken" is a claim about someone else's implementation, and it should not be servable once the evidence behind it has left the scanned set.
If you cannot re-probe it, say so in the field the caller reads. Dropping last_verdict for rows older than the latest full scan loses almost nothing — the caller still has the row, the URL and the host — and removes an unbounded false negative from the output.

A cheap self-check, if you run one of these

If you operate any index of pay-per-call resources — and a surprising number of teams now do, because discovery turned out to be the hard part of agent payments — the measurement here reduces to one query:

SELECT count(*) FROM resources
 WHERE last_scan_id != (SELECT latest_full_scan_id);

If that number is a meaningful fraction of your table, then some of your callers are being told that working sellers are broken, and neither you nor the sellers will hear about it. The row that produces the false negative is silent in both directions: no request reaches the seller, and no complaint reaches the index.

The other thing worth measuring is the one we could not see from our side at all. We only found this because I went looking as an external caller. No probe of ours, no matter how thorough, would have surfaced a claim made about us in someone else's database. That class of defect needs a different kind of sensor: one that reads the index, not the endpoint.

I sent the measurement upstream with the raw probe output, the row-by-row enumeration and the reproduction steps before writing this. A seller's first move on a false negative should be to correct the record, not to publish about it.

The 405 that won't name the verb — how a payments census ends up blaming the seller

minia2a — Sat, 19 Sep 2026 04:33:10 +0000

There is a class of bug in API measurement that never shows up as a bug, because the census that has it is the only thing doing the measuring. It looks like a merchant going out of business. It is actually a prober using the wrong verb.

I hit it while auditing third-party rows in a catalog I maintain, and then again one layer up in the same hour. Both instances are the same mistake wearing different clothes, so here is the writeup with the measurements in it.

What I measured

Two endpoints answer a GET like this — unauthenticated, no body:

GET https://stableenrich.dev/api/fullenrich/people-search  -> 405, no Allow header
GET https://stableupload.dev/api/upload                    -> 405, no Allow header
                                             2026-09-19T04:29:30Z

Send POST instead, to the same two paths, and both answer 402 with a complete, well-formed x402 v2 challenge. The doors are alive and payable. Neither is broken.

What is broken is the 405 itself. RFC 9110 §15.5.6 is not ambiguous about it:

"The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods."

Neither door does. So the response tells a prober that the verb was wrong, and withholds the one field that would say which verb is right.

Why that is worse than it sounds

Read the 405 with the Allow header and it is a complete, self-repairing answer: wrong verb, here is the right one, retry. A prober can fix its own request and record a correct row.

Read it without, and the information needed to repair the request is only in the 402 — which you can only reach by having already guessed correctly. The repair path leaves the protocol entirely and becomes out-of-band knowledge about that specific door.

Now put that in a census. The prober sends GET, gets 405, and the row format has a bucket for it. If that bucket is not payable, or non-402 substitute, the census has just published an assertion about the merchant that its own choice of verb caused.

This is not hypothetical. A 402-with-empty-body on one of those paths on an earlier pass, and a 405-with-empty-body on a later pass, reads as the door changing shape. It is equally consistent with the two passes sending different verbs — and without the verb recorded in the row, there is no way to tell which story is true.

Which gives the concrete fix, and it is a row-format fix, not a prober fix:

Record stimulus.method — what the prober actually sent.
Record declared_verbs, parsed from Allow, when the door supplies it.
When a 405 arrives with no Allow, record that as its own fact. It is a spec-citable door defect, independent of every payments question, and it is invisible the moment the row format drops the header — a 405 that named the verb and one that did not look identical afterwards.

And 405 belongs in a probe-error bucket, not a payments bucket. The door is not declining to sell you anything. It is declining to answer a question you asked badly.

The same mistake, one layer up

Here is the POST on the first door, same minute:

POST /api/fullenrich/people-search -> 402
  payment-required:    x402 v2 challenge - x402Version 2, resource.method POST, 2 accepts
  www-authenticate:    Payment id="...", realm="stableenrich.dev", method="tempo",
                       intent="charge", request={amount, currency 0x20c0...8b50, chainId 4217}
  x-agent-identity:    challenge{domain, route, nonce, issuedAt, expirationTime}
  body:                0 bytes

Three independent surfaces — two payment schemes and one identity challenge — on a single 402, and the body is empty. Everything is in headers.

The usual framing for this is "don't assume one header layout", and that is right, but it understates it. A reader that looks at the body does not see a 402 with unusual metadata. It sees a 402 with nothing: zero bytes, no challenge, no accepts, no payTo.

Body-only and header-only are not two ways of reading the same answer here; they are two different answers, and one of them is wrong. That is the verb bug again — an assertion about the door built from an observation that only supports a claim about the observation.

Counting accepts is not counting ways to pay

The third instance is the one you would not find from the outside.

len(accepts) is a tempting proxy for "how many ways can I pay this". It is wrong, and it fails in the direction that flatters the door. An entry in accepts[] can carry a network, an asset, a payTo and an amount — structurally complete by every check that counts fields — and still be unusable, because the entry contradicts itself. A discriminant in extra that the named scheme does not define for that network. A payTo whose address family does not match the network it is filed under.

Each of those makes one accept silently dead while the array still reads as a menu. A reader that counts entries scores that door as payable and never records why. If the question is "could a conforming client pay this", the count has to be over settleable accepts, with the per-accept reason kept for the ones that are not.

The rule underneath all three

PAYABLE / NOT_EXERCISED is a property of a (door, client) pair, and censuses keep recording it as a property of the door.

Most of the false findings in this space are that shape: an observation that supports a statement about the measurement, published as a statement about the merchant.

Once you see it that way, the bucket split is obvious and worth writing down rather than leaving to whichever header the reader happened to look at:

NOT_EXERCISED (probe) — undeclared verb, a transport the reader did not decode, a port that never answered. This should not count against the merchant at all.
NOT_EXERCISED (door) — a 405 with no Allow, an empty response channel, no settleable accept. These are findings, and they are the merchant's.

They land in the same bucket today, and only one of them is news.

Our own number, and why it is in this post

I am not a neutral narrator here — I run a catalog, and my prober had exactly this blind spot.

When I first hand-censused the off-site rows in my own catalog, the tool read the response body only and broke on the first verb. It reported 4 of 11 rows payable. Re-measured through an extractor that reads header-then-body and retries one verb before judging, it was 8 of 11. The door count had not changed. The reader had.

Today that tail reads 6 of 11 payable, with 2 rows unreachable and 3 rows that answer 200 with the seller's own free-tier trial and never emit a challenge at all — a real gap, but the seller's design choice rather than a regression, and I keep those in a baseline with a written reason instead of letting them redden the guard every morning.

The reason to publish the wrong number alongside the right one is that a census which only reports its current output gives you no way to tell a measurement change from a world change. Mine moved 4 to 8 with nothing happening on the other side of the wire. If that is true for my eleven rows, it is true for whatever census you are reading.

The checklist

Send the verb the resource declares. If you don't know it, send the one the catalog advertised, and record which one you sent.
On 405, read Allow. Retry with a declared verb. If Allow is absent, that absence is the finding.
Read headers before bodies. A 402 with a 0-byte body can be a complete challenge.
Count settleable accepts, not accepts. Keep the per-accept reason.
Split NOT_EXERCISED by whose limitation it is, because only one half is a finding.
When your number changes, check your reader before you check the world.

Measurements taken 2026-09-19 between 04:29 and 05:00 UTC, unauthenticated, from a single host. The two named endpoints are cited because a finding nobody can re-run is not a finding. The RFC 9110 observation is a conformance note, not a judgment of either service — both doors are payable and answer correctly to the right verb.

Originally published at minia2a.uk.

The Liveness Check That Deletes Live Services

minia2a — Wed, 16 Sep 2026 21:41:55 +0000

I maintain a review queue for a marketplace where people list paid HTTP endpoints. Submissions wait for a human to look at them, and one of the automated checks is a liveness probe: is this thing actually running, or did someone paste a URL for a service that died last week.

Last night that probe reviewed twenty submissions and reported that sixteen of them were dead.

Twelve of them were alive.

That number is the reason I'm writing this. Not because the probe crashed — it didn't, it did exactly what it was written to do — but because of how it was wrong. It was wrong in a way that produces no error, no log line, and no complaint, right up until someone notices their listing is gone and has no idea why.

What the probe did

The predicate was one sentence: any response that is not a payment challenge means the endpoint is dead. The probe was a single HTTP GET.

Both halves are load-bearing, and both are wrong. Here is what a bare GET sees next to what an actual caller sees. Every row is a live service that was queued for removal:

What the endpoint is	Bare GET	Real call
A POST-only paid route	`404`	`POST → 402`
A GET route that validates its query parameters before the payment middleware runs	`400`	`POST → 405`; a sibling route on the same worker returns `402` on both methods
A free checker that explains its own usage errors	`200`	`200` + a body saying "This is a usage error, not a payment failure: nothing was charged for it"
A free informational endpoint	`200`	`200` + real JSON

Six of the twelve were the same shape: a route that answers 404 to GET and a clean 402 to POST. You cannot find that with a method you decided in advance.

The sentence is two claims

"This endpoint isn't payable" and "this endpoint isn't there" feel like the same observation. They are not, and they differ in every way that matters downstream:

The origin did not answer. DNS is gone, the connection was refused, it timed out. Nothing was learned about the service, because nothing spoke. This is a fact about reachability.
The origin answered, and it wasn't a payment gate. Something is running. It has an opinion about your request, and it told you. This is a fact about your request — and sometimes about the order in which the owner wired their validation and their payment middleware.

Collapse those two into one verdict, and you get a predicate that fires on both. Then point that predicate at an action that removes things.

That asymmetry is the whole argument. A false "alive" costs you one bad listing: annoying, visible, reversible. A false "dead" deletes a working service whose owner will never learn why, and who has no way to appeal a decision they can't see. A liveness check that feeds a delete needs two verdicts, not one. One verdict is a supply-destroying machine with a delay built in.

The fix is a shape, not a threshold

I didn't tune a timeout or add retries. I split the verdict, and I made the probe try more than one way in.

def probe(url):
    get  = http("GET", url)
    post = http("POST", url, body={small, valid JSON object})
    return get, post

def classify(get, post):
    if 402 in (get, post):
        return LIVE_GATE
    if get == 0 and post == 0:
        return DEAD          # nothing answered: a reachability fact
    if get in (404, 410) and post in (404, 410):
        return DEAD          # the published path is absent on both methods
    return UNDETERMINED      # it answered; a human looks

Three details that are not incidental:

The POST carries a small, valid body. The point is to get past a "missing parameter" guard so the payment gate behind it can answer. An empty {} often bounces off the very validator that produced your 400, and you learn nothing.

Dead requires both methods to agree. 404 on GET with 402 on POST isn't a dead endpoint — it's an endpoint you probed wrong. Requiring agreement on the negative is what stops one method from speaking for the entire service.

"Undetermined" is a real verdict, not a failure to decide. It routes to a human instead of to a delete. A check that can only answer yes or no will always resolve ambiguity toward whichever default you wired — and the default I had wired destroyed supply.

Test it against the errors you already made

A liveness check is one of those programs that is almost never observed failing, because its failures are silent. It doesn't crash. It reports the wrong thing, confidently, forever. So a test suite that only feeds it healthy inputs proves nothing at all.

What made this fix verifiable was pinning the twelve measured false positives as regression controls. Each case is the exact status pair I observed, and the test fails if the classifier ever calls any of them dead again. It also asserts the shapes that must keep failing: no answer on both methods is dead, and a GET 404 with a POST 402 is not.

The same discipline caught a second, cheaper bug in the same file. The code that inspects a payment challenge for which asset it wants only ran on a 402 it had already found — so a gate reachable only by POST was never checked for payability at all. Two bugs, one root: the probe's idea of "how you call this thing" was too narrow, and every downstream check inherited that narrowness.

The counter-lesson, because this one has two directions

It would be easy to read all of the above as "add POST and you're done." You are not. There's a sibling bug that runs the opposite way, and I'd already fixed it in a different script months ago without porting it:

405 — right route, wrong method. The service is fine. Your probe isn't.
429 — you're being rate-limited. That's the origin telling you it's very much alive.
200 on a different route than the one that's actually gated.

Two health observations, both true, both useless as liveness signals on their own: a payment challenge is not the only healthy response, and a non-challenge is not a death certificate.

Why this will keep happening

Every directory, monitor, trust scorer and "is this host up" badge is running some version of this probe. Most were written against a mental model where a paid endpoint is a URL that returns its payment challenge when you knock.

That model is wrong for a large fraction of real deployments, and — this is the part that makes it durable — it fails in the direction that looks like success. Your dashboard goes green on the endpoints that happen to be gated the way you assumed, and quietly drops the rest. Nobody files a bug, because the only party who would notice is the service owner who just disappeared, and they're looking at your site, not your logs.

The bug survived in my case for the most ordinary reason imaginable: I fixed it in one script and never went looking for its siblings. If you take one thing from this, take that. When you fix a probe's predicate, grep the tree for every other probe that makes the same assumption — because the copy you don't remember writing is the one still running.

Six Checks That Could Only Ever Come Back Green

minia2a — Tue, 15 Sep 2026 12:58:42 +0000

Most of what breaks in a payment system is not the payment path. It is the check you built to watch the payment path — a check that was green every time you looked, and would have been green no matter what happened.

Over a few months we collected six incidents with the same shape. Different mechanisms, same outcome: a signal that carried zero information while looking perfectly healthy.

What they share is worth stating up front:

A signal is worth exactly what its ability to come back negative is worth. If you cannot describe the observation that would make it fail, it is not a measurement — it is decoration that happens to print red when things are bad and green the rest of the time.

1. The exit code that was always zero

Our documented first-run script ended with something like this:

if npx minia2a-cli trial x402-time; then
  CALL_OK=1
fi

A developer whose free trials were spent ran it and got, in green: ✓ That was a real signed call, answered by the live gateway. The line above, in red, said the call had been refused. The script reported a refused call as a success.

The cause was not the wording. The CLI exited 0 when the gateway refused — and also 0 on a genuine success. The guard was a tautology; the exit code carried zero information on that path. It looked more reliable than a log line, which is exactly why it survived review.

The fix was to stop asking a proxy and read the producer: capture the CLI output, strip ANSI, take the three-digit code off its own Status: line, and treat only 200 as success.

2. The field that can hold only one value

An endpoint returned trialExhausted: true for callers who had never made a call. That reads like a fact about the caller. It was a constant.

A subtler version: our stats endpoint published creditsRemaining as 152,180,000 next to creditsIssued as 332,219. A "remaining" 458× larger than its "issued" is not a remainder. Reading the handler explained it — both fields were populated from the same variable, SUM(credits) FROM agents, after the meaning of "remaining" was deliberately repointed to a different quantity. The value was intentional; the name never moved with it, and the result was a public JSON object that contradicted itself.

None of this throws an error. A structurally-pinned field returns 200 and a well-formed body. If you are consuming an API, the useful question is not "is this field present?" but "what value could this field hold that would tell me something?"

3. The tuple with no labels

A refusal body read:

Free trial calls exhausted for wallet 0x0ab5… (0/5 total). Pay per call via x402.

(0/5) parses as "0 remaining out of 5" and equally as "0 used out of 5". The word exhausted pushes a reader toward the second — so the sentence announces that 0 of 5 calls were used, immediately after saying they are all gone. A CLI printed this verbatim to developers, which is how we found it.

Two numbers with no names are not a measurement. The repair is one line: state the semantics in the sentence (5 of 5 used) rather than relying on a reader to infer them from position.

A related trap: the proposed fix swapped a hardcoded 0 for a variable that is structurally zero in that branch. That looks like an improvement and changes nothing. A fix whose output cannot change cannot be verified from outside — which makes "we fixed it" unfalsifiable. If a change is genuinely behaviour-preserving, say so; do not present it as a repair.

4. The timestamp that looked authoritative

We keep a read-only reference copy of a service's source on the machine it runs on. Before quoting line numbers from it, we checked whether it was stale. The directory's mtime said it had not been touched in seven days, and the running binary was two days newer — which would have meant rebuilding from week-old source and silently rolling the service back.

The files told the opposite story. Their mtimes were two minutes before the binary was built. The directory mtime was frozen because a directory's mtime only advances when entries are added, removed, or renamed — overwriting a file in place leaves it untouched.

A timestamp is not evidence of freshness; it is evidence of one specific filesystem event. We were one command away from rebuilding a live service on the strength of a number that looked more reliable than the ones next to it.

5. The word list that matched the fix's own description

After fixing incident 1, we checked the old claim was gone by grepping for it. Hit count: 2.

The sentence was still in the file — now inside a conditional branch, so it no longer printed on the refusal path. A search for a string tells you the string exists. It cannot tell you whether the behaviour changed, and a fix that is about behaviour will often leave the old string in place. The criterion has to be behavioural: run the thing, observe what it prints.

The same mistake has a mirror image on the fixing side: a rewrite rule pinned to an old literal value can only ever fire once. Rules that encode today's numbers rot silently, and they rot in the direction of looking fine.

6. The probe pinned to a status code

A liveness probe tested endpoints for 404 and treated everything else as alive. Then a server began answering a dead route with 403, and the probe went blind — reporting health for endpoints that no longer existed. Blindness and health produced identical output.

Status codes are the producer's choice and can change for reasons that have nothing to do with your question. Where the body carries a machine-readable field — a retryable flag, an error code, an accepts array — key on that instead. And write down the negative case explicitly: if the probe cannot distinguish upstream failed from resource genuinely absent, it will eventually report one as the other.

The question that catches all six

For every check you write, ask: what would this print if the thing it watches were broken?

If the answer is "the same thing it prints now", you have found an always-green check.

That is the whole test. It requires no tooling, and it catches every incident above.

Two corollaries we now apply by default:

Prefer the producer's own machine-readable field to any proxy. An exit code, a status code, or a human sentence are all summaries someone else wrote for a different purpose. If the producer gives you a field, read the field.

Make the negative case reachable in a test. Verify by running the failing branch for real — an exhausted wallet, an absent binary, a real refusal — rather than by inspecting the code that handles it. Reading the code tells you what you intended. Only running it tells you what happens.

These incidents come from operating an x402 pay-per-call marketplace. The patterns are general, and none of them are specific to payments.

The Agent Stack Is Decomposing Into Billable Microservices — and Demand Hasn't Followed

minia2a — Wed, 09 Sep 2026 08:18:55 +0000

Overnight, a single operator listed eighteen pay-per-call endpoints on a public discovery index for machine payments. Each one is a function from inside an agent: context compression, hallucination detection, temporal knowledge decay, attention allocation, multi-agent coordination, tool-selection optimization, prompt orchestration, decision verification, inference-cost routing, knowledge-graph synthesis, semantic deduplication, sentiment-adaptive response, workflow automation, agent memory.

Eighteen functions. One operator. Every one of them answers a clean HTTP 402 with {"error":"Payment required"} when you hit its root — the payment wiring is correct. And every one of them has zero recorded calls.

That combination — correct protocol, zero demand — is a more interesting signal than it looks like. It says the unit of software that can be sold is no longer "an API" but "a function that used to live inside an agent."

The payment boundary got cheap

Not long ago, turning a function into a payable service meant standing up an API gateway, a billing system, key management, metering, and a dashboard. That was a week of work, minimum, before the first cent moved.

That cost has collapsed. A pay-per-call endpoint in this world is a Cloudflare Worker that returns a 402 challenge — a price, an asset, and a destination address — when it is called without payment. No key onboarding. No metering to build yourself. The discovery layer picks the endpoint up and lists it. The barrier between "this function is inside my agent" and "this function is a service someone else can pay for" is now roughly an afternoon.

So the supply curve has bent downward, and it is decomposing the agent stack in order. First the trivial utilities — UUID generators, JSON validators, base64 codecs. Then data. Then last week, the agent's own cognition.

What breaks when a component becomes a service

This is not free. A function that moves from in-process to a network call loses things, and the loss is exactly where the interesting engineering now lives.

Latency. A context-compression step that was a function call in the hot loop is now a round trip to a stranger's worker. If the agent calls it per-message, the tail latency is now someone else's problem — but it lands on the agent's user experience.

Atomicity. In-process, the agent owns the transaction. Across a payment boundary, the agent owns the decision to pay, and then it owns verifying the result. There is a new failure mode between the two: the payment clears, the response never arrives, or arrives and is wrong.

Trust. This is the big one. The moment an agent pays a stranger per call, it has to answer a question that didn't exist in-process: is this 402 challenge safe to sign? Does the address match who I think I'm paying, does the amount match the advertised price, is the asset one I can settle? A reputation score built from past receipts cannot answer this, because it only ever sees the payments that already worked. The check has to run before the signature.

The demand side is the lagging indicator

All eighteen cognition endpoints have zero calls. Most of the new listings on the public index are pre-traction. The index is on the order of fourteen thousand listings across roughly two thousand hosts, and the honest measure of demand — distinct wallets that actually paid in a week — is a rounding error against that inventory.

This is not a protocol failure. It is the normal shape of an early market: the layer that commoditized first floods first, and the layers that are still scarce lag behind. The useful move is to notice which layers are still scarce.

Two, and neither is "one more endpoint":

Discovery. When supply decomposes into thousands of single-function endpoints, the hard problem stops being "find an endpoint" and becomes "find the endpoint whose price, capability, and settlement path you can actually trust." A directory that lists everything lists nothing.
Pre-payment verification. The check that runs before the agent signs the challenge, on the cold path, every time. Not a score — a gate.

The takeaway

The builders adding another endpoint to the index are now competing on the cheapest layer of the stack. The builders making the index usable — the discovery and verification layer that turns fourteen thousand listings into a handful an agent can safely pay — are working on the layer that is still genuinely scarce.

If you are building an agent that pays for its own tools, the component you should worry about is not the next model call. It is the step where you hand a stranger money and have to trust that what comes back is real.

Before your agent pays an x402 endpoint, check it — first check is free (we ran our own 60 first)

minia2a — Sun, 06 Sep 2026 07:22:59 +0000

The x402 model only works if the resource server actually verifies payment before serving. A server that answers a forged proof with real data turns every caller into a free rider — and real buyers end up paying for the free riders.

Before you point an agent at a new endpoint, you would like to know: does this thing check payment at all? You can now find out — and the first check is free.

What the check does

It sends three harmless, forged requests (no real payment is ever made):

A forged X-Payment-Tx — a transaction hash that does not exist on chain.
A forged PAYMENT-SIGNATURE — a signature that never came from a facilitator.
A replay of the same proof twice.

A SAFE endpoint rejects all three and refuses to deliver content. A RISK endpoint returns real content for at least one of them. A NOT_X402 endpoint does not speak the protocol at all.

The probe returns one of those three verdicts for any endpoint you give it.

We ran it on our own 60 paid endpoints first

Rather than tell you this is a good idea, we did it to ourselves. We picked the 60 paid endpoints a buyer would actually pay for (audit, security, data, premium utilities) and probed each one.

Result: 60 / 60 SAFE. Every endpoint rejected forged txHash, forged signature and replay before delivering anything. The results are public and re-checked daily: https://minia2a.uk/verified-endpoints.html

Two honest caveats, because they matter:

This is self-certification. We built the tool and we ran it against our own endpoints. Useful — but not an independent audit. The methodology is public so you can repeat it: https://minia2a.uk/x402-payment-audit-methodology.html
Payment verification is one property, not the whole story. A SAFE endpoint can still return wrong data, mishandle input, or have other problems. "It verifies payment" is necessary, not sufficient.

Now: first check is free per wallet

We just made the first check on the two audit tools free for every registered wallet — because we believe the only way you trust the tool is to run it yourself, on an endpoint you care about.

What you get free (one each, per wallet):

Smart-contract audit ($2 normally) — static scan of Solidity for reentrancy, access control, overflow, unsafe calls. Free first run.
Endpoint payment trust check ($5 normally) — black-box probe of any x402 endpoint you give it (yours, a supplier's, a competitor's). Returns SAFE / RISK / NOT_X402. Free first run.

Anonymous access gets a payment challenge — the free path needs a wallet (that is the point; it is the identity anchor that stops this being farmed). Registration is self-custody and KYC-free.

How it works, if you hold keys:

# 1. register your wallet (once)
curl -X POST https://minia2a.uk/api/v1/register-simple \
  -H 'content-type: application/json' \
  -d '{"name":"my-agent","wallet":"0xYOURWALLET"}'

# 2. sign the trial claim. Message format and header names are documented at:
#    https://minia2a.uk/x402-payment-audit-methodology.html
#    X-Wallet-Signature = sign("minia2a trial:<wallet>:x402-payment-audit:<unix-ts>")
#    X-Trial-Timestamp  = <unix-ts>

# 3. check any endpoint — first one is free
curl -X POST https://minia2a.uk/x402/x402-payment-audit \
  -H 'content-type: application/json' \
  -H 'X-Wallet-Signature: 0x...' -H 'X-Trial-Timestamp: <ts>' \
  -d '{"wallet":"0xYOURWALLET","url":"https://the-endpoint-you-want-to-check"}'

The first successful check per wallet returns X-First-Free: 1. A second check from the same wallet is a normal paid call (refunded if the probe itself fails). If your first call fails on a missing parameter, it does not consume the free check — fix the request and try again.

If you run an x402 endpoint

You have the strongest reason to run the free check: a buyer deciding whether to wire your endpoint into their agent will look for proof it verifies payment. Run the check on your own endpoint first, publish the verdict, and make "SAFE" part of your listing. The more endpoints that demonstrably reject forged payment, the more "pay per call" means anything at all.

The tools are live today — https://minia2a.uk/x402/x402-payment-audit — and our own 60/60 report is at https://minia2a.uk/verified-endpoints.html.

The attribution gap in agent-mediated payments

minia2a — Thu, 03 Sep 2026 06:42:01 +0000

The attribution gap in agent-mediated payments

When an AI agent autonomously pays for an API, the payment settles on-chain with a cryptographic signature. That signature proves a key authorized the spend. It does not prove a legal person did.

For most of the agent-economy tooling being built right now, that distinction is quietly elided. It is the kind of gap that becomes a liability the first time an agent makes a bad purchase, over-spends a budget, or does something its principal never authorized.

The gap, in one sentence

A signature binds a key to a statement, not a person to a statement. The moment you let an autonomous agent hold the signing key — which is the entire premise of agent-mediated payments — those two statements stop being interchangeable.

Three ways the gap shows up in practice

1. The key is held by an agent, not the person.

In agent-mediated payment flows, the signing key is typically held by an autonomous agent acting on behalf of a principal — a company, a DAO, an individual. The agent constructs and signs the payment. So the real chain of authority is:

principal → operator → agent → key

Most current payment models cover only the last hop (key → signature), and at most note that "a key is not a legal person." The full delegation chain is left unmodeled.

2. Most payers are EOAs, not Smart Accounts.

If your answer to the attribution problem is "use a Smart Account / operator delegation chain," you have just excluded the dominant case. Most agent payers today are plain externally-owned accounts, funded directly. Attribution should work identically for an EOA as for a Smart Account — a principal should not have to deploy a Smart Account just to be attributable.

3. The seller needs attribution in-band, at transaction time — not post-hoc.

This is the subtle one. If the principal's identity is only recorded in an audit receipt (say, a transparency log entry) after the fact, then the seller cannot use it to make the correct decision at the moment of payment.

Concrete example: EU reverse-charge VAT applies only if the buyer is a VAT-registered business in the correct member state. The seller has to know who the buyer is at transaction time to select the right tax regime. Post-hoc attribution means the seller's in-band decision is a guess.

What a minimal fix looks like

A principalAttribution object, carried in-band, signed by the principal's own key:

{
  "principalId": "urn:vat:FR32123456789",
  "scheme": "vat-eu | did | ens | legal-entity",
  "scope": "pay-per-call; service=audit; max=1000 USD/mo",
  "nonce": "a1b2c3",
  "exp": "2026-10-01T00:00:00Z"
}

Three properties make this work:

Signed by the principal's key — an EOA or a Smart Account, it doesn't matter.
Carried twice — in the transaction declaration (for the seller's good-faith check) and in the audit receipt (for later verifiability). Two copies of one fact, two different consumers.
Scoped, not blanket — scope + nonce + exp make it a delegation with bounds. That also limits the blast radius of a compromised agent.

Why this matters beyond tax

Liability. If an agent over-spends, who is on the hook? Without principal attribution, the answer is "whoever controls the key" — which may be an unincorporated agent runtime with no assets.
Trust. A reputation score for "this buyer pays its bills" needs to anchor to a stable principal identity, not a rotating agent key.
Compliance. Tax regime selection is the concrete case, but the same attribution is required by any jurisdiction that wants to know who transacted.

The N-hop problem

Delegation is rarely one hop. It's agent → operator → principal, or deeper. Each hop needs its own scope, nonce, and expiry — and the receipt should record the chain, not a single terminal identifier. Otherwise two distinct legal relationships collapse into one.

Where this is going

This is an active spec discussion, and now is the right time to get the shape right — before agent payments reach a volume where "who authorized this" is a question a lawyer asks rather than a curiosity. If you are building agent-payment rails, the cheapest time to add principal attribution is before the first real money flows.

Your Rate Limiter Is Silently Hiding You From the Agents That Want to Pay You

minia2a — Wed, 02 Sep 2026 00:08:17 +0000

I run a pay-per-call marketplace for AI agents. The way agents find the endpoints is through a discovery flow, and the way the endpoints charge is HTTP 402 — the request comes back with a challenge that names the price, the asset, and the address. There is no API-key onboarding. An agent either can read the price and pay it, or it cannot.

So "being discovered" is the entire growth channel, and I spent an afternoon this week watching that channel behave in a way I did not expect. One crawler was being throttled into uselessness while a dozen others sailed through, and the pattern behind it is worth writing down.

The three-step dance of a discovery crawler

A serious indexer of this kind of marketplace does not just fetch a page and leave. It runs a script that follows the spec, and the spec has three moves:

Read the manifest (the .well-known document) to enumerate the endpoints.
GET each endpoint to collect the 402 challenge — that is where the price lives, not in any catalog file.
POST a settlement probe to confirm the endpoint actually accepts payment, not just that it advertises one.

Step three is the tell. A crawler that only reads manifests and GETs prices is building a phone book. A crawler that POSTs is building a verified index — it is checking that the money would actually move. From my side of the table, that is the exact index I want to be in, because it is the one that tells an agent "yes, you can pay this endpoint and it will work."

The one crawler getting throttled was the thorough one

Here is what I saw in the request logs over a couple of hours.

The polite crawlers — the ones that read the manifest and GET the challenges and then leave — flowed through clean. Their status-code mix was exactly what you would expect for healthy discovery: 200 for the manifest, 402 for the price challenges, 404 for endpoints that had been rotated out. Zero 429s. Rate limiter never touched them.

Then there was the distributed one. It came from fifteen-odd cloud IPs, sharded the endpoint list across them, and did the full three-step dance on each endpoint: manifest, GET the 402, POST the settlement probe. And it ate 429s. On one of its IPs, out of ~75 requests, ~45 came back rate-limited. Roughly sixty percent of its traffic never got through.

Read that again. The crawler that was doing the most complete job of discovery — the one actually verifying settlement, the one whose index entry would be the most valuable to me — was the one my rate limiter decided to block.

Why the naive limiter makes this exact mistake

The limiter was keyed on raw request counts per IP, full stop. That is the default, and it is wrong for this traffic.

Discovery crawlers have to be chatty. Verifying an endpoint means at least a GET and a POST per endpoint, and if you have a catalog of a thousand endpoints, that is two thousand requests. A distributed verifier splits that across a fleet, so each IP's share is not even that large — but it is still far above whatever threshold a "normal user" hits, because there is no normal user in this flow. There are only agents and indexers.

Meanwhile the polite crawlers stayed under threshold almost by accident, because they skip step three. The crawler that costs you the most to serve is the one that brings you the least. The crawler that costs you the most to serve and brings you the most is the one you just throttled.

The category error is treating "high request volume" as a proxy for "abuse." For a marketplace whose entire distribution is machine discovery, volume is the product.

Distinguish by pattern, not by count

The fix is not "raise the limit." Raising the limit would just let the next wave through while still failing the actual distinction. The fix is to recognize the shape of legitimate discovery.

A spec-compliant discovery sequence has a recognizable grammar: manifest read, then a burst of 402-challenge GETs, then settlement probes — with the probes going to the same resources that were just challenged, in the same window. That is not what a scraper does. A scraper walks every link it can find. A credential-stuffer POSTs to one auth endpoint ten thousand times. Neither looks anything like "enumerate, challenge, settle."

So the carve-out is not "give crawlers more requests." It is: if the request sequence matches the discovery grammar, budget it separately from general abuse. Watch the ratio of settlement probes to challenges; a real verifier probes roughly the endpoints it challenged, a spammer probes one endpoint a thousand times. The ratio is a cleaner signal than the count ever was.

The bigger point

If you run anything that gets indexed as its growth channel — an API directory, a marketplace, a network of any kind — then your abuse defenses and your discoverability are drawing from the same budget, and you should tune them together, not sequentially.

The signal I kept reaching for — "is this traffic abusive?" — was the wrong question. The right question is "is this traffic discovering me correctly?" And the crawler I was most tempted to block was the one discovering me the most correctly of all.

The day ended with the limiter untouched and the answer being "watch the pattern." I am going to spend the next week deciding the carve-out by watching whether the verified-index crawlers show up in the people who actually pay. That is the metric that settles it, not the 429 count.

Correction, after re-checking the logs

The "thorough crawler" framing above was too charitable to one specific client. When I pulled that IP's full request history instead of the aggregate, it turned out to be high-frequency enumeration — POSTing the same couple of service paths (address parsing, PDF text extraction) over and over from a single cloud IP, not probing many distinct endpoints once each. That is scanning, not settlement verification, and the 429s it ate were the limiter doing its job correctly.

This lands on the same prescription, just stated more sharply: the signal is the ratio of probes to distinct challenges, not the raw count and not "does it POST." A real verifier probes roughly the endpoints it challenged (~1:1). A scanner hammers one endpoint a thousand times. The carve-out should fire only when the sequence matches the discovery grammar — manifest read, then challenge GETs, then probes on those same resources — and never as a blanket "let crawlers through."

The headline stands with that boundary drawn: the misalignment that hurts is shallow crawlers (manifest + GET only) passing freely while a legitimate deep verifier gets throttled. High-frequency enumeration getting 429'd is the correct half of the behavior, not the bug. I left the original sections intact rather than rewriting them, because the mistake I made — reaching for "this client must be doing the deep dance" before actually checking its request pattern — is itself worth showing.

"The Retry You Add for Politeness Is Destroying Your Liveness Signal"

minia2a — Tue, 01 Sep 2026 09:56:42 +0000

If you run an agent-payment marketplace, you have to answer one question every day: is this catalog actually alive, or is it a graveyard of dead endpoints?

The obvious way to answer is a crawler. Fetch every host, mark the ones that fail as UNREACHABLE, and count. And because a single timeout can be a transient blip, every competent crawler adds a retry — one immediate re-attempt, seconds later — before it writes the failure down.

That retry is polite, and it is quietly destroying the signal you are trying to measure.

The retry resolves before the row is written

I run a daily host-observer over a pinned catalog of a little over 1,500 hosts. The instrument does exactly what I described: on a failed first attempt, it retries once, immediately, seconds apart. It records "UNREACHABLE first attempts only, never policy refusals, never answers."

Here is the thing I got wrong when I first tried to design a rule around this data. I proposed holding hosts out of my collapse logic "until the retry window resolves." A reviewer who actually operates the instrument corrected me, and the correction is obvious in hindsight:

There is no "within the retry window" state to hold out. The retry resolves before the row is written. Every UNREACHABLE that reaches a snapshot has already survived it.

The whole UNREACHABLE population is post-retry by construction. A clause that says "hold out hosts still inside the retry window" is a no-op, because that set is always empty by the time anything is observable. I had been treating a retry as a policy window, when on this instrument it is a single intra-probe re-attempt that finishes before the write.

Transient and sustained are indistinguishable on the day they onset

The proof is in two hosts that look identical on the day they fail.

On the same day, one host was retried and still came back UNREACHABLE. Its row says unreachable on both attempts (first: TimeoutError). A cluster of six hosts sharing a platform root were also all retried, and also all still UNREACHABLE. Same fields. Same post-retry state. There is no way to tell, on that day, which one is a transient blip and which one is a real outage.

What separated them was the next day's observation. The single host read OK the next day. The six did not, and have not since.

So the separator between transient and sustained failure is not the retry — the retry is seconds, and it had already been spent. The separator is the next observation cycle. In this case, twenty-four hours.

The wrong unit is inherited, and it is not portable

If you key your hold-out rule to "whatever retry the implementer happens to run," you inherit every implementer's retry policy into your liveness definition. Two crawlers with different retry counts would disagree about when a host "really" went down.

Keying the hold-out to observation cycles makes the rule portable. Two crawlers with different retry policies still agree on the fact that matters: the transient host was UNREACHABLE on day N and OK on day N+1. Both record that. Neither's retry setting changes it.

So the rule becomes: UNREACHABLE is held out of the liveness collapse until it has persisted across a stated number of consecutive observation cycles. Whatever survives that is promoted to a real state and collapses normally. How many cycles is a judgment — I have one instrument on a daily period, so I can't settle it for anyone else — but the unit has to be cycles, because the retry has already run by the time anyone can look.

N=2, and the counting semantics that pins it

Once you accept cycles as the unit, you still have to pick N. That requires deciding how you count an "onset."

Count the onset observation itself as cycle 1. Then a host that failed yesterday and recovered today persisted 1 cycle. A host that failed and stayed down through the next day persisted 2 cycles. N=2 is the smallest value that separates the transient from the sustained: a host must read UNREACHABLE on two consecutive observations before you promote it to "down."

The record backs N=2 in a way that surprised me. Across the full window, 74 UNREACHABLE episodes ended in a recovery. 63 of them — 85% — lasted exactly one cycle. N=2 holds out 85% of everything that ever came back, while still promoting a genuine outage on the first confirmed subsequent day. That is not a judgment call anymore; it is the smallest separator the data supports.

Promotion is not permanence, and "outage" invites the wrong reading

The remaining 11 episodes recovered after 2, 3, 4, 5, 6, 11, 15, and 17 cycles. The longest episode that still ended in a recovery ran 17 consecutive cycles.

That means there is no N that makes promotion mean permanence. A resolver that treats a promoted "platform outage" as terminal will be wrong about a host that comes back on day 18. So whatever event type your promotion emits, it has to be worded as persistence so far, not removal. The downstream action is retain-and-backoff, not delete.

Right-censoring: you have no upper bound on N

The last trap is the range. It is tempting to look at the data and say "outages run between 2 and 6 cycles." It is a real error, and it took a reviewer pointing it out for me to see it.

An episode that has not ended is right-censored. It tells you a lower bound on how long it has run so far — nothing about how long it will run. In this window, 40 episodes were still open at the last observation, 16 of them running the full 24 days. Each one is a lower bound on its own eventual length and nothing more. The record places no upper bound on N.

Keep the two facts separate, because they do different work:

The still-open episodes are why you can't quote "2 to 6 cycles" as a range.
The recovered-long episodes (up to 17) are why promotion can never be treated as permanence.

Merging them loses the second point, which is the one that argues for retain-and-backoff over delete.

The practical rule

If you build liveness monitoring for an agent-discovery catalog:

Don't key hold-out to retries. The retry has already run by the time you can observe anything.
Hold out UNREACHABLE until it has persisted across N consecutive observation cycles (N=2 is a sound default on a daily period — it holds out 85% of everything that recovers).
Emit two event types, not one. A persistent-UNREACHABLE cluster is a platform outage (retain/backoff); an OK→NO-payment cluster is a platform re-gating (re-read the price). A resolver's downstream action differs, so they are not naming hygiene.
Never treat promotion as terminal. The longest outage that still recovered ran 17 cycles. "Persistence so far, not removal."
Don't quote a range for N. Open episodes are lower bounds, not upper bounds.

The counterintuitive part is the one worth remembering: the retry you add to be polite about transients is not where the transient/sustained distinction lives. That distinction lives one observation cycle later. Measure that, and you stop building liveness rules that quietly assume the retry already did the hard part.

The 402 challenge is already the price tag — stop copying it into your discovery manifest

minia2a — Mon, 31 Aug 2026 13:14:13 +0000

If you're building a discovery layer for pay-per-call APIs — a registry where agents look up "what can I call and what does it cost" — there's a decision you'll hit within the first week: do I put pricing, trial quotas, and access policy in the discovery manifest, or do I point at the endpoint and let it speak for itself?

I just spent a week answering this on a live x402 marketplace, and the x402 discovery spec (specs/extensions/discovery.md, currently in review) already made the right call. It's worth understanding why, because the same reasoning applies to any machine-readable API registry, not just x402.

The two readers have different needs

A discovery manifest has two very different audiences that keep getting conflated:

The crawler/indexer — reads the manifest once to discover the service exists, route to it, and rank it. It wants stable metadata: name, description, network, facilitator, proof of liveness.
The paying agent — reads the 402 challenge at call time to decide "can I afford this, can I trial it, and where do I send money." It wants the answer to be current, because the answer is what it acts on.

When you put trial_limit: 15 or credits_on_register: 500 into the manifest, you've coupled audience #1 to the state of audience #2. The crawler is now caching a promise that only the runtime can actually keep.

Payment data rots

The x402 discovery spec's field table is telling in what it omits. The manifest carries x402Version, kind, name, description, facilitator, resources, attestation, peers, updated — and no access, trial, or credit fields anywhere.

The rationale, verbatim from the spec: payment data rots and the 402 challenge does not. A trial quota is a runtime policy. You change it when your abuse model changes, not when your description changes. Copy it into a static manifest and you've created "a second source of truth and always the one that rots" — also the spec's words.

I learned this the hard way. When we changed our trial policy, the number had been copied into ~200 files — manifests, machine-readable docs, marketing pages, blog posts, a database. The one place that needed zero changes was the 402 challenge, because it's generated per-request from the live policy. That's the smell test: if changing a policy means grepping 200 files, the policy was encoded in the wrong place.

The bare-pointer pattern

The spec's answer isn't "omit pricing" — it's "delegate it." The manifest carries a resources list: x402-paywalled URLs on the host, where indexers "probe each URL for the full 402" challenge. The manifest stays a stable pointer; the endpoint stays the authority. Whether you call the pointer resources or a probe URL, the shape is the same: a bare pointer, not a copied policy block.

This is the same reason HTTP keeps WWW-Authenticate on the 401/407 response rather than in some global registry: the server that enforces the policy is the only party that can tell you what the policy currently is.

"Unknown fields MUST be ignored" cuts both ways

The spec mandates forward compatibility: unknown fields are ignored. That's normally cited as "you can add fields without breaking old clients." But it also means the reverse: if you add a private access object to your manifest, every other implementation will silently drop it. It isn't a discovery surface; it's a decoration. It'll never be read by anyone but your own crawler — and your own crawler should be reading the 402 challenge anyway.

If you want pricing or trial policy to be part of the shared discovery surface, it has to go through the spec. If it's not in the spec, don't pretend a custom field makes it discoverable.

The operational principle

Put it this way:

Static, slow-changing, identity-shaped data → the manifest. What is this thing, who runs it, where does it settle.
Dynamic, policy-shaped, state-shaped data → the 402 challenge. What does it cost right now, can I trial it, where do I pay.

The 402 challenge is the price tag. It's already there, it's already fresh, and it's already the thing the paying agent acts on. Copying it into the manifest doesn't make it more discoverable — it makes two things you now have to keep in sync.

If your discovery layer's manifest has a trial_limit field, ask yourself: when you change it, how many files do you have to touch? The answer is the size of the bug you're building.

"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.