Today at Bright Data’s Agent Harness Hackathon, sponsors including TrueFoundry_, an agent of mine paid $150 in two seconds for work that takes five days by hand. Neither payment protocol had a word for the gap between those two numbers. Here is the build, the three specification gaps it hit, and the ecosystem scan I ran afterward to find out whose gaps they were._
I have been watching payment rails get built for some twenty years and they always get built in just about the same order. Somebody solves moving the money. Everybody celebrates. Then a decade goes by and somebody quietly solves what happens when the money moves and the goods do not as fast as the cash. Agent payments are running that sequence again, except faster, and with a buyer that has no memory of ever being cheated.
Here is the thing I did not expect to find. Two public explorers of agent payment traffic share 33.4% of their domains with each other. Either one shares under 5% of its domains with what I turned up by searching registries, GitHub, npm and .well-known paths the way a buyer agent would search. The servers that transact and the servers that are findable are close to separate populations. That gap turned out to explain nearly everything else I saw.
Purchase
The service I was buying against has deferred human fulfillment. Someone spends three to five days on it by hand. That is the entire product. Compressing it would be like speeding up a fermentation.
My agent handled the front half cleanly. Found the offer, read the terms, stopped at a human approval boundary, paid. Two seconds, $150, done. And then it sat there holding a receipt for something that would not exist until Thursday.
Both protocols I tried treat payment and delivery as the same moment. In the ordinary case, the API call where money and answer arrive together, that assumption is invisible and free. Introduce five days and it stops being an assumption and starts being a hole.
Two protocols, both young
x402 took the dormant HTTP 402 status code and made it move. Pay per call, settle on chain, no account required. It is the larger rail by a wide margin.
MPP came later with richer challenge and receipt semantics on the same shape. Smaller, more careful.
Neither expresses deferred settlement. Payment captures now and fulfillment becomes a promise with nothing standing behind it.
Why I built on MCP extensions
Both halves already existed, which is what made the gap interesting rather than merely annoying.
MCP has Tasks. Durable, resumable, survives the buyer process dying. That covers days later. MPP and x402 have payment challenge and receipt. That covers pay now. What no spec says is how the two compose. On a successful paid call the receipt and the task ID arrive in the same response, and nothing anywhere binds one to the other.
I looked at three other routes first. Escrow needs a custodian holding funds, which puts back the intermediary the whole rail exists to remove. Webhook-only completion tells the buyer that work finished and gives the buyer no way to check. Dropping the deferral drops the product, because the five days are the value.
So I built on the extensions and wrote down every place the specs made me guess.
Six terms a buyer needs before approving. Price, fulfillment mode, expected window, result type, refund policy, cancellation policy. None has a standard slot in MCP discovery. All six went into a custom namespace, readable by exactly one buyer agent on earth, which is mine.
Receipt-to-task binding is unspecified, so I invented a rule. The server ties the receipt to the task ID and keeps it stable across reads, and the buyer rejects a receipt that vanishes or changes. Reasonable rule. Entirely mine.
Three gaps in one purchase. One implementation proves the flow runs and proves nothing about anybody else running it.
Scan
I wanted to know whether the gaps were mine. So I coded roughly 7,000 surfaces across three populations: 1,127 discoverable ones from registries, GitHub, npm and .well-known files, 329 servers with verified MPP transaction history, and 5,555 registered x402 origins pulled from an ecosystem running 216 million transactions and about $53.9M in settled volume across 273,639 seller wallets.
Price first. 8.1% of discoverable surfaces state a figure an agent can resolve before calling. 71.4% mention payment or credits or billing with no number attached. Across 70 npm packages, not one gave a price.
Then recourse, which is where I stopped and reran things. 0.2% of discoverable surfaces expose a dispute or support path a machine can reach. Zero of 329 verified transacting servers. One of 5,555 registered origins. I ran it at 81 rows, then 302, then 1,127, half expecting the number to move. It never did.
Concentration is steep. Top five MPP servers hold 71.7% of transactions and 92.5% of volume, with ATXP alone around 89%.
And the registry is noisier than it looks. Full pagination pulled 20,900 entries, of which 13,505 were duplicate versions, one publisher accounting for 670 versions of a single server. Rank by count and you are ranking republication.
Two surfaces in the entire sample publish price as a real machine-readable file. Two.
What I take from it
Recourse matters more than price and gets less attention. Price tells an agent what success costs. Recourse tells it what failure costs, and an agent with no dispute path has no floor under its downside. Everything I coded is built for the run where nothing goes wrong.
Partial disclosure is worse than silence. A listing that says credits with no number walks an agent forward and hands it nothing to reason with. A blank listing at least fails closed.
The two-economy split reads like incentives, not negligence. Registries are where a server goes to be seen. Transaction endpoints are where a server goes to be used. Different jobs, different populations, and discovery currently indexes the wrong one.
And the build order runs backwards from how consumer payments grew up. Rails, then disclosure, then recourse, at machine speed.
Where it leaves the build
The work still takes five days. The specs still have no way to say so. What changed in one day is that I can point at the missing sentence and hand somebody the log.
Which leaves the question I keep turning over. A recourse standard could come from the people drafting the specs, or it could come from buyer agents refusing to pay surfaces that stay quiet, and those two roads produce different standards on different timelines. At 0.2% across 7,000 surfaces, neither has started. Who moves first, and what has to break before they do?
Appendix A: two protocols
HTTP 402 Payment Required shipped in the original HTTP spec and then sat unused for decades. Every browser knew the code. Nothing ever sent it.
x402 revived it. Server answers with 402 and a payment challenge, client pays on chain, mostly USDC on Base, and retries with proof. No accounts, no API keys.
MPP uses the same challenge and retry shape, adds receipt semantics and defines transports including one over MCP. Newer and smaller: mppscan’s top 329 servers show 2.6M transactions against x402’s 216M.
Appendix B: method
Three sources fed this. The 1,127-row discovery survey is mine, scanning MCP registries, GitHub code search, npm and .well-known paths, with Bright Data handling pages that need rendering. Transaction counts come from mppscan and x402scan, both public.