Streaming Payments on Radius
New ways to pay are here. Radius supports them at scale. Here’s how.
The machine economy needs a new payment primitive. Transactions like real-time inference consumption, compute purchases, and paid content access have costs that are dependent on duration and degree of usage.
Streaming payments solve this. Rather than pre-paying for capacity or waiting for an invoice, value flows in lockstep with consumption. The agent pays as it goes and the provider gets paid in real time. Either party can walk away and neither carries credit risk.
The launch of Tempo's Machine Payments Protocol (MPP) alongside existing standards like x402 is driving important conversation on how the payment handshake should work. Critically, the growth of streaming payments in tandem with use cases like pay-per-visit will require massive transaction capacity. That's where Radius comes in.
Supporting streaming payments at scale
Protocols like x402 and MPP define how a client and server negotiate and authorize payment. They handle the handshake: the challenge, the credential, the receipt. Settlement is the job of the network underneath.
Consider what happens when streaming payments meet real-world adoption. A single pay-per-visit content platform serving millions of concurrent users generates millions of settlement transactions per second. Layer in AI inference, API metering, and IoT billing, and you're looking at transaction volumes that vastly exceed what most networks were designed for.
For this to work, the settlement layer needs fees low enough that sub-cent transactions stay economically viable, finality fast enough to keep pace with consumption, and throughput that doesn't degrade under load.
Radius was built for this. Stablecoin transfers execute for $0.0001. Finality is sub-second. And because Radius enables parallel execution rather than sequential block-based consensus, throughput scales linearly with compute. Each micropayment can settle individually, in real time, at a cost that rounds to zero.
RadRouter: Streaming AI payments in practice
RadRouter is a live application on Radius that demonstrates the value of streaming payments. It's an AI model router, a single API endpoint that gives you access to every major LLM provider, that supports pay as you go consumption. No API keys, no subscriptions, no credit cards. A lightweight local proxy handles wallet signing automatically, and payments settle in under a second as you use the models.
Protocol agnostic by design
RadRouter currently uses x402 for its payment flow, but could support MPP with minimal architectural changes. Ultimately, Radius is a protocol agnostic network supporting microtransactions at scale.
How RadRouter works today with x402
- IDE sends request. Zed (or any OpenAI-compatible client) sends a standard API request to the local proxy on localhost.
- Proxy gets 402. The proxy forwards to RadRouter, which responds with HTTP 402 and payment terms denominated in SBC.
- Auto-sign and pay. The proxy signs an EIP-2612
permitwith your local key and retries the request with anX-Paymentheader — no popups, no interaction. - Instant delivery. A facilitator verifies the permit and settles on Radius in ~500ms. The response streams back to your IDE seamlessly.
Every inference request is a discrete transaction: challenge, sign, settle, deliver. It works well for per-request billing, and the entire round trip completes faster than it takes for the model to generate its first token.
How the same flow would work with MPP
- IDE sends request. Same as above: Zed sends a standard API request to the local proxy.
- Proxy gets 402 with MPP challenge. RadRouter responds with HTTP 402 and a
WWW-Authenticate: Paymentheader advertising a Tempo session payment method and a suggested deposit amount. - Session opens. The proxy initiates a payment via a Radius transaction, locking allocated funding (e.g., 1 SBC).
- Vouchers replace transactions. On each subsequent request, the proxy signs an offchain voucher incrementing the cumulative amount owed and includes it as an
Authorization: Paymentcredential. The server validates the voucher with a CPU-bound signature check. - Streaming delivery. For SSE-based responses (like token-by-token inference), the server charges per token as content streams. If the pre-allocated balance runs low, the client automatically signs a new voucher and the stream continues uninterrupted.
- Session closes. When the agent is done, a single close transaction on Radius settles any remaining balance and refunds unspent deposit.
The key difference: x402 settles each request individually on Radius or other supported networks. MPP amortizes settlement across an entire session using offchain vouchers, with as few as two Radius transactions. Both Radius transactions benefit from sub-second finality and $0.0001 fees. The protocol is the interface between buyer and seller, Radius is the settlement infrastructure.
What comes next
Machine-to-machine payments are gaining traction and yesterday’s release of MPP is another step towards meaningful adoption. As this new class of payments scales, it will require settlement infrastructure that can handle high-volume, low-value transactions without compromise.
Radius is that infrastructure. No native token. Stablecoin-native fees. Linear scalability.
Try RadRouter today. Read the Radius docs to start building. Follow us on X.
Build on Radius
Get in touch with our team to discuss your next project.