On August 4, 2026, Cloudflare launched Wallets — programmable wallets that let AI agents hold a balance and pay for APIs, MCP tools, and content autonomously. We run an x402 payment marketplace. The obvious question, on day one: can a Cloudflare Wallet agent actually pay for a minia2a service?
This post is the honest technical answer. Not a press release — a compatibility check, layer by layer. Where it works, where it's unverified, and the two specific gaps we need to close before we call it "supported."
First, the current state of minia2a, straight from our live API:
We run real x402 endpoints on Base L2. Cloudflare's agents, if they can speak x402, should be able to pay us. Let's check whether they can.
Cloudflare's design is two-tier, cleanly separating funding from spending:
The protocol layer is x402 — HTTP 402 "Payment Required" — with settlement in USDC on Base (primary) and Solana. Cloudflare's Agents SDK wraps any MCP client with withX402Client(), so every tool call gets the 402 → sign → retry cycle for free. The facilitator URL it uses is https://x402.org/facilitator.
minia2a's implementation is deliberately facilitator-agnostic. We don't pin a facilitator, a wallet SDK, or a key model. The flow is the raw protocol:
Authorization headerNew agents get 15 free trials per IP, then 500 credits on registration. Past that, it's pay-per-call USDC. Because we only depend on the protocol — HTTP 402 + a USDC transfer + a signature — any wallet that speaks x402 should work, Cloudflare's included.
Here's the honest layer-by-layer check:
| Layer | Cloudflare Wallets | minia2a | Status |
|---|---|---|---|
| Payment protocol | x402 (HTTP 402) | x402 (HTTP 402) | ✅ Compatible |
| Settlement chain | USDC on Base (primary) / Solana | USDC on Base (default) | ✅ Compatible |
| Facilitator | x402.org/facilitator |
Facilitator-agnostic (any) | ✅ Compatible |
| Payment proof | x402 standard signature | x402 signature verification | ✅ Compatible |
| Sender identity | cloudflare.pay handle |
API key / wallet address | ⚠️ Needs recognition |
| Signing key model | API key → Cloudflare signing service | Self-custody private key | ⚠️ Needs verification |
| Service discovery | Monetization Gateway (Jul 1) | /.well-known/x402 + marketplace |
🔮 Future opportunity |
Four green rows, two yellow rows, one purple row. Let me unpack each one — especially the yellows, because those are the ones that decide whether "compatible in theory" becomes "works when you click Go."
Both sides implement x402. That's not a fuzzy "shared vision" claim; it means the bytes on the wire match. An x402-capable client sends a request, receives 402 Payment Required with a payment invoice, signs a USDC transfer, and retries with the proof. Cloudflare's withX402Client() wrapper and our endpoints implement the same negotiation. No translation layer required.
This is the single biggest practical win. Cloudflare settles USDC on Base by default; minia2a invoices USDC on Base by default. No bridging, no chain-hopping, no "the wallet only speaks Solana and the endpoint only takes Base" mismatch. A Cloudflare Virtual Wallet and a minia2a invoice are on the same chain before they even meet.
Cloudflare's agents talk to x402.org/facilitator. minia2a doesn't hardcode a facilitator — we accept whatever the client's facilitator returns as long as the settlement lands. Cloudflare's facilitator choice is irrelevant to whether the payment clears. This is exactly the property we designed for.
The payment proof Cloudflare's wallet produces is the standard x402 signature envelope. We verify that envelope against the invoice. Same signature scheme, same verification path.
cloudflare.pay handlesCloudflare introduced cloudflare.pay handles — human-readable identities like research.acme.cloudflare.pay, backed by a keypair. When a Cloudflare agent pays us, its handle is the sender identity. Today, our wallet registration recognizes EVM addresses and API keys as wallet identifiers. A cloudflare.pay handle is a new identifier shape we don't currently parse.
This doesn't block the payment — the settlement is still a normal USDC transfer to our invoice address. But it does block attribution: we want to associate that sender with a wallet user record, apply trial/credit logic, and keep a per-handle history. If we can't recognize the handle, the payment still lands but the agent is anonymous to us.
The fix is small and well-scoped: accept *.cloudflare.pay strings as a valid wallet identifier in registration, and store the handle alongside the resolved address. It's a validation + normalization change, not a protocol change.
This is the one genuinely open technical question. Cloudflare Virtual Wallets are operated with an API key — the actual signing happens inside Cloudflare's service, not on the agent's machine with a raw private key. Our endpoints, like all self-custody x402 implementations, expect a payment proof signed by the private key corresponding to the invoice address.
The question is whether Cloudflare's signing service can produce a proof our verifier accepts for the address we invoice. That depends on the exact key-derivation model under the hood — whether the Virtual Wallet's on-chain signing address is derivable from, or at least resolvable to, the identity we see at settlement.
We have not tested this end-to-end yet. It's the difference between "the spec says compatible" and "we've watched a Cloudflare wallet pay us." Until a Virtual Wallet actually completes a payment against one of our endpoints, I'm keeping this row yellow on purpose.
"Until a Cloudflare Virtual Wallet has actually paid one of our endpoints, the key-model row stays yellow. Compatible in theory is not the same as verified in practice."
To make this concrete, here's what the flow looks like from each side.
import { withX402Client } from "@cloudflare/agents-sdk/x402";
const mcp = createClient({ transport: "http", url: "https://minia2a.uk/x402/proxy" });
const paid = withX402Client(mcp, {
virtualWalletId: "vw_01J9x...", // agent's Virtual Wallet
apiKey: process.env.VIRTUAL_WALLET_KEY, // API key, not a raw private key
facilitator: { url: "https://x402.org/facilitator" },
});
// Every tool call now: request → 402 → check guardrails → sign → retry
const time = await paid.callTool("minia2a_x402_time", {});
const gas = await paid.callTool("minia2a_x402_gas", { chain: "base" });The agent framework doesn't know it's paying. It calls a tool, and the wrapper handles the 402 negotiation inside Cloudflare's guardrails — if the merchant isn't allowlisted or the spend exceeds the cap, the call fails before any money moves.
When the agent is out of free credits, our endpoint answers with the invoice. This is a real response from our current implementation:
HTTP/1.1 402 Payment Required
Content-Type: application/json
{
"_registration_required": true,
"message": "Credits exhausted. Pay with USDC on Base.",
"payment": {
"amount": "0.005",
"token": "USDC",
"chain": "Base",
"recipient": "0xf16F0882de08315B438E9f3a2Abfb2d2E5d94ECA"
}
}The Cloudflare wrapper parses that invoice, checks the Virtual Wallet's guardrails, signs the USDC transfer, and retries:
POST /x402/proxy/x402-time HTTP/1.1
Authorization: x402 <signed-payment-proof>We verify the proof on-chain against the invoice, and return the result. The whole cycle — 402 out, proof back, settlement, 200 OK — runs in a couple of seconds. That's the entire compatibility surface.
Cloudflare's Monetization Gateway (announced July 1, 2026) is the seller side of this stack. Its long-term promise: a service listed in the Gateway becomes discoverable to every Cloudflare-connected agent, with Cloudflare handling pricing, collection, and payouts.
minia2a already serves /.well-known/x402 metadata on every endpoint — the same shape the Gateway uses for service discovery. So the path from "a Cloudflare agent can pay us" to "a Cloudflare agent can find us" is short. But it's a real integration, not a side effect, and it depends on Gateway's listing API and fee model. That's why it's a future row, not a today row.
Honest analysis leads to an honest to-do list. Four items, in priority order:
cloudflare.pay handle recognition — accept *.cloudflare.pay as a valid wallet identifier in registration, normalize it, and attribute payments to the handle.withX402Client() config that works.We're doing these in order. Items 1 and 2 are the ones with real engineering content; 3 and 4 are documentation of whatever the test reveals. If the key-model row turns red — if Cloudflare's signing service can't produce a proof our verifier accepts — we'll say so publicly and work the spec angle, because that's a protocol-level gap, not a minia2a-level gap.
At the protocol, chain, and facilitator level, Cloudflare Wallets and minia2a are compatible today. A Cloudflare agent's x402 client should be able to pay our endpoints with USDC on Base without a single line of custom integration on either side.
Two gaps stand between "should be able to" and "is verified": recognizing cloudflare.pay handles for attribution, and proving that Cloudflare's API-key signing model produces proofs our self-custody verifier accepts. Both are testable, both are on our list, and neither requires a protocol change.
The interesting part is what comes after. 299 services, 42 wallet users, 318 unique agents — and now the entire Cloudflare-connected agent population has a payment rail that can reach them. When Monetization Gateway opens up, the number of agents that can find and pay minia2a services is going to change the shape of this marketplace.
Create an agent wallet and try minia2a's x402 services — 500 credits free on registration
Register for minia2a →Sources: Cloudflare Wallets Announcement, minia2a live stats, minia2a x402 docs