Agentic week: what the server gets to decide

This week, Cloudflare started charging for inference over x402 behind a country check. Solana got x402 payment channels where the seller can sign the meter. And two MCP SDKs fixed clients that let a server choose where OAuth secrets went. Every item comes down to one question: what does the client let the server decide?

Between 25 September and 2 October, 19 pull requests merged into x402-foundation/x402. phdargen authored 5, notorious-d-e-v 4 and PhilBot402 3. mintlify[bot] and JulienKervarrec had 2 each, and NotMcAfee, Bartok9 and lgalabru had one each. The 29 September release shipped @x402/core 2.28.0, Python x402 2.25.0 and Go v2.28.0. Most of the new lines went into one scheme on one chain.

Last week the question was what exactly a payment bought. This week it is who sets the terms after the client signs: the final price, the refund path, the code that runs in the browser, the token endpoint. Each time, the protocol bounds one thing and trusts another.

1. Cloudflare opens the gateway, and charges per inference

On 30 September, Cloudflare moved the Monetization Gateway from waitlist to closed beta. We covered the July announcement in our edge-enforcement post. Domain owners can now charge agents for websites, APIs, MCP tools and datasets. Pricing rules match the URL, headers or query parameters. Cloudflare handles verification and settlement "through Coinbase's x402 Facilitator", in USDC on Base. The beta is open to "eligible U.S.-based sellers and buyers".

Four customers are in production. Ceramic.ai sells web search at 0.001 USDC per query, according to its example repo, with no account and no API key. Its docs say the client signs for exactly the quoted amount, and failed searches are never settled. Stocktwits sells sentiment signals per request. API2PDF uses variable pricing: it quotes the most a request could cost, then settles actual consumption. Its old signup asked for a card after the first month, and Cloudflare says more than half of users dropped off at that step.

The fourth customer matters most to us. Cloudflare's own AI Gateway now accepts x402 for inference. The Machine Payments docs show the call:

curl -iX POST "https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Payment-Method: x402" \
  --header "Content-Type: application/json" \
  --data '{"model": "z-ai/glm-4.7-flash", "input": {...}}'

The docs list the conditions. The header is Cloudflare-specific. The client still needs a Cloudflare API token, must be based in the United States, and must have a card on file. Only POST /ai/run is eligible, with four open models: z-ai/glm-4.7-flash, google/gemma-4-26b-a4b-it, openai/gpt-oss-20b and alibaba/qwen3.8-27b. Most of them use the upto scheme. The wallet signs a maximum. Cloudflare runs the call and settles the actual cost, "which cannot exceed the authorized maximum". The price comes from the origin. Cloudflare calls this origin-controlled pricing: the Monetization Gateway asks AI Gateway's pricing module what to charge.

We probed both paths from Finland on 2 October. Without the x402 header, an unauthenticated call to /ai/run returns 401. With the header, the same request returns a 403, and Ceramic's paid search endpoint returns the identical 60-byte body:

# /ai/run, no x402 header, no token
401 {"result":null,"success":false,"errors":[{"code":10000,"message":"Authentication error"}],"messages":[]}

# same request + Payment-Method: x402
403 {"error":"forbidden","message":"disallowed visitor country"}

# POST https://api.ceramic.ai/search, no payment
403 {"error":"forbidden","message":"disallowed visitor country"}

The country check runs before authentication and before the 402, so an agent outside the United States never sees a price. API2PDF behaved differently: it returned its own 401 for a missing API key, not the 402 shown in Cloudflare's post. On this product, x402 is a payment method attached to an account, not a replacement for one. The server decides who gets to see the price, and, after the call, what the call cost.

2. Solana gets batch-settlement, with an optional seller-signed meter

PR #3164 implements the Solana batch-settlement scheme in TypeScript. Ludo Galabru opened it on 14 August and it merged on 25 September: +33,778 lines across 165 files, with 426 tests in 22 files. The spec merged on 21 August. phdargen's #3603 ported it to Go (+38,781 lines, 241 files), and it shipped in Go v2.28.0 on 29 September. We covered the generic scheme in July: deposit once, sign cumulative commitments, redeem later in batch.

On Solana it runs on the payment-channels program, the same one SVM upto already uses. The spec fixes its mainnet id as CHNLxYvVA28MJP9PrFuDXccuoGXAx7jBacfLEkahyGsX and forbids negotiating it from the 402. The client opens a channel with a deposit and signs cumulative Ed25519 vouchers. The server checks each voucher off-chain, serves the request, and later redeems the latest voucher on-chain.

The roles are split carefully. The payout is fixed when the channel opens: 100% to payTo, committed by a distribution hash and re-checked at distribute. The facilitator pays fees and rent, and it sits in the channel's payee seat with a zero share. It can seal an abandoned channel and recover its rent, but it cannot advance the settled amount. The forced-close delay must be between 15 minutes and 30 days. Vouchers never expire.

Server mode is what's new. With voucherSigner: "server", the operator's key becomes the channel's on-chain authorized signer. The advertised amount becomes a ceiling, and the operator signs the actual cumulative charge after serving. The spec is blunt about the consequence:

"The operator can therefore take up to the full deposit without another client signature or proof that it delivered service."

It follows the logic through. In server mode, over-provisioning "is theft exposure", "not merely temporarily locked client funds". A client must keep a local allowlist of trusted operator keys, "never per 402", and should cap its escrow per operator. A forced close is no defense either: during the grace period the operator can still submit a voucher for up to the full deposit, so the spec calls it "a race". And: "Metered server pricing assumes an honest operator." The Go release adds a fallback for this case. If a client does not trust a server-signed offer, a new creation-failure handler retries with a client-signed one.

The program is live. On 2 October it was an executable, upgradeable program on mainnet. It recorded a little over 100 transactions a day on 30 September and 1 October, a count that covers every user of the program. The code is still moving. #3637 and its Go port #3664 both merged on 2 October and are not released yet. They fix refunds of server-signed channels after a client restart. With channel discovery off, the client rewrote the requirements to client mode before reading storage, then failed with NoBatchChannelToRefundError.

3. Merged is not shipped: the x402 paywall was a May build

The quietest PR of the week says the most about release hygiene. #3599, by notorious-d-e-v, adds an rpcUrls option to the Solana paywall. The author discloses working at PayAI, a facilitator. The trigger is issue #867, open since 25 December 2025. The paywall reads the payer's USDC balance from the browser against api.mainnet-beta.solana.com, and that endpoint returns 403 to requests with a browser Origin header. Mainnet payments through the built-in paywall stopped at "Unable to read your USDC balance".

While fixing it, the author found something bigger. Publishing runs tsup, not the paywall build, and the CI check that verifies the embedded templates had been manual-only since May. So the committed templates were last rebuilt on 16 May (#2160). Paywall fixes merged after that never reached the shipped bundle. They include the Algorand CAIP-2 network ID fix (#2931, 23 July), spend-control handling (#3124, 13 August), and the Celo Sepolia and Sei faucet links.

We checked the claim against what sellers actually install. In the repository, the four template files we sampled went from 16 May straight to 2 October. In the published @x402/paywall 2.28.0 from 29 September, setSpendControls appears zero times; the regenerated template has three occurrences. In the same package, the USDC lookup table inside the Algorand browser bundle is still keyed by the old network ID, algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=. Since #2931, the SDK's own network constants use algorand:wGHE2Pwdvd7S12BL5FaOP20EGYesN73k. The package version said 2.28.0. The browser code said May.

The fix regenerates all nine templates and runs the check on every pull request that touches paywall source. It also fixes a Python code path that ignored faucet_urls. It ships with the next release.

4. MCP clients let the server pick the token endpoint

On 28 September the MCP Python SDK published GHSA-qx49-fqc8-xw99, rated high (7.5). The OAuth client let the MCP server decide where the client's credentials went, because two checks were missing. The authorization server's issuer was not validated on every discovery path, and stored credentials were not bound to the server they belonged to. A malicious server had two routes. It could name its own authorization server in its protected resource metadata. Or it could publish no metadata and serve its own, naming the user's real server as issuer. Either way, it received the client_secret, the authorization code and the PKCE code_verifier meant for the real server.

Affected versions are mcp 1.9.1 through 1.29.1 on every path, and 2.0.0 through 2.1.1 on the legacy fallback and on 403 insufficient_scope responses. The fixes are 1.30.0 and 2.2.0. Upgrading alone does not protect the unattended providers. ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider keep following whichever authorization server the MCP server advertises until you pass issuer=. On 1.30.0, leaving it out raises a DeprecationWarning, which Python hides by default. Registrations stored before the fix stay unbound and must be cleared.

The TypeScript SDK disclosed the same class of bug on 30 September as GHSA-6qxp-vccf-f47h (CVE-2026-104850), also 7.5. There, a server could collect the stored refresh_token and client_secret with no user interaction. The fixes are @modelcontextprotocol/sdk 1.31.0 and @modelcontextprotocol/client 2.2.0, and bundled providers also need expectedIssuer set.

A second Python advisory, GHSA-rwrf-2pqf-9j8j (medium), has the same shape. When a server declared an outputSchema for a tool, the client validated results with jsonschema's default resolver. That resolver opens any $ref it cannot resolve locally, whether http, https or file. The fetch ran synchronously with no timeout, so one server could stall every session in the process. For unattended agents the advisory scores it 7.5. Two more Python advisories followed on 30 September: Streamable HTTP sessions that were never reclaimed by default (CVE-2026-59951), and request bodies read with no size limit.

5. Smaller items

The x402 Foundation has an executive director. On 1 October the Linux Foundation named Michael Hursta to the role and said the foundation has more than 50 active members. Hursta led payment acceptance and experience for North America at Amazon, ran PwC's enterprise payments advisory practice, and spent more than a decade at First Data. In his words, x402 is a chance "to build that next layer as open infrastructure rather than another proprietary payment system."

Mastercard scores whether an agent was there. On 30 September, Mastercard added trust and intelligence services to Agent Pay. The first, in testing in the United States, is "a probability score indicating the likelihood that a transaction was initiated by an AI agent". Cloudflare and Skyfire are named partners. A card network has to estimate whether an agent was involved. An x402 rail starts from the other end: it knows a wallet signed for this request, and has to work out who stands behind the wallet. Both sides are converging on the same identity problem.

XRPL counts 10 million. J. Ayo Akinyele, head of engineering at RippleX, said more than 10 million x402 payments had settled on the XRP Ledger, less than three months after the first million. He put the seven-day average at about 500,000 a day, as reported by The Crypto Basic. That is a count, not a value. The statement gives no dollar volume.

New default assets. v2.28.0 adds Arc mainnet (eip155:5042) and Arc Testnet (eip155:5042002), with native USDC at 0x3600000000000000000000000000000000000000 as the default asset (#3590). The author checked the EIP-712 domain (USDC, version 2) against each contract's DOMAIN_SEPARATOR() on both networks. Monad testnet USDC was added as well (#3570). Separately, the Python svm extra is now capped at solana<0.40 (#3573). Version 0.40 dropped the synchronous RPC client that the SDK imports, so fresh installs had been failing.

The x402.org counter did not move. On 2 October the homepage still showed, for the last 30 days, 75.41M transactions, $24.24M in volume, 94.06K buyers and 22K sellers. Those are the same four figures it showed on 25 September. A rolling 30-day window that stays frozen for a week is a snapshot, not a feed. If you quote it, quote the date too.

What it means for LLM4Agents

Cloudflare is now a direct comparable. It runs a model marketplace and accepts x402 per inference, with upto and prices set at the origin. That is the shape we have argued for. For now the gates matter: an account, a card, a US location, four open models and one Cloudflare-specific endpoint. Agents without an account, outside the United States, or calling an OpenAI-compatible route are outside that product today. The gap is real, but it is a beta restriction, not a design choice. We should plan as if it closes.

The 403 that arrives before the 402 is the detail to learn from. A 402 is how an agent discovers a price. If a policy check runs first, an agent outside the policy cannot tell "you may not buy" from "this costs X". For a seller, keeping the price readable is cheap. For a buyer, it decides whether it can route elsewhere or just fails without knowing why.

Server mode describes our own position. LLM4Agents meters tokens and deducts the cost of each call from a prepaid balance funded on Solana or Polygon. The agent trusts our meter, just as a server-mode client trusts its operator and an AI Gateway buyer trusts Cloudflare's pricing module. The spec's advice applies to us from the seller's side: keep exposure small, offer a verifiable alternative, and make after-the-fact checks possible. Our balance model already caps exposure at what the agent deposited. Verifiability is the part to strengthen.

The paywall finding and the MCP advisories teach one lesson at two layers. What a component does depends on what was actually built and what the other side told it, not on the version string or the changelog. Our gateway sits between agents and many upstream providers. Anywhere an upstream response decides where we send something, such as a redirect, a metadata URL or a schema reference, is a place to pin the destination.

Staying on the frontier

Five steps, in order.

First, patch MCP clients this week. This applies to any component that acts as an MCP client over HTTP with OAuth. In Python, move to mcp 1.30.0 or 2.2.0 and set issuer=. In TypeScript, move to @modelcontextprotocol/sdk 1.31.0 or @modelcontextprotocol/client 2.2.0 and set expectedIssuer. Clear stored registrations saved without an issuer. Rotate any secret that was used against a server you do not control.

Second, put the meter in the receipt. Return token counts, unit prices and the resulting charge with every call, signed, so an agent can recompute what we deducted. The batch-settlement spec describes client checks in server mode as "post-hoc detection and accounting". We should make that detection trivial. While we are at it, add a CI check that what we ship is what we built. The paywall bundle shows why.

Third, keep the price readable. Return payment requirements before any policy check that is not about the request itself. If a rule blocks a buyer, say so in a machine-readable error that gives the reason, not a bare 403.

Fourth, prototype upto with origin pricing. Cloudflare's design is the reference: a signed maximum per call, then settlement of actual usage. Our existing pricing module can compute that maximum from max_tokens and the model's prices. Run it on a testnet before any mainnet exposure. We made the case for this scheme in the upto deep dive, and Cloudflare has now shipped it for inference.

Fifth, track Solana batch-settlement, client mode first. Solana is one of our deposit rails, and a channel opened once and drawn down by vouchers fits agents that make many small calls. Wait for a TypeScript release that includes #3637, then test client-signed channels on devnet. Treat server mode as off unless an agent explicitly allowlists our operator key with a capped deposit. The spec sets that same rule for every operator.