The CEO of one of the world's largest internet companies said no blockchain can handle what AI agents need. Here is what that means — and why Radix is being built for exactly that problem.
Cloudflare runs infrastructure for roughly 20% of all websites on the internet. When its CEO, Matthew Prince, says something publicly about what he needs from a blockchain, it is worth paying attention. What he said, on the Bankless podcast in early 2026, was blunt: no existing blockchain can handle the volume that AI agents will generate. Not Ethereum. Not Solana. Not any of the current options.
The number he had in mind was 100 million transactions per second. That is not a typo. It is the scale at which AI agents — software programmes that act autonomously on behalf of people and businesses — will need to settle payments when they become the primary users of the internet.
That moment is closer than most people realise. AI agents are already buying and selling services, completing tasks, and paying each other. The question is not whether this happens. The question is which settlement layer they use when it does.
To understand why this matters, it helps to understand how an AI agent transaction works in plain terms. It is not like a human logging into a bank. It is closer to a standing order that the agent issues in advance, which executes automatically when certain conditions are met — with no human needing to approve it at the moment it happens.
The instructions go out over the normal internet — fast, cheap, no blockchain involved. When they need to settle, they come back on-chain. Radix handles that settlement step. At very high volumes, Radix's architecture (called Hyperscale) is designed to handle the load that Cloudflare's CEO is describing — without slowing down or becoming expensive.
Most blockchains process transactions in a single queue. Every transaction waits its turn, which puts a hard ceiling on how many can be processed per second. Radix's architecture — Cerberus consensus, extended by Hyperscale — removes this ceiling by processing transactions in parallel across shards. The theoretical limit scales with the number of validators, not with a fixed queue.
But throughput alone is not the argument. The more important property is what a Radix transaction tells you. When an AI agent settles a payment on Radix, anyone authorised can read exactly what happened: which assets moved, from which account, to which account, in what amounts, under what conditions, verified by which agent. The transaction is human-readable by design. On most other blockchains, you need additional tooling to reconstruct that picture from raw data.
For an AI institution — an organisation run primarily by AI agents — this legibility is the difference between a system that can be audited and one that cannot. Regulators, investors, and counterparties can verify what happened without trusting the organisation that operated it.
The Cloudflare problem is not hypothetical. Builders in the Radix ecosystem are working on it now, in public, with real deployments. A single evening's conversation in June 2026 illustrates the state of play:
That last question is the most significant. xStelea is asking whether the human signing step can be removed entirely — whether the agent can deploy, own, and operate on-chain components autonomously, then deliver the ownership credential to the human after the fact rather than requiring human approval before each step. If the answer is yes, the developer experience becomes: describe what you want, the agent builds and deploys it, you receive the keys. No blockchain expertise required.
Vlad B learned something important building the World Cup Badge Arena — a live Radix mainnet collectible game deployed in June 2026: his AI agent got NFT metadata formatting wrong because it did not have precise enough instructions. The fix is structured skills — a canonical set of instructions that tells the AI exactly how Radix components, tokens, and badges are formatted, so it does not have to guess. xStelea's RAP protocol and rdx-cli are the beginning of this skills layer. The RadixScan MCP server expansion is another piece. When they connect, an AI can deploy a complete Radix application correctly on the first attempt.
There is a version of this story that is purely about throughput — Radix can process more transactions per second than competitors, therefore it wins. That argument is necessary but not sufficient. The more durable competitive advantage is what it feels like to build on Radix with AI assistance.
When a developer asks an AI to build something on Ethereum, the AI has to navigate Solidity's quirks, gas estimation, the risk of reentrancy attacks, and the opacity of EVM bytecode. When a developer asks an AI to build on Radix, the transaction is a human-readable manifest — a structured description of intent that the AI can write, verify, and debug in plain terms. Assets are first-class objects. Permissions are explicit. The things that go wrong on other chains either cannot happen on Radix or fail cleanly rather than silently.
Vlad B's observation — "it's honestly crazy how fast I managed to put this game together, and I deployed directly on mainnet to cut time" — is the developer experience story in one sentence. A long-tenured builder, using AI assistance, shipping to mainnet faster than expected because the architecture is legible to the AI helping him build it.
The payment mechanism described above has a name in technical circles: x402. It is an extension of the HTTP protocol — the same protocol that powers every website — that allows a server to respond to a request with "payment required" rather than just returning content or an error. The client (an AI agent or application) pays automatically and retries. No human interaction needed.
A community builder — xStelea, with commit history in the official Radix developer toolkit — has implemented x402 on Radix, deployed on Cloudflare Workers. The implementation is live and publicly verifiable. It uses Radix's Transaction Manifest V2, which means the payment is a human-readable, structured document rather than opaque bytecode.
The "instructions sent out and acted on off-chain" described in plain English above are called subintents in Radix's architecture. A subintent is a partial transaction signed by one party — for example, an AI agent committing to pay — that can be combined with other subintents and submitted as a single atomic transaction. This means multiple parties can act independently and their actions settle together, without any single party having to coordinate or trust the others during execution.
The RadixScan MCP server (mcp.ai.radixscan.io) provides AI agents with keyless access to Radix chain data. It is being expanded to support component deployment — allowing AI agents to deploy Radix packages and instantiate components through structured instructions rather than manual wallet operations.
Radix's base consensus mechanism, Cerberus, processes transactions in parallel across shards rather than sequentially in a single queue. This means throughput scales with the number of validators rather than being capped by a fixed architecture.
Hyperscale is the Rust-based extension of this architecture, targeting mainnet deployment in 2027. A testnet demonstration achieved 500,000+ TPS. The path to 100 million TPS — Cloudflare's stated requirement — is architectural rather than speculative: it requires more validators and continued engineering, not a fundamental redesign.
Honest qualification: 500K TPS on a testnet and 100M TPS in production are separated by significant engineering work and real-world adversarial conditions. The architecture is the right shape. The gap between demonstrated and required is real and should not be glossed over.