This content reflects minia2a as of its publication date and is kept for the record. Current model: x402 pay-per-call in USDC on Base only, 5 free trial calls per signed wallet, no credits and no top-up rail.
2026-10-16
Three things landed in the x402 ecosystem inside four days, and all three were about chains:
- October 13 — Ripple and Privy (a Stripe company) put programmable agent wallets directly into the XRP Ledger, built on x402. Vendor-sourced figures put XRPL at roughly 13–14 million agent payments, about a quarter of network activity.
- October 14 — Chainalysis counted more than 138 million x402 payments on Base by Q3 2026, 87% of them between a hundredth of a cent and ten cents.
- October 15 — Ankr launched pay-per-request infrastructure with x402, Monad mainnet first (eip155:143), with a discovery manifest and an MCP surface.
Every one of those is a genuine expansion of the protocol. None of them changed what our own payment challenge offers, and this post is about that gap — because the gap is where the engineering actually lives.
What our 402 says, on October 16
This is the unpaid challenge from /x402/time?probe=1, trimmed to the part that decides whether a client can pay:
{
"x402Version": 2,
"accepts": [
{
"scheme": "exact",
"network": "eip155:8453",
"amount": "100000",
"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"payTo": "0xAb62452b4b019bC4402BFfCca6C706d16d72A7Bf",
"maxTimeoutSeconds": 120
}
]
}
One entry. eip155:8453 is Base; the asset is USDC on Base. There is no Monad entry, no XRPL entry, no Solana entry. We checked eight endpoints picked across the catalog on 2026-10-16 — x402-gas, x402-dns, x402-pip-audit, x402-block-explorer, x402-ai-sql, x402-add-business-days, x402-ends-with-any, x402-camel-split — and every one returned an accepts array of length 1 on eip155:8453.
An agent holding only XRP or MON, or holding USDC on a chain we do not name, cannot pay us. That is worth saying plainly, because the announcements above are easy to read as "the ecosystem supports five chains, so this marketplace does too." It does not.
The difference between "we know the chain" and "we can settle the invoice"
Our gateway keeps a chain table. As of today it has seven entries. Exactly one of them is marked settleable (fields elided below — each full entry also carries its chain ID, USDC address and facilitator URL):
var Networks = map[string]NetworkConfig{
"base": {CAIP2: "eip155:8453", Settleable: true},
"celo": {CAIP2: "eip155:42220"},
"solana": {CAIP2: "solana:mainnet"},
"polygon": {CAIP2: "eip155:137"},
"circle": {CAIP2: "eip155:8453"},
"algorand": {CAIP2: "algorand:wGHE..."},
"cloudflare": {CAIP2: "eip155:8453"},
}
The comment sitting above that table says the rule better than I can:
Settleable is decided by actual capability, not by whether the map has the key. Adding a chain means finishing verification, settlement and refund together before setting it true.
That rule was not written as design philosophy. It came out of two incidents.
Incident one: advertising chains we could not settle
Until 2026-09-14 our discovery documents derived their advertised network list from the keys of that map. Keys are a statement about which chains the code knows a name for. They are not a statement about which chains can take money. So celo, polygon, solana and algorand were advertised.
They could not settle. Production .env carries a single RPC_URL, so the refunder processes for celo and polygon were never constructed at all, and the on-chain verification and transfer-amount helpers are hardcoded to Base. A client that took the advertisement seriously would have paid on a chain with no refund path behind it. Money you can collect but cannot give back is not a rail — it is a liability. The fix was to stop deriving the advertisement from the map and pin it to the one entry with Settleable: true.
Incident two: a chain whose facilitator stopped resolving
injective was in that table until the same day. Its facilitator host, x402.injective.network, had gone NXDOMAIN — confirmed against three independent resolvers, with x402.celo.org resolving normally in the same check as the positive control. Meanwhile /x402/chain/injective/ was still cheerfully issuing an eip155:1776 invoice. Nobody on Earth could settle it. The chain was removed, and the chain router was changed so an unknown chain no longer silently falls back to Base — a silent fallback would have produced a Base invoice under an injective URL, which is a different lie with the same shape.
Both incidents have the same signature: the invoice was well-formed and unpayable. A well-formed unpayable invoice passes every schema check you would think to write. It is only detectable against the capability behind the document.
So what would it take to add Monad, or XRPL?
Reading our own table and those two incidents, the list is short and none of it is a marketing decision:
- A facilitator that settles on that chain, and stays resolving. Incident two is what happens when this is assumed rather than monitored.
- A receiving address and a configured RPC for that chain. Incident one is what happens when the advertisement runs ahead of this.
- A working refund path on that chain. We refund failed paid deliveries — the platform reports 98 of them. A chain where the refund path does not construct is a chain where a failed call becomes an unrecoverable one.
- The EIP-712 domain, the asset address and the token decimals for that chain. These are per-chain constants and getting them wrong produces signatures that verify locally and fail at settlement.
Announcement day covers item 1 for one facilitator. Items 2 through 4 are per-seller, and they are where a marketplace's support for a chain is actually decided.
The numbers that decide it for us
Here is our own position, measured today rather than argued:
| Services listed | 1,709 |
|---|---|
| Priced at one cent | 1,438 — 84.1% |
| Priced at ten cents or less | 1,538 — 90.0% |
| Priced at a dollar or less | 1,682 — 98.4% |
| Paid calls, last 7 days | 5 |
| Paid calls today | 0 |
| Adopting agents, last 7 days | 0 |
The price band is the same band Chainalysis found the whole ecosystem living in — the one where card fees exceed the value of the call. That part of the thesis is holding up in public data and in our own catalog alike.
The bottom three rows are the ones that argue against spending this week adding a rail. Five paid calls in seven days and zero adopting agents is not a chain-selection problem. An agent that cannot find us is not blocked by our accepts array, and an agent that can find us and holds Base USDC can already pay. Adding Monad this week would move none of those numbers, and it would add a second chain's worth of failure modes to a seller whose current failure modes are not yet the binding constraint.
What would change our mind
One thing, and it is observable rather than speculative: an agent in our logs that wants a service, holds funds on a chain we do not name, and cannot bridge or acquire Base USDC. That is a rail problem, and it would be visible as unpaid 402s whose client tells us which chain it settled on elsewhere.
Until that shows up in the logs, "we support your chain" is not a claim a seller can make honestly from an announcement. It is a claim you can only make from the refund path.
Everything in this post is measured: the challenge body came from a live unpaid call, the chain table and both incident write-ups are from the deployed gateway source, and the price and usage figures came from /api/stats and /api/services on 2026-10-16. The three news items link to their own sources. If you want to check the central claim yourself, call any of our endpoints without a payment header and count the entries in accepts.
Originally published at minia2a.uk.
Top comments (0)