The opportunity
Cloudflare's $70 billion question — and why Radix might already have the answer.
An independent read on what Matthew Prince's Bankless interview means for Radix, what one community builder has already quietly shipped, and what needs to happen next.
The gap Cloudflare is asking someone to close
§ 01 — The setup
What just happened on Bankless.
On May 25, 2026, Cloudflare CEO Matthew Prince spent ninety minutes on the Bankless podcast explaining a problem — and publicly inviting solutions. Cloudflare sits in front of roughly twenty percent of the world's websites. When its CEO uses that platform to ask for something specific, it is worth paying attention to what he asked for.
The problem Prince described: AI agents are about to overtake humans as the dominant source of traffic on the internet. Cloudflare projects this happens in the first half of 2027. The current business model of the web — advertising and subscriptions — does not survive that transition. Agents do not click on ads. A single subscription, scraped by an agent, displaces a hundred human pageviews. Without a new way for content creators to be paid, the web that produced the content the agents are reading begins to collapse.
The solution Cloudflare is converging on is HTTP-native micropayments — specifically, an open standard called x402, developed in partnership with Coinbase and the Linux Foundation. When an agent requests a piece of content, the server responds with HTTP 402 Payment Required, the agent pays a fraction of a cent via a stablecoin, and the content is delivered. At scale, this becomes the new economic substrate of the internet.
But there is a catch — and it is the catch that matters for Radix.
Cloudflare currently handles roughly 500 million HTTP requests per second across its network. Between one and ten percent of those are potentially monetisable. That is five to fifty million transactions per second of payment volume — on day one. Every blockchain Prince's team has evaluated tops out at around two million TPS. He needs two to three orders of magnitude more, and he said so out loud.
§ 02 — The fit
Why Radix specifically maps to this ask.
Of all the high-throughput L1s in the market, Radix is the one whose technical positioning maps most precisely to what Prince described. Three reasons:
- Linear scalability through Xi'an. Radix's consensus mechanism is designed to scale throughput linearly with the number of nodes, rather than hitting the ceiling that single-shard chains face. Xi'an, currently in development, is the production realisation of that design.
- Atomic composability. Transactions can interact with multiple parts of the network in a single atomic operation. Cloudflare's use case isn't isolated payments; it's payments that need to compose with other on-chain logic — subscriptions, reputation, escrow — without splitting into sequential steps across separate shards.
- Subintents. A Radix-specific transaction primitive that lets a client sign a partial payment intent while a separate party (the resource server, in this case) wraps it in a sponsored root transaction and pays the gas fee.
Subintents in particular are the detail that becomes more interesting the longer you sit with the x402 use case. They mean an AI agent doesn't need to hold gas tokens, doesn't need to wait for a confirmation before getting the content, and doesn't need to be running on a chain that knows anything about HTTP. The client signs an intent; the server settles it. That is exactly the shape of the problem Cloudflare is describing.
Replicating this UX on other L1s typically requires centralised relayers, separate paymaster contracts, or off-chain workarounds. Radix has it as a first-class transaction primitive.
§ 03 — The proof of life
Someone has already built it. Quietly.
Here is where this stops being theoretical.
A Radix community builder going by the handle xstelea has, before this podcast even aired, been working on a Radix-native implementation of x402. The work is in three artifacts you can verify yourself, right now:
A 672-line protocol spec, forked from the canonical x402 repository
Covers both sponsored and non-sponsored settlement modes. Written as a fork of x402-foundation/x402 — meaning it has a credible path to being upstreamed into the official x402 standard.
github.com/xstelea/x402/.../scheme_exact_radix.md
A merged pull request to radix-web3.js
Merged May 25, 2026. CLI tooling for subintent construction, transaction inspection, a runnable Hono reference server, and a working settlement pipeline with tests.
github.com/xstelea/radix-web3.js/pull/37
A working endpoint, deployed on Cloudflare Workers
Returns the correct HTTP 402 Payment Required response for protected resources. It is running today, on Cloudflare's own infrastructure.
x402-radix-reference.xstelea.workers.dev/protected/reference.md
For non-technical readers, what this means is straightforward: someone has already built a working version of the thing Cloudflare is asking for, and it is running on Cloudflare's own infrastructure today.
For technical readers, what's particularly notable is the rigour of the spec itself. It handles subintent front-running through Radix's VERIFY_PARENT instruction and the virtual signature badge mechanism. It treats replay protection at both the facilitator cache layer and the ledger layer. It enumerates exact instruction-count and argument constraints for facilitator verification. It explicitly addresses denial-of-service surface area for sponsored facilitators. This is not a sketch. It is written with the discipline of a standards document.
Open the technical deep-dive
The sponsored flow — the one that matters for the agent UX — works like this:
1. The client (an AI agent, in the Cloudflare scenario) requests a protected resource.
2. The resource server returns HTTP 402 with a PaymentRequirements payload specifying the amount, asset, recipient, network, and a notaryBadge identifying which facilitator is authorised to settle.
3. The client constructs a SubintentManifestV2 with exactly five instructions: VERIFY_PARENT (binding the subintent to the specified facilitator), ASSERT_WORKTOP_IS_EMPTY, a withdraw from the client account, TAKE_ALL_FROM_WORKTOP, and YIELD_TO_PARENT.
4. The client signs the subintent only — no gas, no full transaction — producing a SignedPartialTransactionV2 which is hex-encoded and sent back via the X-PAYMENT header.
5. The facilitator verifies the structure (exact instruction count, exact arguments, signature validity, replay-cache check, preview against ledger state), then wraps the signed subintent as a child in a root transaction, pays the gas via lock_fee, notarises with the key matching the notaryBadge, and submits.
6. On commit, the resource server returns the protected content.
The cleverness is in VERIFY_PARENT. Without it, a signed subintent would be a bearer credential — anyone obtaining it could attempt to wrap it in their own root transaction and submit it. VERIFY_PARENT binds the subintent to a specific notary virtual badge, which only the intended facilitator can produce in the auth zone (via notary_is_signatory: true). Front-running is mechanically impossible. This is a real, subtle attack vector that the spec has handled at the protocol layer rather than via convention.
The toolkit dependency worth flagging: the spec's tooling table notes that the official @radixdlt/radix-engine-toolkit does not yet expose V2 manifest and intent support, which is what subintents require. xstelea has had to maintain a community fork (@steleaio/radix-engine-toolkit) to fill the gap. This is the single most important Foundation-level item on the table. Until the official TypeScript SDK supports V2 natively, every external builder who wants to do anything with subintents hits the same wall — and most won't fork the SDK themselves.
§ 04 — The path
What needs to happen now.
Three things, in order of priority.
First, the Foundation needs to close the SDK gap.
The community fork of the TypeScript toolkit cannot be the long-term answer. The official @radixdlt/radix-engine-toolkit needs to expose V2 manifest and intent support, and it needs to happen on a timeline measured in weeks rather than quarters. If Radix wants to be taken seriously as a settlement layer for agent payments, every external builder must be able to use the canonical SDK out of the box.
Second, the demonstration needs to be matured.
xstelea's reference implementation is the right seed artifact, but it needs the polish that distinguishes a community demo from an institutional offering. Specifically: performance characterisation under load (latency, end-to-end settlement time, fee profile), a dashboard that visualises the things Prince explicitly named on the podcast (requests per second, accepted payments, pending settlement, finalised settlement, fraud and replay prevention), and a multi-builder bench so it doesn't look like a one-person project.
Third, the messaging needs to be calibrated.
The instinct to claim "Radix can do ten million TPS today" is exactly the wrong move. Cloudflare's evaluators have already filtered out every L1 that has overclaimed and underdelivered — that's how they ended up at "two million is the best we've seen." The credible move is to present what is actually working today, characterise the path to scale with engineering rigour, and let the spec and the running code speak. This is a long game; credibility preserved now is credibility deployable later.
§ 05 — Honest risks
What's not a golden ticket.
It bears saying clearly: this is an opportunity that needs to be played carefully, not a deal that is already done. Four risks worth naming directly.
Risk 1 · Single-builder dependency
The entire current stack — spec, implementation, V2 SDK fork — rests on one community contributor. Bus-factor matters, and a serious Cloudflare-grade conversation would surface this as a concern immediately. The remedy is more builders engaging now, not fewer.
Risk 2 · The open-source debate
Some have raised whether components of Xi'an should be open-sourced selectively, to prevent a Cloudflare-scale actor from spinning up a permissioned variant that bypasses the public network and its token. The concern is legitimate; the proposed remedy (delay open-sourcing) is almost certainly the wrong instrument. The right defence is network effects — making the public Radix network the cheapest, fastest, and most credible venue to settle. This is the kind of strategic decision the incoming Marshall Islands DAO LLC governance will need to handle with discipline.
Risk 3 · Overclaiming
Community enthusiasm already shows a tendency to claim throughput Radix has not yet demonstrated in production. That pattern, projected externally, will undermine credibility with exactly the audience Radix wants to reach. Lead with what is verifiably working today.
Risk 4 · Cloudflare is not promising equity
The realistic outcome is partnership or integration, not investment. Cloudflare has explicitly positioned itself as wanting to support payment rails, not pick winners. Distribution and validation are the prize, not a capital injection.
§ 06 — How to contribute
If you want to help, here is where.
- If you build. Look at xstelea's pull request. Contribute. Multi-builder presence is the single most important credibility lift this effort needs right now.
- If you operate nodes or run Stokenet. The Stokenet transition is nearly complete and the community now controls the testbed. This is the right surface to validate any future production-grade demo against.
- If you are Foundation, Cabinet, or RAC. Engage with xstelea directly. Decide whether this is officially supported or community-driven, and communicate clearly either way. Prioritise V2 support in the official TypeScript SDK above almost everything else on the developer-tooling roadmap.
- If you are simply community. Watch the messaging. Share the working code, not the marketing claims. The credibility you preserve now is the credibility that opens doors later.